求大佬指点， 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 的解析，基本没完美的解析方式，因为格式太多了。有效果好的，基本都收费闭源了。。
所以，只能说是将就用。。。完美的是还没有的，只是矮子力拔将军