大部分人第一次做 RAG 失败,不是因为技术难,而是每一层都挑了当下最热门的 5 个工具,结果搞出个 Frankenstein。先做最简单能 work 的版本,之后再随时换掉某一块。
五层,按顺序
基本 RAG 系统有五个组件,跳过或简化某些是可以的(有时甚至更好),但你要知道它们存在:
- 文档加载 / 切块(loader / chunker) — 把原始素材切成可以 embed 的小块
- embedding 模型 — 把每个 chunk 变成向量
- 向量数据库(vector store) — 存向量、文字、metadata
- 检索(retriever) — 拿到用户 query 时,找最相关的 chunk
- 生成(generator,LLM) — 拿着 chunk + query,写出答案
80/20 法则:切块跟检索比 embedding 模型跟 vector DB 重要。大部分团队在错的层级上钻牛角尖。
第一层:切块
默认:切成大概 500 token 的 chunk、重叠 50 token、按自然边界切(段落,然后句子)。LangChain 的 RecursiveCharacterTextSplitter 或 LlamaIndex 的 SentenceSplitter 是标准工具,直接用。
默认不够时:文件有强结构(法律合同、代码、有章节的学术论文)。这类用 semantic chunking 或 section-aware chunking — 按文件本身的自然单位切。Unstructured.io 跟 Docling 处理 PDF、HTML、DOCX 而且保留结构。
新手最常踩的坑:chunk 切太大(「每块 context 多 = 检索更好,对吧?」)。错。大 chunk 会稀释检索信号 — 真正相关的那一句话会被旁边两段不相关的文字平均掉。chunk 要小。如果需要更多 context,就多捞几个 chunk 让 LLM 自己整合。
第二层:embedding 模型
纯英文:OpenAI text-embedding-3-small(每百万 token $0.02)是默认。快、便宜、几乎所有场景都够好。text-embedding-3-large 微幅好一点,但价格 4 倍,通常不值得。
多语言或中文为主的内容:BGE M3(开源,自架或透过 Together / Replicate)跟 Cohere Embed v4 是两个强选择。BGE M3 自架免费;Cohere 是 hosted 也稳定。OpenAI 的 embedding 中文还行但不如专门模型。
专业领域(医疗、法律、代码):有评估数据证明能 help 的话再考虑 domain fine-tune embedding。大部分团队应该跳过。
第一步不要 fine-tune embedding。几乎永远是改善 chunking 或加 reranker 的提升更大。
第三层:vector store
第一个项目:已经用 Postgres 就 pgvector;没用就 Qdrant。两个都免费、两个都能 scale 到百万 chunk、两个 DX 都好。
什么时候用 Pinecone 之类的 hosted:ops 能力是瓶颈而不是钱的时候。Pinecone 比较贵,但你不用想 DB 的事。对只有一个工程师的初创,这通常是对的取舍。
什么时候用 Weaviate、Milvus、Chroma、LanceDB:第一版很少需要。各有有趣的特色(Weaviate 的 hybrid search、LanceDB 的 S3-native 架构)但第一版通常用不到。有具体理由再选。
不要根据 benchmark scaling 图选 vector DB。你第一个项目有 1 万个 chunk,不是 1 亿。任何选项处理 1 万 chunk 都是瞬间。
第四层:检索
默认:top-k 语义搜索(k=5 到 10)。把 query embed 后,用 cosine similarity 找最近的 k 个 chunk。所有 tutorial 都这样示范。
升级 #1:hybrid search — 语义搜索 + 关键字搜索(BM25)。很多 query(「Q3 合同价格是多少」)需要关键字匹配才能捞到对的 chunk。Hybrid 几乎永远比纯语义好。Qdrant、Weaviate、pgvector + tsvector 都支持。
升级 #2:reranker — 先用 vector search 捞 20-30 个候选,再用 cross-encoder 模型重排。Cohere Rerank v3 是黄金标准(每 query $0.001)。自架选项像 BGE reranker 也有竞争力。Reranker 带来的提升常常大过换 embedding 模型。
升级 #3:query expansion / HyDE — 让 LLM 在搜索前重写 query。对模糊 query 有合理提升。等检索明确是瓶颈再加。
第五层:生成
Claude 4.5 Sonnet 是 2026 年 RAG 生成的默认。它比 GPT-5 跟 Gemini 2.5 Pro 更会「只用提供的 context」,context 缺漏时较少幻觉,citation 比较干净。
GPT-5 在简单 Q&A 上速度更快、价格相似品质下更便宜。高量、面对客户、延迟 dominate 的 RAG 用它。
Gemini 2.5 Pro 在 context 巨大(1M+ token)时最强 — 那种场景有时候可以完全跳过检索把整个 corpus 直接丢进去。中型文件集(10-50 个 PDF)可行,但不能 scale 到企业级知识库。
DeepSeek 跟开源模型是成本受限或要自架时的选择。品质好,但「不要幻觉、要引用 chunk」这类指令服从度比较弱。
什么时候不适合做 RAG
如果你的整个知识库总共不到 10 万 token,直接全部贴进 LLM context 跳过检索就好。现代长 context 模型处理没问题、延迟可接受、整类检索失败的问题消失。
如果数据每几秒就变(交易、实时分析),RAG 是错的 pattern。用 SQL 或你既有的 query 层,给 LLM tool use 去查。
如果你没有评估数据,你做的不是 RAG,是「带检索的愿望思考」。先花一天做 50-100 个问题/期望答案的 pair 再调任何东西。
最小可行 stack
真的第一个项目的话:
- Loader:LlamaIndex
SimpleDirectoryReader或 LangChain document loader - Chunker:
RecursiveCharacterTextSplitter,500 token、50 重叠 - Embedder:OpenAI
text-embedding-3-small - Vector DB:pgvector 或 Qdrant
- Retriever:top-10 语义搜索 + Cohere Rerank v3 → top-5
- Generator:Claude 4.5 Sonnet,系统 prompt 严格要求「只从 context 回答」
这个 stack 跑起来几乎不花钱、一天能架好,在大部分场景上跟更复杂的解决方案有竞争力。
下一步
- 看一下 RAG 评估:怎么量化你的 RAG 真的有用
- 关键字 query 多的话研究 hybrid search
- 探索 agentic RAG:让 LLM 自己迭代检索
- 看 chunk size 实验 — 你的数据大概有个特定的最佳数字