ARTICLE · 1208724
AI 知识库模型的实现:文档分片、向量库、检索与生成
前面我们讲过，模型的上下文长度是有限的。那如果你想让它回答「我司 2024 年报第三页写了什么」，怎么办？总不能把整本书塞进上下文吧。这一篇讲的，就是知识库那套本事。
知识像银杏叶，要一片片捡起来再用。
本文看点
· 为什么预训练模型答不好「自家资料」· 文档为什么要切成一小块一小块（Chunk）· 文本怎么变成向量、怎么存进向量库· 检索为什么比「整篇塞进去」更聪明· 检索和生成怎么分工配合
第 2 篇我们讲过上下文窗口：模型一次能看的文字有上限。一本书几百万字，根本塞不进去；就算塞进去了，成本也高到离谱。
更要命的是：就算塞进去了，模型也不一定能准确定位到你问的那一段。信息太多，它反而会抓不住重点。这就像把一整座图书馆搬进你桌面，你还是找不到那本书。
解决方案不是硬塞，而是：先把文档拆了，建好索引，用到哪段查哪段。这就是知识库（RAG）的核心思路。
先把整片林子拆成一片片叶子，才好挑。
知识库的实现，听起来玄，拆开其实是三步流水线：切块 → 转向量 → 存库。
为什么要分片（Chunk）。一整本书没法检索，得切成一小段一小段，每段几百字。切得太大，检索不精准；切得太小，上下文又不够。这个「切片大小」是个经验值。
什么是文本向量化。就是用一个小模型，把每段文字变成一串数字（向量）。意思相近的文字，向量也相近。这就给每段文字发了一个「语义坐标」。
向量库是干嘛的。就是一个专门存这些向量、能快速算相似度的数据库。你一问问题，它就能从几十万段里，找出语义最像的那几段。
向量像光柱，把语义相近的东西串在一起。
当你提问时，系统先做一件事：把你的问题也转向量，去向量库里找最相近的几段文档。找到之后，把这几段塞进模型的上下文里，再让模型基于这些资料回答。
检索负责「找资料」。它像一个图书管理员，根据你的问题从知识库里翻出最相关的几段原文，递给模型。它不负责写答案。
生成负责「写答案」。模型看到递过来的资料，结合自己的语言能力，组织成一段通顺的回答。它不负责去知识库里翻，只负责写。
为什么要这样分工。因为模型再强也记不住所有资料；检索再准也不会写通顺的人话。两者配合，才能既准又顺。这套组合就叫 RAG（检索增强生成）。
记住一点：知识库的本质不是「让模型读更多书」，而是「每次回答前，先去资料里把相关那几段翻出来」。模型负责写，检索负责找，分工明确。
你会看到现在很多企业 AI 产品都挂着「知识库」三个字。为什么？因为它不用重新训练模型，只要维护好资料和索引，就能让 AI 基于私有资料回答。成本低、更新快、可溯源。
下一篇我们再往前走一步：模型不仅能查资料，还能调用外部工具——查天气、算公式、发请求。那是另一番本事。
会查资料的 AI，脚下的路才走得踏实。
前面说「切块—向量化—检索—生成」是四步。真搭系统时，每一步都有工程师要拍板的数字。
一块切多大。常见做法是每块约 300~500 个 token（折成汉字大概两三百到四百字），相邻两块之间再留 10%~20% 的重叠，避免一句话被从中间切断、前后失联。
向量是几维。embedding 模型吐出来的向量，维度常见 768、1024、1536 这几档——维度越高越细腻，但存储和计算越贵。两段文字像不像，算的是余弦相似度。
先召回几条、再留几条。向量检索先粗筛出 top-k，一般 k 取 3~10；严肃场合再上一个「重排（rerank）」模型精挑一遍，压到 3~5 条真正相关的，才塞进 prompt。
工程师怎么调。块切太大检索不精准，太小又缺上下文；top-k 给多了塞一堆噪音，给少了漏召回——多半从 5~8 条起步试。数字、人名、法条号这类「精确匹配」，纯靠语义向量容易漏，业界通常再叠一层关键词检索（BM25）做混合。
误区一：上了 RAG 就不会幻觉了。不会。检索到的片段喂进去后，大模型仍可能曲解原文、张冠李戴。所以 prompt 里要硬性约束：「只根据给定资料回答，资料里没有就明说不知道」。
误区二：切得越碎越准。孤立的小片段缺上下文，模型容易断章取义。重叠和块大小要一起调，不是越小越好。
模型不是百科全书，而是一个会查资料的聪明人；检索是它的书架，生成是它的笔。
这是《大模型零基础通识》系列的第 15 篇。下一篇讲 工具调用与 API：AI 怎么学会查天气、算公式、调用外部系统？
觉得有用，欢迎点赞、在看、转发给同样在啃 AI 的朋友，也欢迎留言聊聊：你用过带知识库的 AI 产品吗？体验怎么样？
