夜雨聆风说到AI应用，我发现一个现象：很多产品经理聊起大模型眉飞色舞，一说到 RAG 和知识库，却总停留在“把文档扔进去就能问答”的水平。而真正让大模型在企业场景落地的核心，恰恰需要这个“检索增强”的武器来把知识库武装一遍。这篇文章想用最直白的方式，把我对 RAG 和知识库的理解梳理出来，以便大家学习交流。
一、RAG 不是个“功能”，是一套开卷考试系统
先给 RAG 下一个产品经理听得懂的定义：大模型本身是个记忆力超强但知识停留在训练截止日的闭卷考生，RAG 则是让它在答题时可以现场翻书。书就是你的知识库，翻书的动作叫检索，对照书本组织答案的过程就是增强生成。
技术细节简化到极致就三步：
用户提问题
系统去知识库里检索出最相关的几段文本（比如 “段落1、段落3、段落7”）
把这些文本和用户问题一起塞进 Prompt，让大模型结合参考资料回答
效果立竿见影：幻觉明显降低，答案可以溯源，私域数据终于能产生价值。可这背后藏着一大堆足以决定产品生死的细节——知识库绝不是“扔进去就完了”的东西。
二、知识库真正的挑战：分块和语义指纹
知识库之所以能“翻书”，靠的不是关键词匹配，而是语义搜索。它的原理是把每段文本变成一串固定长度的数字（Embedding，也叫向量嵌入，可以理解为“语义指纹”），然后通过余弦相似度，欧氏距离等数学工具分析向量夹角和距离计算文本向量相似度。
这里有三个产品经理必须较真的点：
1. 文档分块（Chunking）
你不可能把一本几百页的教材不分段就转成向量，太大抓不住重点，太小丢失上下文。早期我们一刀切 500 字，结果学生问“二次函数的顶点公式怎么推导”，检索出来的片段要么只有公式没有推导过程，要么只有例题缺少定义。后来改成按小节切分并加 50 字重叠，准确率立刻就上来了。不同文档类型（教材、课件、考纲、政策文件）得分策略设计，这是持续打磨的产品活。
2. Embedding 模型的选择
不是所有向量生来平等。有的模型擅长短句，有的适合长文本，有的对中文语义近义词友好。我踩过的坑：拿一个通用英文 Embedding 模型处理中文教育内容，学生搜“勾股定理”完全找不到讲“毕达哥拉斯定理”的文档。后来替换为针对中文优化的模型并加入同义词表，召回率提高 15%。产品经理不用会训模型，但得知道验证：手动构造一批你明确知道应该在 Top3 出现的 Query，测不同模型的召回效果。
3. 不仅是数据库，而是“记忆体”
知识库需要迭代维护。过期的政策、被勘误的文档，必须实时下架，否则就是批量制造错误答案。我们为一个在线学习平台做知识库，光数据清洗就花了两周，里面存在大量重复、格式混乱和互相矛盾的内容（比如同一门课有两版不同的考试说明）。一旦污染了检索源，大模型再强也只会一本正经地胡说八道。
三、产品经理要盯住的“增强检索”流水线
把流程拆开看，RAG产品的核心竞争力就在于这条流水线的设计：
查询改写：用户询问"如何退课"时，系统应自动将其扩展为"用户申请退订课程的操作流程说明"。这一步至关重要，若省略将导致后续流程偏离正轨。除查询改写外，意图识别是另一个相似的重要策略，但需根据项目规模和实际应用场景来评估其必要性。
多路召回：向量召回语义相关，关键词召回（BM25）精确命中专有名词，两路结果合并去重。我们试过只靠向量，问课程编号“XXX-101”老返回相似度勉强及格但根本不是这门课的文档，加上关键词匹配马上解决。
重排序（Rerank）：粗召回（从知识库中“捞”出一批可能相关的文档或片段的过程）可能返回 20 条片段，用重排序模型精筛出最相关的 3 条，速度和效果的最佳平衡点。
提示词模板：规定大模型“基于以下资料回答，如果资料不包含则直接说不知道”，并严格引用片段编号，这才能让溯源落地。
上下文窗口控制：检索片段+对话历史+系统提示词，总 token 数必须远低于模型上限，否则大模型“失忆”。我们曾因没算好，线上对话超过 5 轮答案开始飘，查了半天才定位到是被长历史撑爆了窗口。
一条稳定的 RAG 链路，就是不断在这些环节做实验、看指标、调参数。它本质上是检索系统工程 + 数据运营，而非单纯的算法工作。
四、给产品踩坑者的评估与迭代心法
很多团队喜欢凭感觉拍 RAG 好不好，这是大忌。可以通过如下的“三个维度”分析评估：
忠实度：答案是否能从提供的资料片段中推断出来，有没有额外发挥。这是反幻觉的底线。
相关度：答案是否准确回答了用户问题，有没有答非所问。
覆盖度：知识库中有正确答案时，检索环节能不能把它真正捞上来。
落地上，用 RAGAS 这类开源框架跑自动化评分，同时每周固定抽出 50 条真实会话做人工打分。初期我们的系统自动评分 85，人工却只给 60，因为用户问“这门课学完能达到什么水平”，系统给出了“掌握核心技能”这种空话——根本原因是知识库里没有明确的课程目标描述，系统在强行联想。最终我们补充了教学大纲中的“学习成果”章节，人工分直接拉到 92。
更重要的是，产品经理必须建立“Bad Case集 → 知识库优化”的数据飞轮。每个“踩”的反馈，都必须能追溯到是缺文档、分块不优还是提示词没约束到位，然后驱动修复。这感觉有点像做搜索策略产品，既要懂意图，又要懂内容。
五、用 MVP 思维启动你的 RAG 项目
我不建议一上来就追求复杂架构，追求完美。用最小可行产品方法：
划出 20 个最高频、最封闭场景的问题（比如学生问“怎么查看考试成绩”“如何申请缓考”）。
整理 10 篇高质量的核心文档做知识库（比如学生手册、课程大纲、常见问题解答）。
用 Dify 或 LangChain 搭一条最简链路：固定分块 400 字，向量召回 Top5，不用任何改写和重排。
让真实用户测三天，记录所有不满意答案，看问题分布：是没召回、还是召回了但模型没用上、还是知识库里压根没有。
我们内部一个教务问答机器人，只用 3 天跑通了流程，上线第一周解决了 60% 的重复咨询，然后依据数据再逐步加入查询改写和多路召回。MVP 的目的不是完美，是快速可视化和低成本试错，对产品经理来说，能亲眼看着“哪段文档害答案变差”比听十场技术分享都有用。
六、最后说点实在的
不要把 RAG 当成万能药。它的边界非常清晰：如果知识库本身没有高质量内容，RAG 救不了你；如果用户需求是深度推理而非事实查询，RAG 帮不上太大忙。产品设计上，对那些必须 100% 准确的回答（如退课截止日期、考试分数规则），我倾向于直接用规则兜底，而不是让检索叠加生成去冒险。
另外，RAG 增加了一次检索的延时和 LLM 额外的 prompt token 成本，计算一下每轮问答比纯生成多了几毛，规模化时要掂量。
我们应该把知识库当作一个需要持续运营和关爱的“宠物”，而不是一劳永逸的文件垃圾场。技术决定下限，但数据和场景设计才能拉高上线。理解了这些，再去用工具、拆论文，你会发现所有技巧都围绕着“怎样让大模型翻到正确的那一页书”。
如果你想动手体会，建议打开在线 RAG 沙箱，上传一份测试资源，用不同的分块大小、TopK 数值亲自测几组问题，体会检索结果的变化。这份体感，比任何文章都来得深刻。
