我觉得这道题其实是在问，你怎么在知识密集的场景下让大模型不胡扯还能实时更新。我的理解是，[[RAG]]本质上就是给大模型配一个外挂知识库，需要的时候去查，查回来再基于这些材料生成答案，这样模型就不需要把所有知识都塞进参数里了。
具体说一下流程。首先是索引构建，把文档切碎成小块，也就是 [[Chunk]]，然后做 [[Embedding]] 存到 [[Vector Database]] 里。这里有个坑，固定切分比如512个字符一刀切，经常把完整语义切散，比如一个退款政策条款被劈成两半，检索召回时只拿到半句话，答案就偏了。所以我会倾向用语义切分，结合结构信息，比如按Markdown标题或段落边界来切。
检索阶段，很多人只做向量检索，但纯向量对专有名词比如订单号、错误码效果很差，因为ID类文本语义相近但字面不同。我的做法是 [[混合检索]]，把 [[BM25]] 关键词和向量检索结合起来，再经过 [[Rerank]] 用 [[Cross-Encoder]] 精排一次，把最相关的前几名挑出来给模型。这样召回质量会明显提升。
然后说RAG和微调的边界。微调适合让模型学会特定格式或风格，比如把回复变成客服语气，但 不适合塞实时知识，因为微调成本高、周期长，而且模型容易学到噪音。RAG适合知识频繁更新、需要引用来源的场景，比如企业内部的SOP和合规文档，今天改了政策明天就能生效。但真正落地常常是RAG加微调一起上，比如先微调让模型学会理解业务术语和对话风格，再通过RAG注入最新数据，两条腿走路。
举个例子，电商客服场景，用户问“我退货了但退款没到账”。如果只用微调，模型可能只能背出标准流程，但查不到这个用户具体订单的退款状态。用RAG，系统先检索该用户的退款政策、当前处理进度，再结合模型生成，就能给出“您的退款已审核通过，预计2个工作日内到账”这种带具体信息的回答。
落地风险方面，我特别关注 召回失败 和 [[幻觉]]。召回失败常见原因是文档分块不合理或者Embedding模型没选对，比如用通用Embedding去处理法律合同，效果就很差。我会先用一批典型query做离线评估，看Recall@K，不达标就调分块策略或换Embedding模型。幻觉多半是检索到的材料不相关或冲突，模型强行编答案。我的做法是加一个 置信度阈值，如果Rerank后最高分都低于阈值，就返回“我无法回答”，而不是硬答。
还有一个方向是[[Agentic RAG]]，就是让模型不只是查一次，而是根据问题自主决定查哪个库、要不要多步推理，比如用户问“为什么我用了满减券但价格还是不对”，模型可能需要先查订单、再查优惠券规则、再查库存价格，这就涉及到 [[ReAct]] 或者 [[Function Calling]] 的配合。这个做起来复杂度高不少，但效果也更灵活。
所以我的判断是，RAG不是银弹，它依赖高质量的知识库和检索链路。我更倾向把RAG看作 一个可插拔的知识接口，核心是保证检索的精度和覆盖率。如果知识源本身乱、更新慢，那RAG效果也不会好。