目录
- 大模型原生缺陷:为什么需要 RAG?
- RAG 核心五步流水线拆解
- 向量数据库选型对照表(Demo / 生产 / 分布式场景)
- RAG 怎么评估好坏?不能靠主观感受
- 企业落地最容易踩的 3 个大坑
- RAG 进阶玩法:Query 改写、GraphRAG、Agentic RAG
- 一句话总结
1. 大模型原生缺陷:为什么需要 RAG?
原生大模型相当于闭卷考试,存在 3 个硬伤:
- 知识过时:训练结束之后的新内容,模型不知道
- 幻觉:不知道的内容,也会编造答案硬输出
- 私有知识盲区:无法直接读取企业内部文档、业务资料
✅ RAG 思路:把 AI 变成开卷考试,先检索参考资料,再基于资料回答,只能减少幻觉,不能归零。输出答案需要附带引用溯源,没有资料就如实说不知道。
2. RAG 核心五步流水线拆解
完整链路:切碎文档 → 向量化 → 混合召回 → Rerank 精排 → 带引用回答
- STEP1 切碎文档将长文档切分 Chunk,设置重叠区;不能粗暴拦腰斩断,防止上下文断裂丢失信息。注意模型输入存在最大上下文长度,超长文本会被静默截断。
- STEP2 向量化把文本转为向量嵌入,语义相近的文本,在向量空间距离更近。
- STEP3 混合召回向量检索 + BM25 关键词检索,多路召回,捞出 Top-K 候选片段。兼顾语义相似度和关键词精准匹配。
- STEP4 Rerank 精排【提升效果的关键一步】多路召回拿到 20 条候选后,通过重排模型筛选出 3~5 条最相关片段,是 RAG 效果提升的核心手段。
- STEP5 带引用回答交给大模型,指令限定:仅根据以下资料回答,输出附带原文引用。
你的场景 | 推荐向量库 |
|---|---|
| 本地 Demo 快速验证 | Chroma / LanceDB |
| 已有 PostgreSQL | pgvector |
| 中小生产、要过滤和运维 | Qdrant |
| 亿级向量、分布式 | Milvus |
| 关键词 + 向量混合检索 | OpenSearch / Weaviate |
| 数据、向量、统计一套搞定 | Doris(成熟)/ StarRocks(Beta) |
⚠️选型三提醒:
① Doris/StarRocks 向量能力迭代很快,落地前务必查阅最新官方文档;
② 团队熟悉度优先于性能差距,如果已有 PG,pgvector 往往总成本更低;
③ 删除文档时向量需要同步清理;OLAP 适合批量导入,不适合高频实时更新。
4. RAG 怎么评估好坏?
不要凭肉眼主观感觉效果,必须先建测试题库,量化打分
- 检索侧指标:Hit Rate(Top-K 是否命中正确文档)
- 生成侧指标:答案忠实于参考资料的忠实度
- 常用评估框架:RAGAS
❌没有 assessment 的 RAG 调优 = 玄学迭代
5. 企业落地最容易踩的坑
重点三个:权限、引用、向量同步清理
- 权限过滤:检索时按用户权限过滤文档,防止跨部门数据泄露(比如 A 用户查到 B 部门薪酬)
- 引用溯源:回答标注来源段落,方便人工核查、定位问题
- 僵尸知识:文档删除 / 更新时,旧向量必须同步清理,知识库会残留过时无效信息
6. RAG 进阶玩法
- Query 改写:用户口语化提问,先改写、做 HyDE,再送入检索,优化召回质量
- GraphRAG:结合知识图谱,擅长多跳推理类复杂问题
- Agentic RAG:让 AI 自主决定查询策略、检索次数,自主规划检索动作
7. 一句话记住 RAG
让 AI先翻书、再答题:切碎 → 向量化 → 召回 → 精排 → 带引用生成 落地三件套别忘了:评估打分、权限过滤、向量同步清理