作者：京东科技 管顺利

后端研发的 AI 突围

作为一名后端研发，开始 AI 之路已经 2 年，从 Chat QA，到 AI Agent 的开发，在到 Multi-Agent，AI-Native。

今年 Q2 开始结合保险业务场景，开始全面 AI 落地。我们的 AI Agent 的能力已跨过 L1（Chatbot），在 L2（Reasoner）全面爆发。

我内心是焦虑的，大模型发展的得太快，尤其是在 Cursor、JoyCode 等产品出来后。我想不止是后端研发，所有的业务研发都会焦虑，因为现在风口不在卷微服务、微前端的架构，全都开始卷 AI 了。 除了 AI Infra 外，模型开发也一样焦虑吧，单一的 Agent 也已是过去式。

我的解药是把微服务架构应用到 AI 上，什么 Agent、Planning、RAG、Evaluation、MCP、LLM、Prompt、Memory、MultiModal 都安排起来。

保险 Eva 的 RAG 架构经历了三个阶段，从基础 RAG 到 Deepsearch，在到混合式检索架构（Graph RAG + DeepSearch + 持续的反思与验证 )****

RAG 架构

历史：

首先我们回顾下什么是 RAG？RAG（Retrieval-Augmented Generation - 检索增强生成 ）是一种构建基于大模型（LLM）应用的创新技术，通过利用外部知识源为 LLM 提供相关上下文，从而减少幻觉现象，提高生成内容的准确性和可靠性。最早要追溯到 2020 年，是由 Facebook AI Research（Meta AI）提出的论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》

基础 RAG 架构，朴素的知识管理员

基础 RAG 是所有 RAG 范式的基础，包括 DeepResearch、Agentic RAG、Graph RAG 都是在基础 RAG 上进化出来的。所以我们先熟悉下基础 RAG 的架构，它包含两个核心组件：生成组件（ETL Pipeline）和检索组件（Retrieval）引入下图为例：

①，②，③，④步骤都是生成组件，它的核心就是文件提取、转换、加载， 我们来一步步分析。

•文件提取（Extract）：核心文件读取器，常用的有 doc、pdf、excel、图片等文件，需要关注对中文支持和 Execl 单元格的处理。

•文件转换（Transform）：文件转换的核心有两个chunk和embedding。

****chunk 阶段尤为关键是所有 RAG 范式的核心，就像切蛋糕一样，切之前就已分配好 ：

常用的分块策略有五种：固定大小分块，语义分块、递归分块，基于文档结构分块，基于大模型分块。

****embedding： 向量化，向量是为了满足相似性查找的需求，比如表达“今天天气如何？”这类的询问方式有很多，这时我们需要将文本向量化，存入到向量库中 ：

数据加载（Load） ： 数据存储，我们用的 Elasticsearch8+（ES）进行混合存储，当然也可以其他向量库和关系型数据库来存储。

⑦，③，④，⑤，⑥步骤是检索组件，它分为预处理、检索、后处理

预处理核心是 Query：要不要做 Query 的扩充？扩充多少？带不带原始 Query？需不需要对 Query 转译？预处理偏向于业务处理，根据需求来，相当于基础 RAG 的一扩展特性，Agentic RAG 范式沿用了这一特性。

检索的核心是算法：基础的检索算法“稀疏算法和稠密算法”

1. 第③步中用相同的嵌入文本块模型，向量化用户的查询

2. 然后，将向量化的查询与数据库中现有的向量进行比较，以找到最相似的信息。常规的向量检索 ANN 算法，我们还支 kNN 算法，向量库的表结构的基础字段索引，向量块，原始文本块，原数据字段。

3. TopK，通过预设的 k 阈值，我们只获取最相似的 k 条原始文本块返回，这是 rank 的流程。

后处理的核心是排序：在精排（Rerank）也就是二段检索，之后会进行文本拼接，把结果拼接到上下文中生成 Prompt，最后由 LLM 生成最终答案（Generate）。

Rerank 不是一个必选项，Rerank 模型会结合查询对检索到的初始文本块列表进行评估，为每个文本块分配一个相关性分数。这一过程会重新排序。

最后一步是生成结果，将原始的查询和检索到的文本块，拼接到 Prompt 中，由大模型生成最终的结果。

以上是基础 RAG 的全流程和技术细节点。从原理上看搭建一套基础 RAG 框架是容易的，但实际上从业务角度出发，搭建一套高性能的框架是完全不同的挑战。

倒退到 2022 年，基础的 RAG 方案是很 OK 的。随之模型发展到现在的 Agentic Agent，需要解决的往往是对复杂问题的深度检索，基础的 RAG 这时显得非常的无力，但也促使 RAG 演进了新的范式：Graph RAG，Agentic RAG，DeepResearch

我们的 RAG 架构

我们的 RAG 产品架构上包含了“保险知识库+记忆库+文件库+智能体+搜索+测评”，是技术驱动由算法，工程，数据一起完成的。

算法 AgenticRAG：我们学习了通义 DeepResearch 的开源 WebWeaver 架构，微软的开源 GraphRAG，结合现在火热的 ZEP、REFRAG 的论文

架构上实现了混合式检索“Agentic RAG+DeepResearch”，记忆实现了“情景记忆+程序记忆+语义记忆+时间记忆”，RAG 智能体矩阵实现了“RAG 查询增强智能体，规划师智能体，工具选择器智能体，反思和验证智能体，基于图结构的智能体，深度研究型智能体”。

记忆设计：语义记忆图谱，程序记忆图谱，情景记忆图谱

工程 RAG 平台：承上启下串联全流程，承接业务 Agent 的检索、查询的需求，提供标准接口让 Agent 专注于模型训练迭代

工程架构分了四层：智能体层，业务逻辑层，检索层，数据层；技术栈：Spring AI ，Elasticsearch8+，Neo4j，Redis，京东云；技术能力支持上支持 Python Code 和 RAG Agent Workflow。

数据架构：保险知识库+记忆库+任务中心 组成三角矩阵

保险知识库架构：

任务中心：

Chunck：学习 Cognee 参数调优的思想，提供了五种 chunk 策略。

记忆库：“语义记忆图谱，程序记忆图谱，情景记忆图谱”在此三类记忆上增加双时间字段，保证记忆的时效性。

为什么这样设计？

我们团队核心是一套由多智能体驱动业务的平台（Eva） 。

•我们是需要 RAG 是因为保险业务，保司的很多数据是网上没有的，并且内容很多，上百页甚至大几百页的文档比比皆是。

•我们是 ToB 业务，是围绕业务发展的 Agent，直面经营结果(规模/利润)。

•我们的 RAG 平台隶属于 Eva 基础能力之一。

未来的 RAG

不再过多揣测未来，乘风破浪即可。

•Agentic RAG 里面包含了 Deepsearch，Graph RAG，基础 RAG，如果感兴趣我会像基础 RAG 一样，一层层剥开和大家交流。

•Python Code 和 RAG Agent Workflow 是工程端的自研核心，如果感兴趣我会像基础 RAG 一样，一层层剥开和大家交流。

•记忆库除了“语义记忆图谱，程序记忆图谱，情景记忆图谱”我们还在研发时间记忆图谱，如果感兴趣我会像基础 RAG 一样，一层层剥开和大家交流。

•Chunck 绝对是核心，以至于让 Cognee 花了大半年时间在参数调优上，我们总结一份配置手册，如果感兴趣我会像基础 RAG 一样，一层层剥开和大家交流。

大家可以把感兴趣的留在评论区，也可以提出你们疑问想法，我们多交流。

参考

https://ragflow.io/docs/dev/

https://github.com/Alibaba-NLP/DeepResearch/blob/main/README.md

https://arxiv.org/pdf/2505.24478

https://arxiv.org/pdf/2501.13956

https://arxiv.org/pdf/2509.01092