AI产品经理必修课：RAG终章——生产级架构、评估体系与优化避坑

核心结论:RAG从演示版本走到生产环境的时候, 那个架构的复杂程度是呈指数级大幅度上升的。产品经理必须去理解那个包括接入层、检索层和生成层在内的三层生产架构。此外, 还必须掌握那四个维度的评估指标。

这四个维度具体是指召回率、精确率、答案的忠实度以及延迟这四项。还要对六个高频容易发生问题的坑做出预判。这一篇内容属于RAG系列的最后一篇文章。这篇文章聚焦在如何让系统在生产环境里落地, 以及如何形成一个效果的闭环上来。

生产级RAG架构与原型的核心差异

在原型阶段的时候, 一般是通过先建立文档, 再进行分块处理, 接着把数据变成向量, 然后去检索相关的内容, 再把检索到的信息拼接起来, 最后才生成结果的这一步一步的线性流水线方式来进行的。而到了生产级别的架构那里, 就需要去解决三个工程层面的问题。

多路检索融合: 现在的人可能搞不懂, 但是单向量检索这种东西, 在结构化数据、数值比较、多跳推理场景下其实是不顶用的, 会失效的。

所以大家在生产环境里需要并行地部署关键词检索（BM25）、向量检索（稠密加稀疏）、图检索（知识图谱）, 然后通过RRF（Reciprocal Rank Fusion）或者学习式融合器把这些结果聚合起来。

对于上下文窗口管理这件事, 我们不能把检索返回的那些排名靠前的片段, 全部都送入到大语言模型里去处理。

这个时候, 我们需要引入一个重排序模型来对候选集合进行二次打分明, 然后选取排在前面的前N个部分来注入到提示词里面去, 通常这个N是不大于5的, 通过这样操作, 能够同时控制住总的token数量不超过模型设定的上下文上限是多少。

流式与缓存: 在处理长文本生成这类场景的时候, 响应速度的快慢是能够非常直接地影响到使用者的那种体验感的。所以, 在实际的生产环境里所搭建的那种系统架构必须得要支持一种叫做流式输出的方式, 这种方式使用的协议包括有比如说像什么SSE或者是WebSocket这类工具。

并且, 对于那些被反复大量提问的问答内容还需要做一层叫做语义缓存的处理, 具体的实现方法往往是借助Redis这种数据存储中间件还有向量相似度的一些判定逻辑来共同完成的。

要是后来的查询结果能够成功在这个缓存里面找到对应的匹配项的话, 那么整个过程就会自动跳过那些需要再进行检索以及需要再去生成内容的环节了。

RAG效果评估体系

评估这事儿, 不能只拿“模型回答是不是读起来很顺溜”这一条来衡量, 得建立一套包含四个维度的、可以拿来量化的指标体系。

给大家推荐的工具链有RAGAS、还有LlamaIndex Evaluation以及Arize Phoenix。其中RAGAS是一个自动评估框架, 而Arize Phoenix则提供可观测性面板服务。

建议在每一个迭代的检索策略更新之后, 一定要去跑通完整的评估流水线, 确认无误之后再上线。这样做是为了避免那种仅凭主观感觉来调整参数方式的错误操作。

六大高频踩坑与对策

1. 分块策略一刀切: 这种固定使用五1二token进行分块的做法, 对于表格类文档、代码类文档以及多轮对话类文档来说, 效果是非常差的。针对这个问题, 对策是要根据文档的具体类型来配置有差异化的分块器, 在处理表格时要保留其结构不变, 在分割代码时则需要按照函数或者类的边界来进行切分。

2. 向量化模型存在不匹配问题: 当前做法是利用通用形式的嵌入方法去处理那些属于特定领域的语料资料, 比如医疗行业和法律文书材料, 这种处理方式会导致语义层面的区分能力不够充分。

相应的解决策略是通过使用带有领域特征的语料来对嵌入模型进行微调操作, 或者转而选择采用具备多向量特性的模型类型, 例如类似于ColBERT架构的模型方案。

3. 提示词中检索片段堆砌: 把排名前二十的那些片段全都堆进提示词里面去, 这样做会让噪声淹没关键的信息。解决办法是重新排序后挑选前五个内容, 并且在使用这些内容的时候添加类似以下的指令来对用户进行约束说明, 也就是“以下材料仅供参考答案”这样的话。

4. 存在缺少引用溯源:的问题, 用户没办法核实答案是从哪里来的, 所以心里的信任程度比较低。作为应对的方法, 就是在系统生成回答的时候, 必须规定要标出来源段落对应的ID代码, 然后在前台显示出来的时候, 要让用户可以点击那个链接, 从而跳转到文章的原文上去看。

5. 知识库更新滞后: 因为索引没有随着文档的改变重新进行构建, 所以检索到的就是过期的信息。对策是建立增量索引管道, 通过让文档变更事件触发局部重用嵌入来进行处理。

6. 忽略多轮对话的上下文信息:在用户追问“它”的价格时, 检索系统丢失了先前的实体内容。建议对策是: 先把对话历史里的指代关系消除掉, 再修改查询语句, 然后才执行检索操作。

产品经理的RAG落地决策框架

对于判断是不是要用RAG这个事, 要先把下面这仞问题回答完了再看。

数据是不是私有的,并且在高频地更新? 要是数据是公开的, 并且状态很稳定, 那用微调技术或者长上下文模型, 可能就更为划算；要是数据属于私有性质, 并且在不断地变化, 那RAG就是不可或缺的需要。

答案是否需要可追溯?在合规的领域, 或者是客户服务的环节, 又或者是涉及医疗的状况之下, 必须要能够去找到来源和依据, 而检索增强生成这种技术呢, 它先天就是天然支持这种要求的状态存在着的。对于那种纯粹的、去进行创意生成的场合来说, 这个方面就不一定非要是必须的条件了。

延迟预算是多少? RAG全链路（包括检索、重排和生成）的P95时间通常是在2秒到4秒这个范围内。如果产品本身有小于1秒响应的需求, 那么就需要对缓存命中率进行优化, 或者把检索的深度往回收、缩减一下。

在给出的三个问题里面, 如果有两个或者更多的答案是肯定的话, 那么推荐大家使用RAG方案, 因为这个方案具备最高的性价比。

对于具体的落地节奏建议大家分成三个阶段来做: 首先是在MVP阶段主要使用单向量检索这种方式并搭配开源的大语言模型去验证核心场景的功能与效果, 然后在灰度时期引入多路检索策略同时还需要加入重排序工具即Rerank, 最后在全量上线阶段要把评估看板补齐还要搭建好增量索引的管道工作流, 针对这三个阶段每一个都给大家预留出2到3周的时间当做缓冲期来应对可能出现的变更或调整机会。

这一篇文章属于“AI产品经理RAG必修课”的最后部分。咱们重新回看整个系列的内容, 第一篇主要负责讲解核心的原理以及各个组件的具体拆解情况, 第二篇则专注于讨论检索策略以及提示工程方面的事物, 而到本篇为止, 主要的内容集中在生产架构的设计、量化的评估工作, 以及实际落地的决策分析这里。

只要能够完全掌握三层架构的特点、四维评估的方法, 并且有效规避六个容易出现的坑, 那么就具备了自己独立主导RAG项目的能力, 能够把这个项目从0开始做到1，接着进行后续的持续迭代操作。

常见问题

《AI产品经理必修课：RAG终章——生产级架构、评估体系与优化避坑》主要讲什么？

核心结论:RAG从演示版本走到生产环境的时候, 那个架构的复杂程度是呈指数级大幅度上升的。产品经理必须去理解那个包括接入层、检索层和生成层在内的三层生产架构。此外, 还必须掌握那四个维度的评估指标。 这四个维度具体是指召回率、精确率、答案的忠实度以及延迟这四项。还要对六个高频容易发生问题的坑做出预判。这一篇内容属于RA

AI 人工智能相关内容，适合谁看？

适合关注AI 人工智能的读者，尤其是需要落地执行的运营和建站从业者。