RAG 架构图示例

以下 RAG 架构示例展示了同样的核心构建块——Embedding 器、向量存储、检索器和 LLM——如何随着检索系统从周末原型成长为生产管道而被以不同方式组合。

真实案例

使用场景: 构建首个检索原型的开发者

摄入：文档 → 固定大小分块（512 tokens）→ Embedding → Chroma

查询：问题 → Embedding → 向量检索（Top-5）→ LLM

编排器：单条 LangChain RetrievalQA 链

无重排序器、无查询改写——检索到的片段直接进入提示词

LLM：GPT-3.5-turbo，成本更低

这样组织的原因: 朴素 RAG 是最合适的起点——组件最少，所以当答案出错时，你能在增加复杂度之前先判断问题出在检索（取错片段）还是生成（片段对但答案差）。

使用场景: 答案缺少相关上下文的 ML 工程师

查询：问题 → Embedding → 向量检索（Top-20）→ 重排序 → Top-5 → LLM

重排序器：交叉编码器（Cohere Rerank 或 bge-reranker）为每个候选打分

向量数据库：Pinecone，按文档来源做元数据过滤

为何先 Top-20 再重排到 5：先广撒网，再只留最优

编排器：LangChain，使用 ContextualCompressionRetriever

这样组织的原因: 加入重排序器是对朴素 RAG 性价比最高的升级——纯向量检索只优化相似度，而交叉编码器重排序器会真正把查询和每个片段一起阅读，按真实相关性重新排序。

使用场景: 精确关键词查询（产品编码、名称）在语义检索中失败的团队

查询并行运行两个检索器：稠密（Embedding）+ 稀疏（BM25）

结果用倒数排名融合（RRF）合并后再重排序

向量数据库：内置混合检索的 Weaviate，或 Pinecone + Elasticsearch

摄入同时索引 Embedding 和关键词索引

重排序器对合并后的候选集进行融合与重排

这样组织的原因: 混合检索修复了经典的 RAG 失败场景：用户搜索精确词条——SKU、错误码、人名——而纯语义检索返回“相似”但错误的结果。BM25 抓住精确匹配，Embedding 抓住语义。

使用场景: 构建能自主决定何时、检索什么的助手的开发者

编排器：ReAct Agent，自行判断是否需要检索

Agent 可以改写查询、检索，然后决定是否再次检索

多数据源：向量数据库 + SQL 数据库 + Web 搜索，作为独立工具

自检步骤：Agent 验证检索到的上下文能否回答问题

若检索置信度低，则回退到向用户追问

这样组织的原因: Agentic RAG 把检索决策交给 LLM 本身——不再总是检索，而是由 Agent 推理是否需要外部数据、运行哪个查询、结果是否足够好，在复杂问题上用延迟换取准确率。

回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。