RAG¶
主要内容
Prompt 负责把问题问清楚;RAG 给模型外挂资料库;向量数据库负责语义检索;大模型不是数据库,需要检索、工具和验证来降低幻觉。
参考文档¶
提示词工程.md、RAG.md、向量数据库.md、大模型原理.md、搜索引擎.md
知识地图¶
- 概念:先理解这个模块为什么存在。
- 工具:再看它通过哪些工具落地。
- 场景:最后判断什么时候该用,什么时候不该用。
核心整理¶
Prompt 负责把问题问清楚;RAG 给模型外挂资料库;向量数据库负责语义检索;大模型不是数据库,需要检索、工具和验证来降低幻觉。
我在整理这部分时的重点是把工具放回工程场景,而不是孤立记名词。一个工具出现,通常是为了解决某种复杂度:协作复杂度、上下文复杂度、运行环境复杂度、系统规模复杂度或信息获取复杂度。
学习笔记¶
- 先读 Why,确认它解决的问题。
- 再读 What,建立概念边界。
- 再读 How,补命令、API、配置和实践。
- 最后用一个小 demo 验证。
实践清单¶
- 用自己的话解释本模块核心概念。
- 找一个最小 demo 跑通。
- 记录一个踩坑点。
- 把相关命令或配置写成可复用片段。
- 回看飞书原文,补齐遗漏的术语。
飞书思考题¶
飞书原文未在本模块设置集中独立的思考题,因此本节只保留原文知识整理,不额外添加题目。
Prompt 的结构化写法¶
飞书提示词文档提到 CoT、Few-Shot-CoT、Zero-Shot-CoT、角色扮演和格式化输出。我整理成一个模板:
这比“帮我写一下”更稳定,因为模型知道边界。
CoT 与 Few-shot¶
CoT 的核心是让模型拆步骤。Few-shot 的核心是给模型几个样例,让它模仿模式。
适合 CoT 的场景:
- 多步骤推理。
- 代码排错。
- 方案比较。
- 复杂文档整理。
适合 Few-shot 的场景:
- 固定格式输出。
- 分类任务。
- 风格迁移。
- 数据抽取。
RAG 的基本组件¶
RAG 不是“接一个向量库”这么简单。完整组件包括:
- Loader:加载文档。
- Splitter:切块。
- Embedding:向量化。
- Vector DB:存储和检索。
- Retriever:召回相关内容。
- Reranker:重排。
- Generator:结合上下文回答。
- Evaluator:评估答案。
Chunk 怎么切¶
切太大:召回内容噪音多,模型难找重点。
切太小:语义不完整,答案缺上下文。
较好的做法是:
- 保留标题层级。
- 对代码和表格特殊处理。
- 给 chunk 加 metadata,比如来源文件、章节、日期。
- 允许一定 overlap。
向量数据库与语义查询¶
传统数据库擅长精确查询:where id = 1。向量数据库擅长语义相似:问题和文档不含同一个词,也可能因为意思接近被召回。
相似度常见算法:
- Cosine similarity:看方向相似。
- Dot product:看投影大小。
- Euclidean distance:看距离。
ANN 是为了在大规模向量里更快检索,牺牲一点精度换速度。
主流向量数据库¶
飞书文档提到:
- Pinecone:托管、企业级、低延迟。
- Milvus:开源分布式,适合大规模。
- Qdrant:Rust,高性能。
- Weaviate:GraphQL、多模态和 AI 模块。
- Chroma:轻量,本地原型友好。
我自己的选择思路:
- 学习和 demo:Chroma。
- 本地/中小项目:Qdrant。
- 大规模或团队部署:Milvus。
- 不想自运维:Pinecone。
RAG 的常见失败¶
- 文档没切好,导致搜不到。
- embedding 模型不适合中文或领域文本。
- topK 太少漏内容,太多又引入噪音。
- 没有 rerank。
- prompt 没要求基于来源回答。
- 检索结果过时。
大模型不是数据库¶
大模型会生成概率上合理的文本,不保证事实正确。RAG、工具调用、引用来源、测试和人工确认都是给模型加“落地约束”。
搜索引擎和 AI 的配合¶
AI 可以帮我改写搜索词,但不能替我验证事实。查技术问题时优先看:官方文档、标准、源码 issue、维护者博客,再看二手教程。
知识卡片¶
Embedding¶
Embedding 把文本映射到向量空间。语义相近的文本向量距离更近。
TopK¶
TopK 太小容易漏召回,太大容易引入噪音。需要结合 rerank 和上下文窗口调整。
Grounding¶
让回答绑定来源材料,能减少幻觉。RAG 回答最好说明依据来自哪些片段。
Evaluation¶
RAG 不评估就不知道好坏。至少要准备一组固定问题测试召回和回答忠实度。