LLM
说到LLM大语言模型，相信很多人都不陌生了：
- 本质：依靠海量文本数据训练而成的概率模型
- 能力：能理解和生成文本、代码，还能进行推理、对话等
- 特点：
- 参数固定：训练完成后，相关“记忆”就固定在参数里了
- 知识有时间限制：只掌握训练截止日期之前的数据，存在知识时间节点
可以把LLM看作一个“通用大脑”，但它不一定了解最新信息，也不知道你的私有数据。
现在的AI大模型，本质上还是在做概率预测。你给它一段提示词，它后台的逻辑其实就是：根据之前学习过的海量文字内容，判断接在这段话后面，概率最大的下一个字词是什么。
也正因为这样，大模型每次给出的回答可能不一样，也没办法保证给出的答案百分百准确。
Token
大模型其实并不直接认识java、Rust这些编程语言，也不懂“编程”这个词本身。在模型内部，所有文字都会先被转成一串数字来处理。
字或者词，并不等于token。一个token既不是单个字符，也不是一个完整的单词。
它的切分方式很灵活： 像the、apple这类常见单词，一般就是1个token。 像microservices这种少见的长复合词，可能会被拆成好几个token，比如micro加services。
中文的情况比较特殊，常用汉字一般是1个token，生僻字则可能会占用2到3个token。
在做大模型应用开发时，一定要留意token的使用量，因为这直接关系到计费。
另外还有上下文窗口的限制，每个模型都有最大token上限，比如8k、32k、128k。
如果你的提示词加上模型返回的内容超出了这个限制，模型要么会忘记前面的内容，要么直接报错。
日常开发里可以按这个大致比例估算： 英文文本，1000个token大概对应750个单词。
中文文本，1000个token大约在500到600个汉字之间，而且随着模型词表的优化，现在处理中文的效率也在不断提高。
代码也会消耗token，空格、缩进和特殊符号都会算进去，像Python这类缩进比较多的语言，token消耗通常比纯文本更快。
我们也可以用相关库来计算token，示例代码如下：
RAG
RAG的全称是Retrieval-Augmented Generation，也就是检索增强生成，它并不是像LLM那样的大模型，而是一种技术架构模式。
举个很直观的例子：
你去问ChatGPT你们公司内部的规章制度，它的训练数据里基本不可能包含你们公司的私有信息。
所以它要么随便编一套看起来很像那么回事的内容，要么直接跟你说不知道。
这时候RAG就能派上用场了，它会在你真正调用大模型之前，先去企业内部的资料库，根据你的问题把相关的资料内容查出来，再把这些内容和问题拼在一起，形成完整的提问发给大模型，让大模型基于查到的真实资料来回答。
这么做主要能解决三个问题：
- 解决幻觉问题，大模型遇到不懂的问题，很容易一本正经地瞎编答案。
- 解决知识过时问题，大模型的知识储备只停留在它完成训练的那个时间点，之后的新信息它都不知道。
- 保障私有数据安全，你不可能为了让AI理解业务代码，就把几百万行私有代码交给模型厂商去重新训练，成本太高还不安全。
另外在使用RAG的时候，还得做好数据清洗这一步。就拿我们repo wiki这个场景来说，要把第三方库、编译生成的target目录这类没用的内容过滤掉。
不然检索的时候会把这些无关信息也带进去，影响最终回答的准确性。
向量数据库
前面我们说到RAG模式，里面有个特别关键的组成部分，就是向量数据库。
在RAG里去查找相关的上下文内容，其实就是在向量数据库里进行查询，具体的步骤是这样的：
- 先把文档按段落拆分成一个个小块
- 用Embedding模型把每一个文档块转换成向量
- 再把这些向量保存到向量数据库中
- 当用户提出问题时，同样把问题也转换成向量
- 通过向量之间的相似度，找出最相关的那些文档块
- 最后把这些匹配到的文档块和问题一起交给大模型，让它生成最终答案
简单来讲，就是把图片、视频、文字这类非结构化数据，通过Embedding模型转换成一串数字数组，也就是向量，比如[0.12, -0.59, 0.88, …]。
在查询的时候，也会把要查询的内容转成向量，然后返回向量空间里距离相近的数据。
Q&A
这时候你大概率会冒出这些疑问：
LLM + RAG + 向量数据库，是不是就等于用大模型去训练自己的私有数据？两者效果差不多吗？如果不一样，差别又在哪？
先说说 LLM + RAG + 向量数据库：
本质上是不改动模型本身的参数，先从外部检索相关资料，把查到的内容交给模型，让它结合参考信息再给出回答。
你的私有数据都存在外部的向量数据库里，只是作为参考素材放进提示词里而已。
再看用私有数据做训练，不管是微调还是预训练：
本质是用你的数据去更新模型参数，让模型把这些知识和规律直接“记”在自身里。
你的数据相当于被融进模型权重里，后续使用时不用再单独去查这份数据。
简单来说，用RAG外挂私有向量数据的方式，成本更低，也更灵活。
如果是特别垂直细分的场景，再考虑用私有数据去训练模型。
总结
做完这些项目整体会有一个感受：大模型应用里，大部分代码其实都是围绕提示词在做；普通应用核心是代码逻辑，而不同大模型应用的差别，主要就体现在提示词上，代码部分反而大多都很相似。
区别主要在于用了什么开发框架，共同点都是调用大模型API，把传统应用一来一回的请求响应模式，换成流式响应，毕竟大模型本身返回结果会慢一些。
开发这类应用时，需要搞懂系统提示词、用户提示词，还有少样本示例引导。写好提示词，是让RAG检索结果更准确的关键。
后面我们还会继续完善 deepwiki-open 这个项目：
优化文本分割器，用上更适合代码分割的工具，比如 tree-sitter
把存在本地的向量数据，换成独立部署的向量数据库
持续优化提示词，让它更贴合我们的项目场景
