文章总结： 本文介绍了大模型应用开发的基本概念，包括LLM本质、Token机制、RAG架构及向量数据库应用。RAG通过检索外部资料增强模型回答准确性，解决幻觉、知识过时和私有数据安全问题。总结强调大模型应用开发中提示词工程的重要性，并提供了后续优化建议。
综合评分： 85
文章分类： AI安全
大模型应用开发必需了解的基本概念
原创
crossoverJie
crossoverJie
2025年12月23日 08:08
重庆
字数 2054，阅读大约需 11 分钟
背景
AI/LLM 大模型最近几年毋庸置疑的是热度第一，虽然我日常一直在用 AI 提效，但真正使用大模型做一个应用的机会还是少。
最近正好有这么个机会，需要将公司内部的代码 repo 转换为一个 wiki，同时还可以基于项目内容进行对话了解更具体的内容。
实际效果大概和上半年很火的 deepwiki[1] 类似。
而我们是想基于开源的 deepwiki-open[2]进行开发，提供的功能都是类似的。
在这个过程中我也从一个大模型应用开发的小白逐步理解了其中的一些关键概念，以及了解了一个大模型应用的运行原理。
LLM
LLM（Large Language Model，大语言模型）大家应该都比较熟悉了：
-
• 本质：一个通过海量文本训练出来的概率模型
-
• 能力：理解/生成文本、代码，做推理、对话等
-
• 特点：
-
• 参数固定：训练完之后“记忆”是固化在参数里的
-
• 知识有时间点：只知道训练截止前的数据（有知识截止时间）
可以把 LLM 当成一个“通用大脑”，但不一定知道最新的、你的私有数据。
目前的 AI 也就是大模型本质上还是概率预测，当你给它一段话（Prompt）时，它在后台做的事情是：“根据我读过的几万亿字，接在这段话后面，概率最高的下一个字（Token）是什么？”
所以大模型每次回答的内容可能不同，也不能 100% 的告诉你准确答案。
Token
大模型并不直接认识java、Rust 或者“编程”这些词。在模型内部，所有的文字都会先被转换成一系列数字。
-
• 字/词 ≠ Token：一个 Token 既不是一个字符，也不是一个单纯的单词。
-
• 灵活切分：
-
• 常见的词（如
the,apple）通常对应 1 个 Token。 -
• 罕见的词或长的复合词（如
microservices）可能会被拆分成几个 Token（如micro+services）。 -
• 中文通常比较特殊：一个常用的汉字可能是 1 个 Token，但不常用的汉字可能会占用 2-3 个 Token。
在做大模型应用开发的时候尤其需要注意 token 的用量，毕竟这是计费的标准。
还有一个是上下文窗口的限制，每个模型都会有最大 token 的限制（如 8k, 32k, 128k）。
如果你的 Prompt 加上模型的回复超过了这个限制，模型就会丢掉前面的记忆或者直接报错。
在日常开发估算中，可以大概估算一下这个比例：
- • 英文文本：1000 Tokens ≈ 750 个单词。
- • 中文文本：1000 Tokens ≈ 500 到 600 个汉字（随着模型词表的演进，现在的模型处理中文的效率在不断提升。）。
- • 代码：代码中的空格、缩进和特殊符号都会消耗 Token。Python 等由于缩进较多，消耗通常比纯文本快。
也有相关的库可以帮我们计算 token：
# Choose encoding based on embedder type
if embedder_type == 'ollama':
# Ollama typically uses cl100k_base encoding
encoding = tiktoken.get_encoding("cl100k_base")
elif embedder_type == 'google':
# Google uses similar tokenization to GPT models for rough estimation
encoding = tiktoken.get_encoding("cl100k_base")
else: # OpenAI or default
# Use OpenAI embedding model encoding
encoding = tiktoken.encoding_for_model("text-embedding-3-small")
return len(encoding.encode(text))
也可以通过 openai[3] 的一个实例网站来可视化查看 token 的计算规则：
RAG
RAG 的全程是Retrieval-Augmented Generation（检索增强生成），他不是类似于 LLM 的模型，而是一种架构模式。
举个例子：
比如你问 ChatGPT 关于你们公司的某一个规章制度，大概率 ChatGPT 的训练语料是你没有你们公司的内部数据的。
所以他回复你的多半是瞎编的内容，或者直接告诉你不知道。
此时就需要 RAG 了，他可以在真正询问 LLM 之前先到内部的资料库里通过用户的问题将相关上下文查询出来，然后再拼接成一个完整的 prompt 发送给 LLM，让 LLM 根据你通过的数据进行回答。
这样能解决一下三个问题：
- 1. 幻觉问题：你问它一个它不知道的事情，它会一本正经地胡说八道。
- 2. 知识过时：大模型的知识停留在它训练结束的那一天。
- 3. 私有数据安全：你不能为了让 AI 懂你的业务代码，就把几百万行私有代码全发给模型提供商训练一个新模型，那太贵且不安全。
使用 RAG 时还需要额外考虑到数据清洗的步骤，比如我们这里的 repo wiki 的场景，我们需要把一些第三方库、编译后产生的 target 目录等不需要的内容排除掉。
避免在查询时带上这些内容，干扰最终的结果。
向量数据库
上文里提到 RAG 模式，需要一个非常关键的组件，那就是向量数据库。
我们先要在 RAG 里检索出相关的上下文就是在向量数据库里做查询，具体流程如下：
- 1. 把文档切块（段落级别）
- 2. 用一个 Embedding 模型 把每个块转成向量
- 3. 把这些向量存进 向量数据库
- 4. 用户提问时，也把问题转成向量
- 5. 用向量相似度检索出最相关的文档块
- 6. 把这些文档块 + 问题喂给 LLM，让它生成答案
简单来说就是将一些非结构化的数据（图片、视频、文字）通过Embedding 模型 转换成一串数字数组，即向量（例如：[0.12, -0.59, 0.88, ...]）。
查询的时候也会将查询内容转换为向量，然后返回在向量空间里相近的数据。
Q&A
此时也许你会有以下一些问题：
LLM + RAG + 向量数据库，是不是类似于用 LLM 训练私有化数据？这两者的效果是否类似？ 如果不同，区别在哪里？
LLM + RAG + 向量数据库：
- • 本质是：
不改模型参数，用检索到的外部资料来“喂”模型，让它查完再答。
- • 你的数据在外部（向量数据库里），只是当作参考材料塞进 prompt。
在私有数据上训练（微调 / 预训练）：
- • 本质是：
用你的数据更新模型参数，让模型“记住”这些模式和知识。
- • 你的数据被“烤进”模型权重里，调用时不需要再查这份数据。
| 维度 | RAG（向量库） | 微调 / 私有训练 |
| — | — | — |
| 知识存放 | 外部向量库 | 模型参数里 |
| 更新成本 | 改文档即可，重建 / 增量向量索引 | 需要重新训练部署 |
| 生效时间 | 几分钟级 | 训练+上线，小时～天级 |
| 支持频繁变更 | 很适合 | 很不适合 |
| 透明度/可解释性 | 高 （可以追溯到原文出处） | 低 （模型直接给出，无法确切知道来源） |
总的来说使用 RAG 外挂私有化向量数据的成本更低，也更灵活。
对于一些更垂直的场景，可以考虑使用私有数据训练模型。
总结
总体下来的感受是 LLM 应用大部分的代码都是 prompt 提示词，普通 app 的主要内容是代码，而不同大模型应用的主要区别是提示词；反而代码大部分都是趋同的。
区别就是用了什么框架，但是共同的就是调用大模型 API，将传统的 request/reponse 的请求模式换为流式响应（大模型的响应很慢）。
在开发应用时，需要了解 System Prompt（系统预设角色）、User Prompt（用户提问）和 Few-shot（给模型几个例子引导它）。好的 Prompt 是让 RAG 结果准确的关键。
后续还需要更加完善 deepwiki-open：
- • 优化 splitter，使用更适合代码分割的 splitter，比如 tree-sitter[4]
- • 将存储在本地的向量替换为一个独立的向量数据库
- • 持续优化提示词，更加符合我们的项目背景
引用链接
[1] deepwiki: https://deepwiki.com/redis/redis
[2] deepwiki-open: github.com/AsyncFuncAI/deepwiki-open
[3] openai: https://platform.openai.com/tokenizer
[4] tree-sitter: https://tree-sitter.github.io/tree-sitter/
往期推荐
持续剖析超级增强：将 Trace/ Span 和 Profile 整合打通
业务需求基础，数据架构就不基础！StarRocks Connect 2025 即将开讲
点分享
点收藏
点点赞
点在看
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：crossoverJie crossoverJie《大模型应用开发必需了解的基本概念》