一句话原理：让模型开卷考试
大模型自己的知识停在训练截止那天，你们公司的产品文档它更是闻所未闻。RAG 的思路很朴素：用户提问时，先去知识库里检索相关片段，把片段和问题一起塞给模型，让它照着资料回答。闭卷改开卷，一句话说完。
拆开看就三步：文档切成小块、算成向量存进库里；用户提问也算成向量，按相似度捞出最相关的几段；把这些段落贴进 prompt 让模型作答。工程细节很多，但 PM 理解这三步，就够定位大部分问题了。
这一步解决了三个痛点：私有知识，模型没学过的东西现在有出处了；时效性，知识库今天更新，明天就能答；可溯源，答案能挂引用，幻觉率跟着降。Perplexity 这个产品，本质上就是给大模型接了个实时搜索的 RAG。
适合什么场景
判断标准一句话：答案能从明确的文档里找到出处的问题，适合 RAG。
企业知识库问答，「年假怎么算」翻员工手册；客服机器人，「这个型号支不支持以旧换新」翻商品库；法律、医疗文献助手，回答必须引到具体条文。飞书、钉钉里那些对着公司文档问答的 AI 功能，底下都是这套架构。
但「适合」有个前提：知识库本身得是健康的。很多企业兴冲冲要上知识库问答，一盘点发现文档三年没更新、同一个问题三个部门三种说法。这种时候第一笔预算该花在知识治理上，不是买向量数据库。
反过来说，答案不在任何一份具体文档里的问题，RAG 就帮不上忙。
局限比宣传的大
第一，检索质量决定上限。垃圾进垃圾出，检错了资料，模型照着错资料答得理直气壮。实际项目里，答案不对的 case 一多半错在检索环节，不在生成环节。
第二，切分伤上下文。文档要切成小块才能入库，表格被拦腰切断、段落脱离章节归属，检索回来的东西经常是残的。
第三，有几类问题天然不擅长。汇总类的不行，「把全年销售趋势总结一下」该走 SQL 和报表，不是把十二个月的数据切片塞给模型。多跳的不行，「A 项目的负责人还参与过哪些项目」要连查好几步，单次检索覆盖不了。全局理解类的勉强，「这份合同整体有什么风险」需要通读全文，RAG 只给它看了几段。
第四，权限容易踩坑。企业里不同人能看的文档不一样，检索必须在权限过滤之后做，不然实习生问一句「公司平均薪酬」，模型把 HR 文档捞出来了。这个坑不在算法，在方案设计。
第五，embedding 模型有语言偏向。中英混合的知识库选错模型，中文问题检不回英文文档，这类隐性损耗排查起来很费劲，选型时就要测。
PM 要盯的指标和取舍
三个指标：召回命中率，正确资料检没检到；答案正确率，端到端对不对；引用准确率，标来源标对了没。出问题先查第一个，别急着怪模型。
上线前先建个百来条的评测集，每条问题标注好标准答案出自哪篇文档，这样召回命中率才算得出来。没有这个评测集，所有优化都是盲人摸象。
成本账也要算。文档解析、切分、向量化、存储，都是工程量和钱。知识库更新链路要提前定死：文档改了多久生效？我见过知识库月更的团队，AI 一直拿着过期政策回答用户，比没有 AI 还糟。
还有一个很现实的取舍：文档量小，几十页以内，直接塞进长上下文可能比建 RAG 便宜；量大、更新频繁，才值得上完整的检索架构。经验上几十万字以下可以试全塞，再往上 RAG 的综合成本明显占优。
最后提醒一个组织层面的坑：RAG 项目的效果瓶颈经常不在技术，在知识库的运营归属。文档没人维护、过期没人下架，技术再好也救不回来。立项时就要把知识运营的责任人和更新时效定下来，这是 PM 该拍板的事。