首先，以业务需求为锚点，而不是一上来就堆技术。因为很多RAG项目失败，就是没搞清楚解决谁的问题。 所以第一步就是拆解三方核心需求。用户希望得到快速准确的答案，别绕弯子；客服团队想减少重复问题的负担，但是不能够给他牺牲服务质量；而业务侧就会更关注成本，可控性，还有知识的更新效率。 采用四层的RAG架构：核心逻辑是先找答案再生成，不去给大模型凭空乱编。 第一个是Query理解还有改写，用户问的模糊的话，系统就要转成精准的检索语句 第二个就是建立高质量的知识库，内容必须结构清晰，更新及时，比如把FAQ还有产品文档、政策文件这些按场景组织好。 第三个是精准的检索+重排序，确保top结果正相关。 第四个就是可控生成，基于检索结果生成，并且加入幻觉控制和兜底的策略，然后其中Query改写是关键前置的环节，直接会影响后面所有的结果。 其他核心功能可以包括： 1、多轮对话，可以让用户自然追问，比如退款要多久，接在那个想退货之后。 2、意图识别和路由，区分是查订单、退换货还是投诉，走不同的处理链路。 3、兜底策略，检索不到或者置信度低的时候就主动的说不确定，并且引导到人工上面 4、人工协调机制，把对话上下文和检索结果一起推给人工客服，提升检索的效率。 从以下几个核心指标验证效果： 1、首次的解决率 2、人工的转接率 3、平均的响应时间 4、用户的满意度 5、建立bad case库，每周复盘，快速迭代 #大模型 #人工智能 #后端 #rag #agent #面试