干货分享 | RAG不是“把文档塞进去”这么简单......

“RAG不就是把文档向量化，然后检索出来给LLM吗？”

很多人对RAG的理解停留在这一句话。

但真正上过生产的RAG系统，每个环节都有坑，每个坑都可能让整体效果崩掉。

原始文档可能是PDF、Word、网页、数据库导出......格式混乱，噪音多。

常见问题：

这是被严重低估的一步，直接决定检索质量的上限。

切块太大：一个chunk包含多个话题，检索到的内容不够精准，LLM读到太多无关信息。

切块太小：每个chunk缺乏上下文，LLM无法理解这段话的含义。

咋办咋办：

实战建议：大多数场景从Recursive+10-15% overlap开始调，chunk size在512~1024token之间试验。如果文档结构强（如技术文档、合同），优先按自然段落切。

把文本转成向量，这步的选择影响检索的语义理解能力。

几个常被忽视的点：

Embedding生成后，向量需要持久化存储才能检索。

选型核心看三点：数据量、是否需要元数据过滤、能不能接受托管服务。

快速选型参考：本地原型用Chroma，已有PostgreSQL栈直接上pgvector，生产环境需要高性能过滤用Qdrant，不想管基础设施就用Pinecone。

索引方面默认选HNSW，速度快，向量量级超千万再考虑切换IVF。

最基础的是向量相似度检索，但单靠这个往往不够。以下是常用增强策略：

Hybrid Search：向量检索+关键词检索结果融合。对于包含专有名词、编号、代码的场景，关键词检索效果远好于纯向量。

HyDE：先让LLM根据query生成一个假设答案，用这个假设答案去检索，而不是用原始query。在query很短或很模糊时效果显著提升。

Multi-query Retrieval把原始query改写成多个不同角度的问题，分别检索后合并去重。覆盖面更广，召回率更高。

检索召回的是Top-K候选，但顺序不一定准确。

Reranker对候选结果精排，把最相关的推到前面。

Cross-encoder模型（如bge-reranker）会同时读query和document，比向量相似度判断更准，但速度慢，通常用在Top-20→Top-5的精排阶段。

很多人觉得这步最简单，但prompt工程在这里同样重要。

常见问题：

1. 答案内容错误，多半是Chunking或Embedding的问题，检索到了错误内容

2. 答案内容对但不完整，检索召回率不足，试试Multi-query或Hybrid Search

3. 答案不连贯/逻辑乱，Generation阶段prompt问题，或context太杂

4. 速度太慢，检查Embedding和Reranking是否可以缓存或异步处理。

RAG已经是AI工程师的基础能力。

能说清楚每个环节的原理和优化方向，是区分用过RAG和真正理解 RAG的分水岭。