面经策

RAG 的完整流程是怎么样的？ ​

  • 标签：AI、大模型、RAG

🏛 业务架构师 ​

我把 RAG 完整流程按业务流水线来讲：

1. 知识接入：多源文档（PDF、Word、Confluence、网页）解析、清洗，去页眉页脚水印噪声。 2. 切分：按语义/结构分块，兼顾上下文完整性。 3. 向量化：用 Embedding 模型把切块编码为向量。 4. 入库：写入向量数据库，通常附带部门、时间、密级等业务元数据。 5. 检索：用户提问先经改写/扩展，再混合检索（向量+关键词）取回候选，可加 Rerank 精排和元数据过滤。 6. 生成：把 Top-K 内容装配进 Prompt，约束模型"仅依据资料回答"。 7. 评估反馈：用命中率、忠实度指标持续调优切块和检索参数。

业务本质：RAG 的价值是把企业的私有知识变成"模型外挂的活字典"——知识可随时更新、可溯源引用、数据不出域，这三点正好命中企业落地的三大顾虑（时效、可信、合规），所以它成为 2026 年企业 AI 落地的第一站。我的建议是先用 RAG 解决 80% 的知识类需求，剩下 20% 风格化、强约束的场景才考虑微调。

🏗 系统架构师 ​

我把生产级 RAG 分成离线链路和在线链路两段，这是架构上最重要的切分——两条链路解耦，才能独立扩缩容和迭代。

离线（建库）：文档接入 → 解析（PDF/Word/HTML，表格特殊处理）→ 清洗（去页眉页脚、去重）→ 分块（结构化切块 + 语义重叠）→ Embedding 向量化 → 写入向量库（附带元数据：来源、权限、时间、版本）。

在线（查询）：用户 query → 预处理（改写、扩展、HyDE、意图识别）→ 混合检索（向量 + BM25 + 元数据过滤）→ Rerank 精排 → 上下文组装（截断、去重、按相关性排序）→ LLM 生成（带引用要求）→ 后处理（事实校验、引用对齐、敏感词）→ 返回。

架构上我坚持的三个原则：一是权限过滤必须在检索层做（pre-filter），不能检索完再过滤，否则既泄露片段又浪费窗口预算；二是每一步打日志埋点，检索质量和生成质量分开归因，没有可观测的 RAG 没法迭代；三是离线链路做成幂等任务流（文档版本化），支持增量更新而不是全量重建。

量级参考：在线链路 P95 目标 2~4s（LLM 占大头），检索部分控制在 200ms 内。

💻 全栈开发专家 ​

我把 RAG 拆成离线索引和在线问答两条流水线讲，这是工程上的真实切分：

离线（数据管道）：文档接入 → 解析（PDF/Word 转 Markdown）→ 清洗去重 → 分块（chunk 512~1024 token，overlap 10%）→ Embedding 向量化 → 写入向量库（带 source、时间、部门等元数据）。

在线（查询管道）：用户 query → 预处理（改写/扩展/指代消解）→ 检索（向量 + BM25 混合）→ Rerank 精排取 top 3~5 → 拼 Prompt（「仅依据以下上下文回答并标注引用」）→ LLM 生成 → 引用溯源返回。

用 Spring AI 表达在线侧大概是：

java
String content = SearchAssistant.prompt()
    .user(u -> u.text("{query}").param("query", question))
    .advisors(a -> a.param(FILTER_EXPRESSION, "dept=='sales'"))
    .call().content();

关键提醒：新手容易把 90% 时间花在生成侧 Prompt，实际上效果瓶颈 80% 在检索侧。先建一个 50~100 条的 golden set 评测集，用 recall@k 卡住检索质量，再去调生成，顺序不能反。另一个坑是文档解析质量——扫描版 PDF 不上 OCR 和版面分析，后面全白搭。