很多人以为，RAG（检索增强）只是：
“查点资料 + 丢给大模型”
但在真实系统中，一次请求远比这复杂。
这篇文章不讲概念，而是回答一个更具体的问题：
当用户发出一个问题时，系统内部到底发生了什么？
一、从一个请求开始
假设用户输入：
“公司的报销流程是什么？”
在一个典型 RAG 系统中，这个请求不会直接进入模型，而是会经历一整条处理链路：
Query ↓ Embedding ↓ 检索（向量 / 关键词） ↓ 候选结果（Top-K） ↓ Rerank（精排） ↓ Prompt 构造 ↓ LLM 生成 ↓ 返回结果
复制
关键认知：
这不是“一次模型调用”，而是：
一条完整的数据处理流水线（Pipeline）
二、Embedding：不是编码，而是“信息压缩”
第一步：
把 Query 转成向量
很多人把它当作“编码”，但更准确的理解是：
Embedding = 有损语义压缩
会发生什么？
- 原始文本 → 高维向量（768 / 1024 维）
- 语义被“映射”，而不是完整保留
- 细节信息会丢失
一个典型现象：
- “报销流程”
- “费用审批”
在不同模型中：
- 可能很接近
- 也可能偏离
工程结论：
Embedding 决定了召回的“天花板”
如果这一步错了，后面全错。
三、检索：为什么只用向量一定不够
最常见实现：
Top-K 向量相似度搜索
但它有天然缺陷：
向量检索的问题
- 无法精确匹配关键词
- 对结构化字段无感（如时间 / ID）
- 对长尾问题极其不稳定
工程真实做法
Hybrid Retrieval = 向量检索 + 关键词检索 + 规则过滤
复制
示例架构
关键认知：
向量解决“语义相似” 关键词解决“精确命中”
四、Rerank：被低估的一步
很多 Demo 没有这一步，但在真实系统中，它是：
效果分水岭
Rerank 在做什么？
输入：
- Query
- Top-K 文档
输出：
- 排序更准确的 Top-N
为什么必须要？
因为：
- Embedding 是“粗筛”
- Rerank 是“精排”
常见问题（没有 Rerank）：
- 看起来相关，但其实没用
- 噪声进入 Prompt
- 模型被误导
一句话总结：
检索决定“有没有”，Rerank 决定“准不准”
五、Prompt 构造：真正的输入设计
这一阶段，本质是：
构造模型的上下文输入
做的事情：
- 拼接检索结果
- 控制 token 数量
- 加入系统指令
但核心问题不是 Prompt 技巧，而是：
信息选择策略
常见坑：
- 上下文太多 → 模型抓不到重点
- 上下文不准 → 幻觉
- 顺序混乱 → 理解错误
更本质的理解：
Prompt ≠ 文本
Prompt = 信息压缩后的结构
六、LLM：只是系统中的一个组件
很多人以为：
模型输出 = 结束
但在工程系统中，通常还有：
后处理阶段：
- 格式化（JSON / Markdown）
- 截断 / 清洗
- 敏感内容过滤
- 置信度判断
甚至包括：
- fallback（降级到规则 / FAQ）
- retry（换模型 / 换参数）
- 多模型投票（Ensemble）
关键认知：
LLM 不是系统本身，而是系统中的一个模块
七、为什么你的 RAG 效果不稳定？
我们可以把整个流程抽象为：
常见问题定位：
- Embedding 不匹配 → 语义偏差
- 检索策略单一 → 召回不足
- 缺少 Rerank → 排序错误
- Prompt 构造问题 → 上下文污染
很少是因为：
“模型不够强”
这是一个典型误区
八、一个更重要的结论
如果你把 RAG 看成：
“给模型加点资料”
那它大概率做不好。
但如果你把它看成：
一个完整的信息检索 + 生成系统
你才会开始真正关注：
- 数据结构设计
- 检索策略组合
- 系统可控性
- 可观测性（日志 / tracing）
这也是从 Demo 到生产系统的分水岭。
九、下一篇
下一篇我们继续往下拆：
为什么 Chunk（分块）策略，决定 RAG 的效果上限？
会重点讲：
- chunk 大小 vs 召回质量
- overlap 是否真的必要
- 如何针对业务做分块设计
结尾
很多人以为，RAG 是：
RAG 的本质，不是“增强模型”，
而是“约束模型”。
当你开始从“系统”而不是“模型”去理解它时， 你才真正进入了 AI 工程的核心区。
