大模型的知识截止于训练时刻，且不了解你的私有数据，于是会「幻觉」——一本正经地编造事实。RAG（检索增强生成）是目前最实用的解法：先从你的知识库中检索相关文档，再让大模型「带着资料」作答。
RAG 的三步流程
- ① 切分与向量化（Ingest）：把你的文档切成小块（通常 500-1000 token），用嵌入模型（Embedding）转成向量，存入向量数据库。
- ② 检索（Retrieve）：用户提问时，把问题也向量化，从向量数据库中找出最相关的文档块（通常 top 3-5 个）。
- ③ 增强生成（Generate）：把检索到的内容拼进提示词，让大模型基于这些上下文回答，而非凭记忆。
RAG 架构详解
一个完整的 RAG 系统包含以下组件：
| 组件 | 功能 | 常见选择 |
|---|---|---|
| 文档加载器 | 读取 PDF/Word/HTML 等格式 | LangChain Loader / 自定义 |
| 切分器 | 将长文档切成小块 | 递归字符切分 / 语义切分 |
| 嵌入模型 | 文本转向量 | text-embedding-3 / Gecko / Cohere |
| 向量数据库 | 存储和检索向量 | Pinecone / Weaviate / pgvector |
| 检索器 | 从向量库找相关文档 | 相似度搜索 + 重排序 |
| 大模型 | 基于检索结果生成答案 | GPT-4o / Claude / Gemini |
| 编排框架 | 串联以上流程 | LangChain / LlamaIndex |
向量数据库选择
- 专用向量数据库：Pinecone（托管，简单）、Weaviate（开源，功能丰富）、Milvus（高性能，适合大规模）。
- 数据库扩展：PostgreSQL + pgvector（如果已有 PG，零额外基础设施）、Redis Stack（低延迟）。
- 云托管向量库：AWS OpenSearch Serverless、GCP Vertex AI Vector Search、Azure AI Search（都集成在各自云的 RAG 方案中）。
三大云 RAG 落地方式对比
| 对比维度 | AWS Bedrock | GCP Vertex AI | Azure OpenAI |
|---|---|---|---|
| 托管 RAG 方案 | Knowledge Bases | RAG Engine / Vertex AI Search | Azure AI Search + OpenAI |
| 向量数据库 | OpenSearch Serverless (托管) | Vertex AI Vector Search | Azure AI Search (内含向量) |
| 嵌入模型 | Titan Embeddings / Cohere | text-embedding-gecko | text-embedding-3 (OpenAI) |
| 支持的 LLM | Claude / Llama / Mistral | Gemini / Claude / Gemma | GPT-4o / GPT-4 / GPT-3.5 |
| 文档源 | S3 | GCS | Blob Storage / SharePoint |
| 代码量 | 最低（几乎零代码） | 低（少量配置） | 中等（需组装组件） |
| 权限管理 | IAM | Cloud IAM | Azure AD + RBAC |
| 按量计费 | 向量存储 + 检索 + LLM 调用 | 向量 + 检索 + LLM 调用 | Search 单位 + LLM 调用 |
各云具体接入步骤
AWS Bedrock Knowledge Bases（最简单）：1) 上传文档到 S3；2) 在 Bedrock 控制台创建 Knowledge Base，选择 S3 桶和嵌入模型；3) 自动完成切分、向量化、存储；4) 通过 API 或 Bedrock Agents 调用检索+生成。全程无需写向量数据库代码。
GCP Vertex AI RAG Engine：1) 上传文档到 GCS；2) 创建 RAG Corpus，配置切分和嵌入策略；3) 导入文档自动处理；4) 通过 Vertex AI API 执行检索+生成。也可以用 Vertex AI Search 做更精细的搜索体验。
Azure OpenAI + AI Search：1) 上传文档到 Azure Blob；2) 创建 Azure AI Search 索引，启用向量搜索；3) 使用 Azure OpenAI SDK 的 "chat with your data" 功能；4) 或用 Semantic Kernel 编排更复杂流程。组件较多但灵活性最高。
常见问题排查
- 回答不准确：检查检索结果是否相关——如果检索的文档块不含答案，模型再强也没用。优先优化切分粒度和检索 topK。
- 回答出现幻觉：在提示词中明确要求「只基于提供的上下文回答，如果上下文中没有相关信息请说不知道」。
- 响应太慢：向量检索通常 <100ms，慢在 LLM 生成。使用流式输出（streaming）改善用户体验。如果是嵌入慢，考虑批量预处理。
- 文档太多导致检索质量下降：加入重排序（Reranking）步骤——先用向量检索召回 20 个，再用 Cross-Encoder 重排取 top 5。
- 多语言支持：选择多语言嵌入模型（如 Cohere multilingual），并在切分时注意不同语言的分词边界。
常见问题
Q: RAG 和微调（Fine-tuning）哪个好？ RAG 适合需要实时更新知识、引用来源、多文档检索的场景。微调适合需要特定风格、格式或领域术语的场景。两者不冲突——可以先微调让模型更懂你的领域，再用 RAG 补充实时知识。
Q: RAG 的成本高吗？ 主要成本在 LLM 调用（每次问答约 $0.01-0.05）和向量存储（每百万向量约 $10-50/月）。嵌入模型调用成本很低（每百万 token 约 $0.02-0.13）。相比微调（训练成本 $100-10000+），RAG 的起步成本极低。