RAG 检索增强生成★★

RAG 通常分两段:离线把文档清洗、切块、向量化并写入索引;在线把用户问题向量化,检索相关片段,必要时重排,再把片段和问题一起交给模型生成答案。核心目标是让模型基于外部知识回答,而不是只靠参数记忆。

• +离线质量决定上限,包括文档解析、去重、切块、元数据和权限
• +在线链路要关注召回、重排、上下文拼装、引用和答案校验
• +RAG 不是只接一个向量库,它是一整套知识进入上下文的工程流程

可以从 query、索引、召回、重排和生成五层排查。常见优化包括改 chunk 策略、补元数据过滤、做 query rewrite、混合关键词检索和向量检索、加 reranker,以及让答案引用来源方便发现坏召回。

• +先看检索结果本身,不要一上来调 prompt,否则容易治标不治本
• +权限、时间、产品线等过滤条件常比相似度本身更关键
• +建立一组真实问题的检索评估集,用 recall@k、MRR 等指标跟踪效果

Chunk Size 要在语义完整和检索精度之间平衡。太小会丢上下文,模型看到片段不知道前因后果;太大又会召回噪声、浪费上下文,甚至把真正相关内容埋在中间。

• +FAQ、API 文档、长报告的最佳切块方式不同,不要全站一个固定大小
• +可以用标题、段落、代码块等结构化边界切,比按字符硬切更稳
• +常配合 overlap 保留跨段信息,但 overlap 过大会增加重复和成本

向量检索擅长快速召回相似内容,但 top k 里常混有语义相近却不真正回答问题的片段。Reranking 用更精准的模型重新排序候选,把最能回答问题的内容放到前面,提升最终上下文质量。

• +典型做法是向量库先召回 30-100 条,reranker 再筛到 3-10 条
• +Reranking 增加延迟和成本,适合对准确率要求高的问答
• +如果原始召回没有包含正确答案,reranker 也无法凭空补回来

纯 RAG 擅长找相关片段,但不擅长对大量记录做精确聚合计算。营收这类问题应该查询数据库、报表系统或执行分析代码,拿到确定数字后再让模型解释口径和组织回答。

• +RAG 召回几个片段可能漏数据,也可能把不同口径混在一起
• +聚合、排序、筛选、计算类问题更适合结构化查询或工具调用
• +模型可以生成 SQL 或调用报表 API,但执行和权限校验必须在系统侧完成

Embedding 模型负责把文本变成向量,让语义相近的内容在向量空间里更接近。向量数据库负责存储向量和元数据,并在查询时高效找到相近向量。

• +换 embedding 模型通常需要重建索引,否则新旧向量空间不一致
• +向量库选型要看数据量、过滤能力、权限、更新频率和运维成本
• +相似度高不等于答案正确,还要结合元数据和业务规则过滤

Semantic Search 主要靠向量相似度理解语义,Hybrid Search 会把向量检索和关键词检索结合起来。混合检索对专有名词、编号、错误码、产品型号这类精确词更稳,也能保留语义匹配的泛化能力。

• +关键词检索擅长精确匹配,向量检索擅长同义表达和意图相近
• +混合结果需要融合排序,常见做法是加权、RRF 或再交给 reranker
• +中文业务文档里缩写、型号、代码很多,Hybrid 往往比纯向量更实用

GraphRAG 适合实体关系复杂、需要跨文档推理或聚合关系的问题。普通 RAG 主要找相似片段,GraphRAG 会显式利用实体、关系和社区结构,帮助回答"谁影响了谁"、"这些事件如何关联"这类问题。

• +GraphRAG 的成本在知识图谱构建、实体消歧和持续更新
• +它不一定替代向量检索,很多系统会图谱检索和向量检索结合
• +如果问题只是单文档事实问答,普通 RAG 往往更简单高效