FDE-Wiki

主题

#RAG#知识图谱#数据工程#评估测试

专题定位:RAG 是企业 AI 系统的"知识地基",也是 FDCE(前沿部署上下文工程)的核心实现。本专题把 RAG 从"能跑"讲到"跑得好、跑得稳",覆盖分块、嵌入、检索、重排、查询改写、GraphRAG、Agentic RAG、评估与工程化的全部实战细节。

一、为什么企业 RAG 比 ChatGPT 难得多 ​

很多人以为 RAG 就是"文档切块 → 嵌入 → 向量检索 → 拼进 prompt"。在企业现场,FDE 很快会发现这个"朴素 RAG"远远不够:

  • 文档脏、杂、长:客户的文档是 PDF/Word/扫描件/Excel/网页混合,表格、公式、图片、跨页,切块就够头疼;
  • 问题刁钻:用户问"去年三季度华东区那个退货率异常的产品",朴素检索根本召不回;
  • 准确性是底线:企业 RAG 答错可能误导决策(法律、医疗、金融),不能像 ChatGPT 那样"差不多就行";
  • 数据量大、要增量:百万级文档,不能每次全量重建,要增量更新;
  • 权限与多租户:不同用户能看到不同文档,检索要带权限过滤;
  • 要可观测、可评估:答错了要能定位是检索问题还是生成问题。

结论:企业 RAG 的难度,90% 在"检索质量 + 工程化",10% 才在"调模型"。FDE 在 RAG 上的价值,正是把这 90% 做扎实。

二、RAG 的四代演进 ​

理解 RAG 进阶,先看它的四代演进:

第一代:朴素 RAG(Naive RAG)

  • 固定长度切块 → 嵌入 → 向量检索 top-k → 拼 prompt;
  • 问题:切块粗暴、检索不准、长文档丢失上下文。

第二代:进阶 RAG(Advanced RAG)

  • 语义/结构化切块 + 混合检索(向量 + BM25)+ 重排 + 查询改写;
  • 解决了大部分准确性问题,是当前企业主流。

第三代:GraphRAG / 模块化 RAG

  • 引入知识图谱,捕捉实体关系;
  • 检索-生成模块化,可插拔;
  • 适合复杂关联推理。

第四代:Agentic RAG

  • Agent 自主决定"检索什么、检索几次、要不要换策略";
  • 适合复杂、多跳问题。

三、分块(Chunking)深度策略 ​

分块是 RAG 准确性的第一道关。 切得不好,再强的模型也救不回来。

常见分块策略

  1. 固定长度切分:每 N 个 token 一块,简单但易切断语义;
  2. 递归字符切分(LangChain RecursiveCharacterTextSplitter):按段落→句子→字符递归,尽量在自然边界切;
  3. 语义切分(SemanticChunking):用嵌入相似度判断语义边界,在语义跳跃处切;
  4. 结构化切分:按文档结构(标题/章节/段落)切,保留层级;
  5. 基于文档解析:用 Unstructured/Marker/Docling 等解析 PDF 结构,按逻辑块切。

分块的关键考量

  • 块大小:太小丢上下文,太大检索噪声多。典型 256—1024 token,需按场景调;
  • 重叠(overlap):相邻块重叠 10%—20%,避免边界信息丢失;
  • 表格/图片:单独处理(表格转 markdown/描述),不要和正文混切;
  • 元数据:每块带来源(文档名、页码、章节),用于引用溯源和权限过滤。

可照抄(递归切分 + 元数据,企业常用):

python
from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512, chunk_overlap=64,
    separators=["\n\n", "\n", "。", ",", " ", ""]
)
chunks = splitter.split_text(doc_text)
# 每块附加元数据:来源、页码、章节、权限标签
for c in chunks:
    c.metadata = {"source": doc_id, "page": page_no,
                  "section": section, "acl": allowed_users}

四、嵌入模型选择与微调 ​

嵌入模型决定"语义能不能对上"。

选型考量

  • 语言:中文优先 bge-large-zh、通义/智谱 embed;英文 OpenAI/Cohere;
  • 维度:高维(1024—1536)精度高但存储/检索成本高;
  • 领域:通用嵌入在专业领域(医疗、法律)可能不准,需领域微调;
  • 指令式嵌入:bge 等支持 instruction,查询和文档用不同指令提升精度。

嵌入微调(进阶) 当通用嵌入在客户领域召回不准时,FDE 可用对比学习微调嵌入:

  • 构造(查询, 相关文档, 不相关文档)三元组;
  • 用 bge 的微调脚本训练;
  • 显著提升领域召回。

五、混合检索:向量 + 关键词 + 结构 ​

单一向量检索不够,企业级用混合检索。

为什么需要混合

  • 向量检索:擅长语义匹配(同义、近义);
  • 关键词检索(BM25):擅长精确匹配(产品型号、人名、编号);
  • 结构检索:元数据过滤(时间、来源、权限)。

混合检索实现

  • 向量库(Milvus/Qdrant)+ 关键词(ES/OpenSearch)并行检索;
  • 用 RRF(Reciprocal Rank Fusion) 融合两路结果;
  • 再用元数据过滤。

可照抄(混合检索 + RRF):

python
vec_results = vec_db.search(query_vec, top_k=20)      # 向量路
kw_results  = bm25_db.search(query_text, top_k=20)    # 关键词路
fused = rrf_fuse([vec_results, kw_results], k=60)     # RRF 融合
filtered = [r for r in fused if r.metadata["acl"] & user_acl]  # 权限过滤

六、重排(Rerank):精排召回结果 ​

重排是提升 RAG 准确性性价比最高的一步。

为什么重排有效

  • 嵌入模型为了速度,用双塔(查询和文档独立编码),精度有限;
  • 重排模型用交叉编码(cross-encoder),查询和文档联合编码,精度高但慢;
  • 策略:先用嵌入粗召回 top-50,再用重排精排 top-5。

重排模型

  • bge-reranker(开源,中文好);
  • Cohere Rerank(商业,强);
  • 国产:通义/智谱 rerank。

ROI:加一个重排,准确率常提升 5—15 个百分点,成本增加很小。这是 FDE 最该先加的一步。

七、查询改写、扩展与分解 ​

用户的原始查询往往不是最好的检索 query。FDE 要做查询优化。

查询改写(Query Rewriting)

  • 用 LLM 把口语化查询改写成更适合检索的关键词;
  • 例:"那个退货多的产品" → "2024 Q3 华东区 退货率 异常 产品"。

查询扩展(Query Expansion)

  • 用 LLM 生成多个相关查询,并行检索,合并结果;
  • 提升召回。

查询分解(Query Decomposition)

  • 复杂问题拆成子问题,分别检索;
  • 例:"对比 A 和 B 两款产品的退货率" → 拆成"A 退货率""B 退货率"。

HyDE(Hypothetical Document Embeddings)

  • 先让 LLM 生成一个"假设答案",用假设答案的嵌入去检索;
  • 适合"问题短但答案长"的场景。

八、GraphRAG:用知识图谱捕捉关系 ​

当问题涉及实体关系时,向量 RAG 力不从心,GraphRAG 上场。

GraphRAG 原理

  • 从文档抽取实体与关系,构建知识图谱;
  • 检索时,既查向量,也查图谱(关系跳转);
  • 适合"X 公司的供应商的竞争对手是谁"这类多跳关系问题。

实现

  • 微软 GraphRAG(开源框架);
  • Neo4j 图数据库;
  • LLM 抽取实体关系。

适用场景

  • 企业关系网络、供应链、人物关系、法律案例关联。

九、Agentic RAG:让 Agent 自主检索 ​

第四代 Agentic RAG,把检索交给 Agent 自主决策。

Agentic RAG 流程

  • Agent 收到问题,判断"要不要检索、检索什么";
  • 检索后评估"够不够",不够再检索(迭代);
  • 可调用多个知识源、工具;
  • 综合多轮检索结果生成答案。

优势:处理复杂、多跳、需要推理的问题。 代价:延迟高、成本高、调试难。

适用场景

  • 研究型问题(投研、尽调);
  • 需要跨多源综合的复杂问答。

十、上下文工程(Context Engineering)方法论 ​

Context Engineering 是 2026 年接棒 Prompt Engineering 的核心能力,也是 FDCE 的实质。

核心思想 模型越来越通用,决定输出质量的是喂给模型的上下文质量。Context Engineering 就是"系统化地构建、管理、优化喂给模型的上下文"。

上下文的组成

  • 指令(system/任务说明);
  • 检索到的知识(RAG);
  • 历史对话/memory;
  • 工具定义(MCP);
  • 结构化约束(输出格式、示例)。

上下文工程的实践

  • 上下文压缩:长上下文要压缩/筛选,避免噪声;
  • 上下文排序:重要信息放前面/后面(模型对位置敏感);
  • 上下文版本管理:上下文也要版本化、可回滚;
  • 上下文质量评估:评估喂进去的上下文是否相关、准确、完整。

FDE 的角色转变:在 Context Engineering 范式下,FDE 的工作重心从"写业务代码"转向"构建高质量上下文管道"。代码可能更少,但对客户业务的理解要更深。

十一、RAG 评估:检索评估 + 生成评估 ​

没有评估的 RAG 是盲目的。FDE 必须建立评估体系。

检索评估

  • 召回率(Recall):相关文档有没有被召回;
  • 精确率(Precision):召回的相不相关;
  • MRR/NDCG:排序质量。

生成评估

  • 忠实度(Faithfulness):答案有没有编造(对照检索内容);
  • 相关性(Relevance):答案有没有回答问题;
  • 完整性:该说的说了没。

端到端评估

  • 人工标注 golden set;
  • LLM-as-judge(用强模型评);
  • 用户反馈(点赞/点踩)。

工具:RAGAS、TruLens、LangSmith eval。

十二、RAG 工程化:增量、多租户、权限、可观测 ​

生产级 RAG 的工程化要点:

增量更新

  • 文档变更时,增量更新向量(不是全量重建);
  • 用文档哈希判断变更;
  • 删除/修改/新增分别处理。

多租户与权限

  • 文档带 ACL(访问控制列表);
  • 检索时按用户权限过滤;
  • 多租户数据隔离。

可观测

  • 每次检索:查询、召回、得分、来源;
  • 每次生成:输入上下文、输出、引用;
  • bad case 收集与归因。

性能

  • 嵌入批量化;
  • 向量库索引优化(HNSW 参数);
  • 缓存(热门查询结果缓存)。

本专题小结 ​

  • 企业 RAG 难在检索质量 + 工程化,90% 工作在这;
  • 四代演进:朴素 → 进阶 → GraphRAG → Agentic;
  • 分块:递归/语义/结构化,带元数据与权限;
  • 嵌入:中文 bge/国产,领域不准可微调;
  • 混合检索:向量 + BM25 + 结构,RRF 融合;
  • 重排:性价比最高的一步,+5—15pp;
  • 查询优化:改写/扩展/分解/HyDE;
  • GraphRAG:实体关系多跳;
  • Agentic RAG:Agent 自主迭代检索;
  • Context Engineering:系统化构建上下文,接棒 Prompt Engineering;
  • 评估:检索(召回/精确)+ 生成(忠实/相关)+ 端到端(RAGAS/TruLens);
  • 工程化:增量、多租户权限、可观测、性能。

本专题来源😮'Reilly《AI Agents Stack 2026》、LangChain/LlamaIndex 文档、RAGAS/TruLens、bge/Milvus/Qdrant 文档、微软 GraphRAG、用户库《FDE Prompt工程模板库》《FDE工程化工具链》《fde-delivery 80-tech-selection/90-agent-design》、本书第 9 章。

本站由原始 Markdown 调研报告自动构建 · 原文未改动

FDE 调研报告 (2026)