← Back to all guides

从文档到回答：用 Claude 与 GPT 构建可切换 RAG 应用

1. 明确 RAG 应用的最小架构

RAG（检索增强生成）的目标不是让模型记住所有资料，而是在用户提问时，从你的文档中检索相关片段，再交给 Claude 或 GPT 生成有依据的回答。一个可上线的最小链路包括：文档导入、文本切分、Embedding 向量化、向量检索、重排、提示词组装、模型生成和引用返回。

建议先选择一个明确场景，例如产品文档问答、客服知识库或内部技术规范查询。第一版只接入 50 至 200 篇高质量文档，并要求每个回答都附带来源标题和段落链接，这比一开始追求复杂 Agent 更容易验证效果。

2. 导入、清洗并切分知识库

将 PDF、Markdown、HTML 或 Notion 导出文件统一转换为纯文本。清洗时删除导航栏、版权声明、重复页眉页脚和无意义空行，同时保留文档标题、URL、更新时间、权限级别等元数据。元数据将用于过滤检索范围，也能帮助前端展示引用来源。

切分建议从每段 400 至 700 个中文字符开始，重叠 80 至 120 个字符。技术文档应尽量按标题层级、函数说明或 FAQ 问答切分，不要机械地在句子中间截断。每个片段保存 chunk_id、content、document_title、source_url、section 和 updated_at。

3. 建立向量索引，并保留关键词检索

为每个文本片段调用 Embedding 模型，写入 pgvector、Qdrant、Milvus 或 Pinecone 等向量数据库。查询阶段先将用户问题向量化，按余弦相似度取回 top 10 至 top 20 个片段。对于型号、报错码、API 参数等精确词，纯向量检索容易遗漏，因此应同时加入 BM25 或数据库全文检索，再把两路结果合并。

• 向量召回：适合语义相近但措辞不同的问题。
• 关键词召回：适合版本号、命令、产品名和错误代码。
• 元数据过滤：按语言、产品版本、用户权限或发布时间限制结果。

合并候选结果后，可使用轻量模型或专用 reranker 重排，最终仅保留 3 至 6 段上下文。上下文过长不仅增加费用，也会让模型忽略真正关键的证据。

4. 用统一路由接入 Claude 与 GPT

在服务端建立 provider adapter：输入统一为 messages、system_prompt、temperature、max_tokens 和 model；输出统一为 answer、usage、latency 和 citations。这样业务层不必关心底层是 Claude 还是 GPT。Claude 通常适合长文档归纳、复杂指令遵循；GPT 可用于快速问答、结构化 JSON 输出或作为备用模型。实际选择应以你的离线评测集结果为准。

59API 提供 Claude（Opus、Sonnet、Haiku、Fable）和 GPT 模型的按量访问，API 基地址为 https://api.59api.com，并兼容 Claude Code、Codex 与 OpenAI SDK。对于需要多模型路由的 RAG 项目，这意味着可以减少多供应商账户、密钥和计费管理的复杂度，同时以较低成本使用原生官方质量模型。

5. 编写不允许幻觉的 RAG 提示词

系统提示词应明确规定：只能依据提供的参考资料回答；资料不足时直接说明无法确认；不要编造链接、版本号或政策；每个关键结论后标注对应的 source_id。将检索片段按相关度编号后放入 CONTEXT，再传入用户问题。temperature 建议设为 0 至 0.3，以降低知识库问答的随机性。

前端不要只展示答案，应把模型返回的 source_id 映射为文档标题、章节和原始链接。用户能点击查看证据时，RAG 的可信度和排错效率都会明显提高。

6. 评测、监控与成本优化

准备至少 30 个真实问题，覆盖可回答、需跨文档归纳、资料缺失和容易混淆的情况。分别记录检索命中率、引用正确率、答案完整度、首字延迟和单次成本。若答案错误，先检查检索片段是否命中，再调整切分、召回数量或重排，而不是立刻更换大模型。

生产环境可采用分层路由：默认使用经济型模型处理简单问答，检测到长上下文、复杂推理或低置信度时再升级到更强模型；同时缓存高频问题的检索结果。59API 的低价按量计费和推荐返利机制尤其适合先小规模验证，再逐步扩大调用量。准备开始时，可注册 59API，创建密钥后将其配置到你的模型路由层进行实际压测。

Pricing · Docs