求大佬指点， ai 加知识库的内部原理

原理就是解析文件形成上下文记忆啊

首先，我们知道，和大模型聊天的时候，我们可以设计 prompt,例如:
请结合以下上下文内容，回答用户问题:
```
context
```
用户问题如下：
query

-----
那么，上传文档变成知识库，就是把文档分段，使用向量数据库存起来。当用户提问的时候(假设内容叫 query)，拿 query 内容通过向量搜索找到相关的知识片段,组合成 context,拼到上面类似的 prompt 里面一起给大模型回答。
另外，向量数据库搜索只是比较通用的一种方式。知识怎么分段怎么存，你可以自己设计比如存关系数据库都没问题。

最简单来说，就是文档切片转为向量存入向量数据库，Query 也转为向量，从向量库找出最相似的切分，文本拼接起来给 LLM 模型回答问题。

当然实际肯定比这个要复杂。

把你提供的文档 根据一定的规则拆成片段，通过一个模型（ embedding 模型）转成向量，存起来就变成了知识库。这个过程类比 es 一类的搜索引擎，只不过常规搜索引擎是分词，他这个是向量。

当你问了一个问题，把你的问题也转成向量，和知识库里面的数据做向量计算，拿到最相似的，拼到上下文中，发给大模型，让大模型回答给你。

尤你的 AI 前端程序（不是模型）在知识库搜索内容，然后插到聊天记录里面

矢量数据库，调好参数把数据扔进去解析，聊天的时候触发关键字去矢量数据库拿命中数据添加到上下文再聊天，好不好用全靠参数调的好不好

就是一个搜索引擎，从你的文档中选取和你问题最相关的段落连带着你的问题发给 LLM ，让 LLM 基于文档去回答你的问题。
可以说搜索这部分和 AI 一点关系都没有

我也想知道；例如我把我博客文章全部给 ai ，让 ai 根据我给它的数据，每次问它能找到对应的文章。该如何实现？最好能封装一个 api

模型貌似是无状态的，可以理解外靠外挂向量数据库来构建每一次的提问。

你每次问之前，外部程序都会先从自己的提问历史结合向量数据库构造出完整的上下文，再打包发给模型。

我之前还想调用 ollama 的 api ，想着应该会有个 token id 之类的，后面发现没有，想维持上下文，得把之前得提问历史也需要一并发过去给模型，相当于模型只是纯思考的机器，上下文还是得靠外部程序来构建。

小白问一下，那要是知识库很大，上下文很多，token 岂不是消耗很快？应该涉及多次问答会不会重复发送上下文？

RAG

嵌入模型是用来把文字转成向量的，这样就可以把文字的相似度匹配转成向量的相似度匹配，这样一来更快，二来还能匹配语义上相似但实际不同的句子。

@moyufjm123 #12 会返回知识库的 top k ，不会整个知识库一起给到大模型

小白再问一下，大语言模型是基于概率预测的，那即使有知识库，它一定能返回和知识库内容完全一样的结果么？比如让它基于条件选择合适的 row 并把知识库这一行完整返回来

@chairuosen 我用 deepseek 试过，可以把知识库作为提示词一部分喂给他，基本上回答没啥问题，比别的 AI 模型要聪明。就是比较费 token 。

@moyufjm123

> 那要是知识库很大，上下文很多，token 岂不是消耗很快？

理论上是的，但是一般来讲，只有被匹配到的一段文本（和它们的上下文）会被发送给 LLM ，而且很多工具只会发送匹配度最高的 N 段文本，当然代价就是准确性降低。

> 涉及多次问答会不会重复发送上下文？

会，但有的模型是支持缓存的，比如 OpenAI 和 DeepSeek 连续对话时会自动缓存上下文，命中缓存就有折扣。不过也有模型比如 Claude 和 Gemini 得手动触发缓存，很多工具压根就没有适配……

@moyufjm123 如果知识库很大，会改用微调大模型，这方法不合适。这方法就是很消耗 token ，没办法。

这种基础的问题，你询问 AI 会更快一些...

好的了解，谢谢各位大佬解答

其实知识库的重点应该是文本的切片和向量化，尽可能使查询匹配的结果更精确

低于 token 的消耗，其实很多时候有了精确的匹配之后使用小型的模型也是可以的，而且小模型部署较为简单，也不必去担心持续大量的 token 消耗了

这个算是很基础的 RAG 了，粗暴的喂给大模型，其实还可以把文本转化为知识图谱，做图检索，如 https://arxiv.org/abs/2410.05779 还有领英这个 https://arxiv.org/abs/2404.17723

这里涉及两种模型，一种是 embedding 模型（又叫嵌入模型、向量模型等），一种是大语言模型（就是 LLM ，如 deepseek-r1 ）

原理前面的大佬都解释得很清楚了：
1. 上传知识库，用嵌入模型把知识库内容分词、向量化，存到向量数据库
2. 用户提问时，也调用嵌入模型，把提问内容分词、向量化，和向量数据库的内容进行匹配，找出相关性最高的若干个片段
3. 把用户问题和匹配到的知识内容共同作为提示词，发送给 LLM
4. LLM 基于提供的内容回答问题

原理前面的大佬解释的很好了，下面是我从 deepseek 查到的，对普通无 AI 基础的开发更友好的解释：

用大模型结合用户文档构建问答知识库，核心原理可以用“图书馆+翻译官”的类比来理解，对普通开发者来说主要分三步：

文档预处理（类似图书编目）

把你的 PDF/Word 等文档拆成小段落（类似给每本书分章节）
用嵌入模型将文字转成向量坐标（相当于给每本书贴上精确的地理坐标）
存入向量数据库（相当于建立图书馆的索引系统）
问答过程（类似图书检索）

用户提问时，先将问题转成向量坐标
在向量数据库里找坐标最近的文档段落（类似 GPS 定位最近的图书）
只把相关段落喂给大模型（而不是整个图书馆）
答案生成（像翻译官工作）

大模型将专业文档"翻译"成人话
结合找到的段落内容生成最终回答
整个过程类似你给翻译官几页参考资料，让他帮忙解释某个问题
关于 token 消耗的关键事实：

预处理阶段（向量化）是单次成本
每次问答的 token 消耗=提问长度+检索到的文档长度+回答长度

相比直接微调大模型（需数万元成本），这种方案首次构建成本通常不超过千元，且支持动态更新文档。核心开发难点在于处理 PDF 解析和设计高效的检索策略，对熟悉 Web 开发的工程师来说，主要工作量在系统集成而非 AI 算法本身。

说实话 ，你不如把你这些疑惑都去问 deepseek ，任何一丁点不清楚的都去问，比论坛这种你一言我一嘴的回答有意义的多了。

最近这本书比较火，看看是不是有帮助
https://nndl.github.io/nndl-book.pdf

感觉用这种上下文会耗大量 token,这个确实是个问题啊。
=======
所以很多知识库的场景都是私有化部署，其实知识库很多时候 32b ，14b 的也够用了

@tool2dx #17 比较费 token 的话，独立部署可以解决么？
有个点没太明白，个人的知识库，应该不用那么多参数的 deepseek 模型就行吧（比如 7B ），这样是不是就可以解决 token 不够的问题了？

@sm0king 个人理解：比较费 token 的本质是费算力，本地部署使用的是自己的算力，只要你有足够的算力和电力那应该无所谓吧

嵌入模型是用来检索的。LLM 依赖的 Transformer 架构的时空复杂度是和序列长度 O(N^2)的，所以不太能把知识库所有的语料都放进去。

静态嵌入模型在这里本质上是做语义相似度，把和你要查询的内容相关的文本找出来再喂给 LLM ，因为静态嵌入模型和上下文无关，所以预先计算成向量，然后再和你的查询转换成的计算相似度就可以了。

另一件事情是，LLM 并不是输入越多信息越好，所以用另一个模型帮它做精简。

@sm0king 7B 理解能力堪忧，本来第三方知识库就不属于常用的知识领域范畴，要有点智商才能理解。

token 本地部署确实可以解决开销问题，但想要做到和官方 API 效果一样，感觉挺难的。

就是找出相关内容然后字符串拼接，看 llamaindex 代码就懂了，知识库都是围绕那三五十行代码做各种业务和 UI 的封装。
https://github.com/run-llama/llama_index/blob/81d4b871143ddd4a7cb90333a3d103fbb1f269c5/llama-index-core/llama_index/core/prompts/chat_prompts.py#L21

消耗 token 那是肯定的，所以去年 5 月 deepseek 把价格打到几乎是全行业的 1%，搞得其它几家也跟着降价，不然现在哪有那么多知识库的需求。

本质就是 ai 知道的不多，你得给他你需要他聚焦的题。
但现在的整个知识库发展有个巨大的坑：怎么匹配的问题。这是所有从业者都在努力去优化的，最少现阶段还没完美的在性能，费用，效果三者之间取得完美的结合。
匹配就是很大可能把两个完全不匹配的块当相关块发出去。这是第一个不好用的点，算法一直在优化。
另一个就是上下文限制的问题，和文本解析的问题。这又是一个大坑。比如 PDF 的解析，基本没完美的解析方式，因为格式太多了。有效果好的，基本都收费闭源了。。
所以，只能说是将就用。。。完美的是还没有的，只是矮子力拔将军