在近两年来的 AI 技术演进中,检索增强生成(RAG,Retrieval-Augmented Generation)已从技术探索阶段逐步走向产业化应用,成为提升大模型智能体实用性的核心支撑技术。不同于传统大模型依赖内部训练数据生成内容的模式,RAG 通过融合 “外部知识检索” 与 “智能内容生成” 的双重能力,为大模型引入了实时、专业、精准的外部知识源,极大拓展了其在金融、医疗、运维等复杂专业场景中的应用边界。
然而,在 RAG 技术落地过程中,企业往往面临一系列实际挑战:随着知识库规模扩大,检索结果中无关噪音增多,导致准确率下降;部分关键信息因检索策略局限无法被有效召回,完整性不足;专业领域知识的深度适配能力欠缺,难以满足行业级需求;更核心的是,静态知识无法应对动态场景,最终导致大模型 “幻觉” 问题频发,影响业务决策可信度。
本次分享将聚焦 RAG 技术落地的核心痛点,从知识加工的底层逻辑、检索链路的全流程优化两大维度展开,结合实际案例拆解如何通过精细化设计提升 RAG 系统的召回准确率与业务适配性,为企业级 RAG 应用提供可落地的实践方案
一、RAG 技术落地核心痛点与知识检索优化路径
当前企业级 RAG 智能问答应用在实际运营中,常面临四类典型痛点,这些问题直接制约了 RAG 系统的业务价值发挥:
- 知识库文档量激增后,检索结果中混入大量无关信息,有效信息被稀释,召回准确率显著降低;
- 检索策略单一,导致部分与用户需求强相关的信息因 “匹配偏差” 无法被召回,完整性不足;
- 检索结果与用户真实意图的关联性较弱,例如用户询问 “产品售后政策”,却召回大量产品技术参数文档;
- 知识源以静态文档为主,无法实时获取外部动态数据(如实时 API 接口、数据库更新数据),导致系统应答 “滞后且僵化”,难以应对灵活的业务场景。
针对上述痛点,优化需从 “知识处理” 与 “检索流程” 两大核心环节切入,其中知识处理作为 RAG 系统的 “地基”,直接决定了后续检索与生成的上限 —— 只有通过精细化的 ETL(抽取、转换、加载)工作,将非结构化、半结构化、结构化数据转化为标准化的知识资产,才能为高效检索奠定基础。
(一)知识处理:从数据到资产的精细化转化
知识处理的核心目标是将分散、异构的原始数据转化为 “可检索、可理解、可复用” 的知识资产,具体可分为知识加载、切片优化、多元化信息抽取三大关键步骤。
1. 知识加载:精准解析多类型数据
知识加载的核心是突破不同格式文档的解析壁垒,确保数据中包含的文本、表格、图片、公式等信息被完整识别与保留,为后续加工提供完整的数据基础。
优化实践建议:
- 格式统一预处理:将 docx、txt 等非标准文本格式,优先转换为 PDF 或 Markdown 格式。这两类格式不仅能通过 Apache Tika、PyMuPDF 等工具实现高精度文本提取,还能完整保留文档的排版结构(如标题层级、段落分隔);
- 多元素信息提取:针对文档中的表格数据,采用 TableTransformer 等工具将其转换为结构化的 CSV 或 JSON 格式,并与原文位置关联;对于图片、公式,通过 OCR 工具提取描述信息,生成图片链接或 LaTeX 公式代码,统一存储为 Markdown 格式(如
),确保后续检索时能完整调用; - 层级信息保留:提取 PDF 或 Markdown 中的标题层级(如 H1、H2、H3),构建文档的 “目录 - 内容” 映射关系,为后续构建树形索引提供数据支持。

2. 切片(Chunk)优化:保障上下文完整性
切片是将长文档拆分为符合大模型 token 限制的片段(Chunk)的过程,其核心是在 “token 容量” 与 “上下文完整性” 之间找到平衡 —— 若切片过细,会导致语义断裂;若切片过粗,则可能超出大模型上下文窗口,影响检索精度。
优化实践建议:
- 按语义单元拆分:优先以文档标题层级(如 H2 标题下的完整段落)或逻辑章节为拆分依据,避免将同一主题的内容拆分为多个 Chunk;若文档无明确层级,可通过大模型提取段落语义边界,确保每个 Chunk 包含完整的 “问题 - 分析 - 结论” 逻辑链;
- 特殊元素单独切片:将表格、图片、公式等独立信息单元单独拆分为 Chunk,并在其元数据(Metadata)中补充关联信息,如 “表格来源:第 3 章 产品性能参数”“图片描述:服务器故障排查流程图”,便于后续精准检索;
- 自定义分隔符适配:针对技术文档(如 API 手册、代码注释),支持按自定义分隔符(如
===、### 接口定义)拆分,确保技术术语、参数说明等专业信息的完整性。
3. 多元化信息抽取:提升知识资产维度
传统 RAG 仅依赖文本 Embedding 向量进行检索,难以覆盖复杂场景下的语义关联需求。通过多元化信息抽取,可从原始数据中挖掘出知识图谱、文档树、QA 对、元数据等多维度信息,实现 “向量检索 + 语义补充” 的双重保障,显著提升检索效果。
(1)知识图谱:解决专业领域语义关联问题
知识图谱通过 “实体 - 关系 - 实体” 的三元组结构,将分散的知识转化为结构化的语义网络,能有效弥补传统向量检索在 “知识边界完整性”“语义逻辑清晰度” 上的不足,降低大模型幻觉风险。
- 核心优势:
- 明确知识间的逻辑关联(如 “慢 SQL” 与 “数据库抖动” 的因果关系),避免孤立信息导致的理解偏差;
- 为专业领域提供严格的知识约束(如医疗领域的 “疾病 - 症状 - 药物” 关联),确保检索结果的专业性与准确性;
-
适用场景:对知识严谨性要求极高的领域,如医疗诊断、金融风控、IT 运维等,尤其适合需要 “因果推理”“关联分析” 的业务场景;
-
实现路径 :
- 依托大模型(如 GPT-4、通义千问)对文档进行实体与关系抽取,生成初步的 “实体 - 关系 - 实体” 三元组(如 “浙江我武科技 - 所属行业 - 生物医药”);
- 结合业务规则进行人工校验与优化,例如在运维场景中,通过 SOP 流程标准化 “告警类型 - 根因 - 解决方案” 的关联关系,构建高质量领域知识图谱。
(2)文档树(Doc Tree):解决上下文完整性问题
文档树以 “树形结构” 映射文档的层级关系,将标题作为非叶子节点,具体内容作为叶子节点,通过树的遍历算法实现 “关联内容批量召回”,避免因切片过细导致的语义断裂。

- 适用场景:长文档检索(如技术手册、政策文件),需要获取 “某一主题下的完整信息链” 的场景(如用户询问 “服务器故障排查步骤”,需召回 “故障类型识别 - 根因定位 - 解决方案” 的完整章节);
- 实现路径:以文档标题层级为基础构建多叉树,例如将 “H1:数据库运维” 作为根节点,“H2:慢 SQL 处理”“H2:容量规划” 作为子节点,每个子节点下的段落内容作为叶子节点;当用户问题命中某一非叶子节点时,系统自动遍历其所有子节点,召回完整的关联内容。
(3)QA 对抽取:适配 FAQ 场景精准检索

QA 对抽取是将文档中的 “问题 - 答案” 对应关系提前挖掘出来,形成结构化的 FAQ 库,当用户提出相似问题时,可直接召回匹配的答案,跳过复杂的文本解析过程,提升检索效率。
-
适用场景:客服答疑、产品咨询等高频 FAQ 场景,例如 “会员退费流程”“API 调用限额” 等固定问题的快速应答;
-
实现路径 :
- 预定义规则抽取:针对文档中明确标注的 “Q:XXX A:XXX” 格式内容,直接提取为 QA 对;
- 大模型生成:将文档片段输入大模型,Prompt 指令设置为 “基于以下内容,生成 3 个用户可能提出的问题及对应答案”,批量生成 QA 对并补充至知识库。
(4)元数据与总结信息抽取
- 元数据抽取:根据业务需求提取文档的关键属性,如 “文档所属领域(金融 / 医疗)”“更新时间(2024-05-10)”“版本号(V2.1)”“关键词(慢 SQL、数据库)” 等,存储至元数据字段,后续检索时可通过元数据过滤快速缩小范围(如用户询问 “2024 年的产品政策”,可直接过滤掉 2024 年前的文档);
- 总结信息抽取:采用 MapReduce 思想,先对每个 Chunk 生成摘要,再对所有 Chunk 摘要进行整合,生成文档级总结。该总结可用于应对 “文档核心内容是什么” 的全局查询,也可作为检索时的 “粗筛依据”,提升检索效率。

4. 知识处理工作流:支持个性化需求适配
目前 DB-GPT 知识库提供了文档上传 -> 解析 -> 切片 -> Embedding -> 知识图谱三元组抽取 -> 向量数据库存储 -> 图数据库存储等知识加工的能力,但是不具备对文档进行复杂的个性化的信息抽取能力,因此希望通过构建知识加工工作流模版来完成复杂的,可视化的,用户可自定义的知识抽取,转换,加工流程。

(二)RAG 全流程优化:静态知识与动态数据协同
传统 RAG 系统多聚焦于静态文档的检索与生成,难以应对需要实时数据支撑的业务场景(如 “查询实时股票行情”“获取当前服务器 CPU 使用率”)。为此,我们将 RAG 流程优化分为 “静态知识 RAG” 与 “动态数据 RAG” 两大方向,通过 “静态知识打底 + 动态数据补充” 的模式,实现更全面的业务覆盖。
1. 静态知识 RAG 优化:从 “模糊查询” 到 “精准匹配”
静态知识 RAG 的优化核心是 “提升用户意图与检索结果的匹配精度”,通过原始问题处理、元数据过滤、多策略召回、后置过滤四大环节,构建全链路的精准检索体系。

原始问题处理
目的:澄清用户语义,将用户的原始问题从模糊的,意图不清晰的查询优化为含义更丰富的一个可检索的 Query
- 原始问题分类,通过问题分类可以
- LLM 分类 (LLMExtractor)
- 构建 embedding + 逻辑回归实现双塔模型,text2nlu DB-GPT-Hub/src/dbgpt-hub-nlu/README.zh.md at main · eosphoros-ai/DB-GPT-Hub
- tip: 需要高质量的 Embedding 模型,推荐 bge-v1.5-large

- 反问用户,如果语义不清晰将问题再抛给用户进行问题澄清,通过多轮交互
- 通过热搜词库根据语义相关性给用户推荐他想要的问题候选列表
- 槽位提取,目的是获取用户问题中的关键 slot 信息,比如意图,业务属性等等
- LLM 提取 (LLMExtractor)
- 问题改写
- 热搜词库进行改写
- 多轮交互
元数据过滤:缩小检索范围
当我们把索引分成许多 chunks 并且都存储在相同的知识空间里面,检索效率会成为问题。比如用户问 “浙江我武科技公司” 相关信息时,并不想召回其他公司的信息。因此,如果可以通过公司名称元数据属性先进行过滤,就会大大提升效率和相关度。
async def aretrieve(
self, query: str, filters: Optional[MetadataFilters] = None
) -> List[Chunk]:
"""Retrieve knowledge chunks.
Args:
query (str): async query text.
filters: (Optional[MetadataFilters]) metadata filters.
Returns:
List[Chunk]: list of chunks
"""
return await self._aretrieve(query, filters)

多策略混合召回
-
按照优先级召回,分别为不同的检索器定义优先级,检索到内容后立即返回
-
定义不同检索,比如 qa_retriever, doc_tree_retriever 写入到队列里面, 通过队列的先进先出的特性实现优先级召回。
-
多知识索引 / 空间并行召回
-
通过知识的不同索引形式,通过并行召回方式获取候选列表,保证召回完整性。

后置过滤
经过粗筛候选列表后,怎么通过精筛过滤噪音呢
-
无关的候选分片剔除
-
时效性剔除
-
业务属性不满足剔除
-
topk 去重
-
重排序 仅仅靠粗筛的召回还不够,这时候我们需要有一些策略来对检索的结果做重排序,比如把组合相关度、匹配度等因素做一些重新调整,得到更符合我们业务场景的排序。因为在这一步之后,我们就会把结果送给 LLM 进行最终处理了,所以这一部分的结果很重要。
-
使用相关重排序模型进行精筛,可以使用开源的模型,也可以使用带业务语义微调的模型。
-
根据不同索引召回的内容进行业务 RRF 加权综合打分剔除
显示优化 + 兜底话术 / 话题引导
- 让模型使用 markdown 的格式进行输出
基于以下给出的已知信息, 准守规范约束,专业、简要回答用户的问题.
规范约束:
1.如果已知信息包含的图片、链接、表格、代码块等特殊markdown标签格式的信息,确保在答案中包含原文这些图片、链接、表格和代码标签,不要丢弃不要修改,
如:图片格式:, 链接格式:[xxx](xxx), 表格格式:|xxx|xxx|xxx|, 代码格式:```xxx```.
2.如果无法从提供的内容中获取答案, 请说: "知识库中提供的内容不足以回答此问题" 禁止胡乱编造.
3.回答的时候最好按照1.2.3.点进行总结, 并以markdwon格式显示.

2.动态数据 RAG 优化:对接实时业务场景
文档类知识是相对静态的,无法回答个性化以及动态的信息, 需要依赖一些第三方平台工具才可以回答,基于这种情况,我们需要一些动态 RAG 的方法,通过工具资产定义 -> 工具选择 -> 工具校验 -> 工具执行获取动态数据
工具资产库
构建企业领域工具资产库,将散落到各个平台的工具 API,工具脚本进行整合,进而提供智能体端到端的使用能力。比如,除了静态知识库以外,我们可以通过导入工具库的方式进行工具的处理。

工具召回
工具召回沿用静态知识的 RAG 召回的思路,再通过完整的工具执行生命周期来获取工具执行结果。

- 槽位提取:通过传统 nlp 获取 LLM 将用户问题进行解析,包括常用的业务类型,标签,领域模型参数等等。
- 工具选择:沿用静态 RAG 的思路召回,主要有两层,工具名召回和工具参数召回。
- 工具参数召回,和 TableRAG 思路类似,先召回表名,再召回字段名。
- 参数填充:需要根据召回的工具参数定义,和槽位提取出来的参数进行 match
- 可以代码进行填充,也可以让模型进行填充。
- 优化思路:由于各个平台工具的同样的参数的参数名没有统一,也不方便去治理,建议可以先进行一轮领域模型数据扩充,拿到整个领域模型后,需要的参数都会存在。
- 参数校验
- 完整性校验:进行参数个数完整性校验
- 参数规则校验:进行参数名类型,参数值,枚举等等规则校验。
- 参数纠正 / 对齐,这部分主要是为了减少和用户的交互次数,自动化完成用户参数错误纠正,包括大小写规则,枚举规则等等。eg:

二、RAG 落地案例分享
1、运维智能体背景
在数据基础设施领域,有很多运维 SRE,每天会接收到大量的告警,因此很多时间来需要响应应急事件,进而进行故障诊断,然后故障复盘,进而进行经验沉淀。另外一部分时间又需要响应用户咨询,需要他们用他们的知识以及三方平台工具使用经验进行答疑。
因此我们希望通过打造一个数据基础设施的通用智能体来解决告警诊断,答疑的这些问题。

2、严谨专业的 RAG
传统的 RAG + Agent 技术可以解决通用的,确定性没那么高的,单步任务场景。但是面对数据基础设施领域的专业场景,整个检索过程必须是确定,专业和真实的,并且是需要一步一步推理的。

右边是一个通过 NativeRAG 的一个泛泛而谈的总结,可能对于一个普通的用户,对专业的领域知识没那么了解时,可能是有用的信息,但是这部分对于数据基础设施领域的专业人士,就没有什么意义了。因此我们比较了通用的智能体和数据基础设施智能体在 RAG 上面的区别:
- 通用的智能体:传统的 RAG 对知识的严谨和专业性要求没那么高,适用于客服,旅游,平台答疑机器人这样的一些业务场景。
- 数据基础设施智能体:RAG 流程是严谨和专业的,需要专属的 RAG 工作流程,上下文包括 (DB 告警 -> 根因定位 ->应急止血 ->故障恢复),并且需要对专家沉淀的问答和应急经验,进行结构化的抽取,建立层次关系。因此我们选择知识图谱来作为数据承载。
3、知识处理
基于数据基础设施的确定性和特殊性,我们选择通过结合知识图谱来作为诊断应急经验的知识承载。我们通过 SRE 沉淀下来的应急排查事件知识经验 结合应急复盘流程,建立了 DB 应急事件驱动的知识图谱,我们以 DB 抖动为例,影响 DB 抖动的几个事件,包括慢 SQL 问题,容量问题,我们在各个应急事件间建立了层级关系。
最后通过我们通过规范化应急事件规则,一步一步地建立了多源的知识 -> 知识结构化抽取 -> 应急关系抽取 -> 专家审核 -> 知识存储的一套标准化的知识加工体系。

4、知识检索
在智能体检索阶段,我们使用 GraphRAG 作为静态知识检索的承载,因此识别到 DB 抖动异常后,找到了与 DB 抖动异常节点相关的节点作为我们分析依据,由于在知识抽取阶段每一个节点还保留了每个事件的一些元数据信息,包括事件名,事件描述,相关工具,工具参数等等,
因此我们可以通过执行工具的执行生命周期链路来获取返回结果拿到动态数据来作为应急诊断的排查依据。通过这种动静结合的混合召回的方式比纯朴素的 RAG 召回,保障了数据基础设施智能体执行的确定性,专业性和严谨性。

5、AWEL + Agent
最后通过社区 AWEL+AGENT 技术,通过 AGENT 编排的范式,打造了从意图专家 -> 应急诊断专家 -> 诊断根因分析专家。
每个 Agent 的职能都是不一样的,意图专家负责识别解析用户的意图和识别告警信息诊断专家需要通过 GraphRAG 定位到需要分析的根因节点,以及获取具体的根因信息。分析专家需要结合各个根因节点的数据 + 历史分析复盘报告生成诊断分析报告。

三、总结

建议围绕各自领域构建属于自己的领域资产库包括,知识资产,工具资产以及知识图谱资产
- 领域资产: 领域资产包括了领域知识库,领域 API,工具脚本,领域知识图谱。
- 资产处理,整个资产数据链路涉及了领域资产加工,领域资产检索和领域资产评估。
- 非结构化 -> 结构化:有条理地归类,正确地组织知识信息。
- 提取更加丰富的语义信息。
- 资产检索:
- 希望是有层级,优先级的检索而并非单一的检索
- 后置过滤很重要,最好能通过业务语义一些规则进行过滤。
四、如何学习大模型 AI ?
由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。
但是具体到个人,只能说是:
“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。
这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。
我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
这份完整版的大模型 AI 学习资料已经上传优快云,朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】


五、为什么要学习大模型?
我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年,人才缺口已超百万,凸显培养不足。随着AI技术飞速发展,预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。


六、大模型入门到实战全套学习大礼包
1、大模型系统化学习路线
作为学习AI大模型技术的新手,方向至关重要。 正确的学习路线可以为你节省时间,少走弯路;方向不对,努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划,带你从零基础入门到精通!

2、大模型学习书籍&文档
学习AI大模型离不开书籍文档,我精选了一系列大模型技术的书籍和学习文档(电子版),它们由领域内的顶尖专家撰写,内容全面、深入、详尽,为你学习大模型提供坚实的理论基础。

3、AI大模型最新行业报告
2025最新行业报告,针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估,以了解哪些行业更适合引入大模型的技术和应用,以及在哪些方面可以发挥大模型的优势。

4、大模型项目实战&配套源码
学以致用,在项目实战中检验和巩固你所学到的知识,同时为你找工作就业和职业发展打下坚实的基础。

5、大模型大厂面试真题
面试不仅是技术的较量,更需要充分的准备。在你已经掌握了大模型技术之后,就需要开始准备面试,我精心整理了一份大模型面试题库,涵盖当前面试中可能遇到的各种技术问题,让你在面试中游刃有余。

适用人群

第一阶段(10天):初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么?
- 大模型是怎样获得「智能」的?
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例:向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段(30天):高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示(Embeddings)
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段(30天):模型训练
恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。
到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2:手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段(20天):商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身:基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例:如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。
如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。
这份完整版的大模型 AI 学习资料已经上传优快云,朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】

RAG 项目优化实践与大模型应用指南

被折叠的 条评论
为什么被折叠?



