歲 利先把话说在前面：这一篇不是讲怎么调 prompt，也不是跑通一个 demo 就收工。生成式人工智能的实战做到第五篇，我想把过去半年在项目里最折腾、也最值得总结的一段经历拿出来聊透——从能生成内容，到能解决业务问题。如果你正在做知识库问答、智能客服、文档助手这类落地场景，这篇里的思路和代码应该能直接给你省下几周的踩坑时间。
前四篇我们分别聊了环境搭建与模型接入、提示词工程的结构化设计、文本生成在业务场景的落地，以及多模态生成在工作流里的实用技巧。那些内容解决的核心问题都是"怎么让模型输出更准、更像样"。但真到了生产环境，你会撞上一堵墙：业务方不会只问你"模型能不能把这段文字润色好"，他们问的是"几万页产品文档，能不能变成一个 7x24 小时在线的问答机器人"。这堵墙背后是两个坎——一是模型的上下文窗口装不下海量知识，二是模型只会"说"不会"做"。这一篇，我们就专门拆这两个坎。
先说明一下本篇的行文定位：我会用一个真实落地的"售前技术问答助手"作为贯穿全篇的项目背景，从 RAG 检索增强讲到 Agent 工具编排，再到部署环节的稳定性处理。每一步都给出可照抄的实现方案和关键参数，最后分享我在这个项目里踩过的三个比较深的坑。内容偏工程实践，适合已经跑通过基础 API 调用、想做完整应用的读者。
1. 为什么模型用得好好的，一上业务就"失灵"
先复盘一个我自己的失败案例。最早接了一个设备厂商的项目，需求很明确：把 300 多页的产品手册、常见故障排查文档、选型指南整合成一个问答机器人，给一线销售和技术支持用。我当时的第一反应是"这不简单吗，直接把文档分段塞给模型就行"。结果做了三天，被客户怼回来三次。
问题出在哪？我当时把所有文档按固定长度切了片，每次从里面挑几段拼进 prompt。但客户问的问题根本不是我预想的那种"某型号的额定功率是多少"，而是跳过中间步骤的复合问题，比如"客户现场电压不稳，选型号的时候该往哪个方向考虑"。这种问题依赖的信息分散在三个不同章节里：电气参数表、安装环境要求、故障排查案例。固定切片的检索结果质量极差，模型拿到的上下文本来就不相关，生成的内容自然也就是一本正经地胡说八道。
这个案例暴露了生成式 AI 落地时的通病：单次调用的生成能力再强，也无法替代信息组织和任务拆解。上下文窗口再大，放得下几万页的文档吗？模型能力再强，它能主动去查数据库、调接口、翻工单记录吗？
所以这一篇的核心，其实就是两个体系的构建：
- RAG（检索增强生成）：把"模型的知识"和"业务的知识"分开，让模型在回答问题时先从知识库里检索相关内容，再基于检索结果生成答案。解决"记不住"的问题。
- Agent（智能体编排）：让模型不只生成文本，还能根据用户的意图去调用外部工具——查库存、查物流、翻订单系统，再把这些工具返回的结果整理成回复。解决"不会做"的问题。
这两个体系不是并列关系，而是递进关系。RAG 解决的是"知识来源"问题，Agent 解决的是"行动能力"问题。实际项目中它们往往混在一起用：用户问了一个需要查实时库存的选型问题，Agent 先识别出"需要调用库存接口 + 查产品参数文档"，于是从 RAG 链路检索产品知识，从业务接口拿到库存数据，最后把两者合并成回答。下面我从底层往上逐层拆解。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. RAG 链路搭建：从文档切分到混合检索的完整细节
RAG 链路可以说是生成式人工智能实战里性价比最高的模块。它逻辑清晰、见效快，但做好做坏的区别非常大。我把它拆成四个环节来逐一说明——切分、向量化、检索、组装。
2.1 文档切分：最容易被低估的一步
多数教程会让你"选择一个 chunk_size"，好像这只是个随手填的参数。但实际项目里，切分方式直接决定检索质量的上限。固定按 500 字切片的方案我试过，结果是语义被拦腰截断：一段关于"安装环境要求"的内容可能被切成两半，前半段讲温度范围，后半段讲湿度要求，检索时只能命中原问题里字面匹配更强的半段，另一半信息就丢了。
我后来采用的方案是结构感知切分。先按文档的标题层级（Markdown 的标题、PDF 的章节结构）做第一层切分，把文档拆成"章"；对每一章里内容过长的段落，再按语义段落做第二层切分。如果第二层切分后的块仍然太长，就按句子边界进行第三层切分，但保证相邻块的衔接处预留少量重叠。
一个比较实用的参数组合（基于通用文档的实践总结）：
| 参数 | 推荐值区间 | 说明 |
|---|---|---|
| 第一层切分依据 | Markdown 标题层级 | 按 #、##、### 拆分 |
| 第二层切分依据 | 空行或段落边界 | 以完整段落为语义单元 |
| 重叠长度 | 50-100 字符 | 避免关键信息恰好落在切缝上 |
| 块长度上限 | 800-1200 字符（中文） | 太长稀释检索精度，太短丢失上下文 |
| 块长度下限 | 300 字符（中文） | 低于此阈值需检查是否被过度切碎 |
这里有个容易忽略的细节：表格式内容不要和正文混在一起切。比如设备参数表，它在 HTML 里可能是一个 <table>，如果你按纯文本切分，表格的行会被拆散，导致检索到的内容只剩半张表的碎片。我的做法是先把表格单独抽取出来，每行转成一条独立的"记录型文档"，并把表头字段拼进去，入库时和正文走两套索引或者打不同标签。后面检索时可以按标签加权，让表格命中的结果更聚焦。
2.2 向量化：embedding 模型怎么选
切分完成之后，每一块文档需要变成向量。这里的选择直接影响检索效果。我在项目中对比过通用向量接口和开源向量模型，结论是：中文场景下，开源向量模型在垂直领域的表现常常反超通用接口，尤其当你的文档里有大量专业术语时。
我用的是 BGE 系列的中文向量模型，它有几个被反复验证的优点：对中文长文本支持较好，向量维度不至于高到离谱（1024 维属于可控范围），而且原生支持按句子的相似度匹配。如果你处理的文档里中文占比高，我建议优先尝试这个方向，而不是一上来就接通用向量接口。
向量化过程中有一个常被忽视的参数——query 和 document 是否用不同的编码方式。BGE 这类模型提供的检索指令能明显提升短查询的召回效果，其实就是对用户的那句问题进行指令前缀增强，让查询向量和文档向量在空间中的分布更接近。操作代码如下：
python复制from sentence_transformers import SentenceTransformer
model = SentenceTransformer("BAAI/bge-large-zh-v1.5")
model.max_seq_length = 512 # 超过512会截断，切块时注意
# 文档入库：直接编码
doc_embedding = model.encode(doc_text, normalize_embeddings=True)
# 检索时：给 query 加指令前缀，提升短问题召回率
query_embedding = model.encode(
"为这个句子生成表示以用于检索相关文章：" + query_text,
normalize_embeddings=True
)
我推荐直接将向量库选型定为本地可部署的轻量方案，比如 Chroma 或 SQLite 上的向量扩展。生产环境如果数据量在百万级以下，完全没有必要上分布式向量集群，简单方案反而出问题少、好维护。
2.3 混合检索：为什么纯向量检索不够用
很多 RAG 的初期实现只走向量检索。这在文档比较"正经"、用户提问也比较"正经"的场景下勉强能跑，但真实业务里用户的问法五花八门。一个典型场景：用户问"B 型号和 C 型号啥区别"，向量检索能匹配到"B 型号""C 型号"两个实体的相关段落，却不理解你问的是"对比"，于是两段内容各召回了半篇。而如果加入关键词检索（BM25），"区别"、"对比"这类的词就能帮助提升两段内容同时被召回的概率。
混合检索不是把两种结果简单合并去重就完事，关键是打分融合。业界常用的方案是 RRF（Reciprocal Rank Fusion），思路是把两种检索结果的排名转化为一个融合分，而不直接比较向量距离和 BM25 分数——这两个分数量纲不同，没法直接相加。RRF 的公式是：每个文档的得分等于它在两种检索结果中排名的倒数之和。这样排名靠前的结果天然得分高，两种检索的互补性就能体现。
我还做了更进一步的精排。BM25 和向量检索各自取 top 30 混合后，用一个 bge-reranker 模型对混合结果做重排序。这个模型的作用是把"候选文档和问题的相关程度"重新打分排序，效果非常明显。加了重排序之后，用户问题的首轮准确率和人工评估的满意度都明显提升，这个收益几乎不依赖调参，属于加进来就有效果的模块。
2.4 上下文组装：让模型只依赖检索内容
检索到候选块之后，怎么把内容组装进 prompt 也有讲究。我踩过一个比较蠢的坑：把命中的文档块一股脑全塞进上下文，结果模型被不相关内容带偏。后来严格做了三件事：
- 限制条数：默认只保留重排序后的 top 3 块，每块控制在 500 字左右，总上下文不超过 2000 字。宁可信息缺失也不能让模型分心。
- 标注来源：给每块内容加一个元信息标记，比如
[来自《XX型号选型指南》第三章]。这能让模型在回答时知道自己在引用哪份文档，显著减少幻觉。 - 强约束 prompt 结构：system 提示词里明确写"你只能依据以下资料回答，如果资料中没有相关信息，直接回答不知道"。这句约束比想象中有用，没有它，模型倾向于强行回答；有它，模型的"拒答率"才会真正体现出来。
组装后的 prompt 结构大致是：
text复制请基于以下文档内容回答用户问题。回答时优先引用资料原文，不要编造资料中不存在的信息。
【资料1】来源：产品手册-第2章-电气参数
内容：...
【资料2】来源：故障排查指南-第4节
内容：...
用户问题：...
到这里，RAG 的基础链路就通了：文档切分、向量化入库、混合检索、重排序、上下文组装。这个链路能解决"知识记忆"的问题。但光是能回答还不够——下一层问题是，当用户的需求需要系统主动去查业务系统、去调外部 API 的时候，该怎么办。这就进入 Agent 的范畴。
3. Agent 工具编排：让模型学会动手做事
打个生活化的比方。RAG 相当于给一个聪明但没有工作经验的新人一本厚厚的公司手册，他能引用手册回答问题，但他不会去操作业务系统。Agent 则是给这个新人配上了操作权限：他可以查库存、下单、发邮件，然后把操作结果告诉你。Agent 的本质是让模型从"生成文本"变成"调用工具"。
3.1 一种简单可靠的模式：意图识别 + 工具路由
我见过不少团队一上来就上复杂的 ReAct 式多轮推理循环，结果 token 消耗大、延迟高、还不好调试。在大多数业务场景里，你根本不需要模型在每一步都推理出下一步该干嘛——用户的意图种类往往是有限的，直接做一个意图识别 + 工具路由反而更稳。
具体做法分三层：
- 意图识别层：用一个轻量模型或分类器，把用户问题归入确定的类别（查产品、查库存、查售后、闲聊等）。
- 工具调用层：根据意图类别，确定需要调用的工具链组合。比如"查产品"走 RAG，"查库存"调用库存 API，"查售后进度"调用工单系统接口。
- 生成回答层：把工具返回的数据交给大模型，让模型组织成自然语言回答。
这个结构和"端到端让模型自由决定调用什么工具"相比，牺牲了一点灵活性，但换来了极高的稳定性。生产环境更看重后者。不过，如果你的业务场景确实需要更灵活的推理，也可以用 Function Calling 的方式。这两种方式可以组合：用 Function Calling 实现工具调用的接口规范，用意图识别做路由兜底。
3.2 Function Calling 的工具定义方法
Function Calling 的核心是给模型一份"工具说明书"——用 JSON Schema 描述每个工具的名字、功能、参数类型和必填项。模型根据用户的问题，从这份说明书中选择合适的工具，生成结构化的调用参数返回给你，然后由你的代码去真正执行工具调用。这里的关键是：工具描述写得越具体，模型的选择越准。
我们来看一个具体例子。假设要给问答助手加一个"查库存"的功能，工具定义大致如下：
python复制tools = [
{
"type": "function",
"function": {
"name": "query_stock",
"description": "查询指定型号设备的当前库存数量。当用户咨询到货周期、库存状态、现货情况时调用。",
"parameters": {
"type": "object",
"properties": {
"model_number": {
"type": "string",
"description": "设备型号，例如 B-2000。"
},
"region": {
"type": "string",
"enum": ["华东", "华北", "华南", "西南", "全国"],
"description": "查询库存的区域，默认是全国。"
}
},
"required": ["model_number"]
}
}
}
]
注意 description 的写法："当用户咨询到货周期、库存状态、现货情况时调用"——这一句是给模型看的，帮它判断什么时候该触发调用。参数里的 enum 限定取值范围，能显著减少模型生成非法参数的几率。我建议在参数描述里加上默认值说明（像 region 默认全国），模型通常能理解这种默认设定。
执行完工具调用后，你的代码会拿到真实库存数据。这时把数据和工具调用的结果一起作为上下文返回给模型，让模型基于这些数据生成最终回复。这个回传环节也有讲究：数据要结构化呈现，别把原始 JSON 直接塞进去，模型容易混淆，应当整理成人类可读的文本格式再回传，比如"型号 B-2000 在华东仓库存 120 件，华北仓 85 件"。
3.3 多轮交互中的"确认机制"
Agent 系统上线后遇到的一个高频问题：模型在用户还没把需求说清楚时，就急着自己去调工具了。比如用户问"我想买一台设备"，这个需求少了一个关键槽位——型号，系统却直接查了一整套库存。
解决方案是引入槽位确认机制。工具定义里把必填参数标记出来，如果模型生成的结果里缺少必填参数，系统不是直接报错，而是生成一条追问："您想查询哪个型号的库存？我这边可以帮您确认到货情况。"等到用户补充了型号，再真正执行工具调用。这借鉴了传统对话系统里的槽位填充思想，但比传统实现更自然，因为模型能自己理解缺了什么，不用你写死每一条追问规则。
槽位确认机制的实现成本很低，但体验提升非常明显。上线后系统从"冷冰冰的功能入口"变成"合格的售前顾问"，客户那边的好评基本都集中在这个细节上。
3.4 Agent 的安全性边界
让模型去调用工具，等于给模型开了权限，这必须设置边界。我在生产环境里做了三个硬限制：
- 只读默认原则：咨询场景下的所有 Agent 工具默认只允许查询，不允许写操作。真要开放下单、修改配置这类操作，必须走单独的接口和审批流，绝不能在智能体链路里直接暴露写接口。
- 工具超时与熔断：每个工具调用都有单独的超时时间（通常 3 秒），超时后 Agent 明确回答"系统暂时无法查询库存，请稍后再试"，而不是无限重试或假装成功。
- 敏感信息过滤：模型返回的内容里可能无意中包含工单系统里的用户隐私，需要在生成回答层做关键词过滤和数据脱敏。这个环节虽然简单，但不可或缺。
4. 一个完整的落地案例：售前咨询助手的全流程实现
前面讲了不少原理，这一节把它们串起来，看一个完整的最小实现。我以"售前咨询助手"为例，完整走一遍从启动到部署的流程。这个案例的代码是我在实际项目里用的精简版本，去掉了业务敏感内容，保留了核心链路，你可以把它当成模板来改。
4.1 系统整体结构
整个系统的模块划分如下：
- 数据层：文档库（300 页 PDF 转换成的 Markdown）、向量库（Chroma）、业务 API 接口（库存、工单查询）
- 逻辑层：意图识别模块、RAG 检索模块、工具调用模块
- 接口层：FastAPI 提供 HTTP 接口，对内封装所有逻辑
- 对话层：大模型负责最终回复生成
启动时先做一次数据全量入库，后续每天增量更新。增量更新只处理变化过的文档块，避免了全量重嵌入的算力浪费。
4.2 核心实现代码
主流程用一个继承自 FastAPI 的类来组织，意图识别和工具路由放在一个 controller 里，调用链路的伪代码实现如下：
python复制from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class UserQuery(BaseModel):
text: str
session_id: str = "default"
@app.post("/chat")
async def chat(query: UserQuery):
# step1: 意图识别（用轻量模型，返回一个意图标签）
intent = intent_classify(query.text)
# step2: 根据意图决定工具链
if intent == "product_query":
contexts = retrieve_contexts(query.text, top_k=3)
prompt = build_rag_prompt(query.text, contexts)
answer = llm_chat(prompt)
elif intent == "stock_query":
# 槽位提取：由 Function Calling 完成参数抽取
params = extract_stock_params(query.text)
if not params.get("model_number"):
return {"reply": "请告诉我您想查询哪个型号的设备库存？"}
stock_result = query_stock_api(**params)
answer = llm_chat_with_data(query.text, stock_result)
elif intent == "after_sales":
# 多工具串联：先查工单系统，再生成回复
ticket_info = query_ticket_api(query.text)
answer = llm_chat_with_data(query.text, ticket_info)
else:
# 兜底：普通闲聊走纯模型生成，不进 RAG
answer = llm_chat(query.text)
return {"reply": answer, "intent": intent, "session_id": query.session_id}
这里的 retrieve_contexts 函数封装了混合检索 + 重排序逻辑，内部实现大致是向量检索取 top 30、BM25 取 top 30、合并去重、重排序取 top 3。代码算是精简的，但已经是核心链路的完整表达式了。
另外一个容易被忽略的细节：session 管理。多轮对话需要记住用户前几轮说了什么，否则用户说"那库存呢"的时候，系统根本不知道"那"指的是哪台设备。我在实现里为每个 session 维护最近 6 条消息的上下文，保留关键实体的历史引用。记忆量不用太大，6 条足够覆盖绝大多数咨询场景，token 消耗也可控。
4.3 效果评估：不能光看"答得对不对"
"答得对不对"这个标准，在生成式 AI 场景里很难定义。我做的评估分成三层，每一层都有明确的通过标准：
| 评估维度 | 评估方法 | 达标线（个人经验） |
|---|---|---|
| 回答的相关性 | 人工评分 1-5 分，抽检 100 条对话 | 平均分 ≥ 4.2 |
| 事实准确性 | 逐条核对引用来源，重点查数字、型号、参数 | 错误率 < 2% |
| 拒答合理性 | 遇到知识库覆盖不到的领域，是否诚实拒答 | 拒答率 ≥ 95% |
这组数字不是拍脑袋定的，是我在项目里跑了一个月后总结出来的合理基准。按这个标准，最初版本的助手相关性和准确性都不达标；混合检索 + 重排序的补丁最终把这两个指标拉到了达标线以上。拒答率这块容易被忽视，实际上它直接影响信任感——一个不懂装懂的助手比一个承认不懂的助手危险得多。
4.4 这个案例里的三个"真实的坑"
第一个坑：embedding 模型的引入前后，检索效果有明显提升，但中文长文档下的提升幅度比基准测试里要小。这让我意识到：做检索评估不能只信公开 benchmark，一定要用你自己业务文档里的真实问题去测。我后来建了一个 50 条真实问题的测试集，每回改切分参数或换模型，都拿这个测试集跑一遍，以它的结果为准。
第二个坑：混合检索的权重融合，不是简单地给两个通道设一个固定权重就完事，而是需要根据文档类型动态调整。比如参数表类文档，关键词检索的命中率远高于向量检索，因为用户在问参数时用的是精确型号名称；而场景描述类文档，向量检索更占优势。我用了一个简单的动态规则：按命中的文档类型标签调整 RRF 权重，效果比固定权重好不少。
第三个坑：当模型被要求调用工具时，生成的参数偶尔会产生幻觉值，编造一个型号代号去查库存，返回自然是空的。解决方式是在工具调用层做一个参数校验白名单，把型号和已有产品库做一次合法校验，不合法就直接返回"你问的型号似乎不在我们的产品目录中"。这一步把幻觉参数问题基本清零。
5. 部署与稳定性：生成式应用上线前的最后一公里
跑通了链路、评估达标，下一步是把系统推到生产环境。很多项目死在最后的部署环节——实验室里回答得很漂亮的助手，一上线就超时、崩溃、烧钱。这一节说几个必须处理的生产细节。
5.1 语义缓存：把回答速度从 3 秒降到 0.3 秒
大模型调用的延迟是绕不过去的痛点。首次调用一个普通长问题的生成大概需要 2-5 秒，如果每个用户每次对话都走全链路，用户体验会非常糟糕。我用了一个"语义缓存"的思路：把用户问题先向量化，在缓存里找相似度超过 0.92 的历史问题，如果命中就直接返回历史答案，不再调用大模型。
这套缓存机制上线后，约四成的重复问题直接命中缓存，整体 P95 延迟从 4.2 秒降到 1.1 秒。缓存命中率和你业务问题的重复度有关，问法高度相似的场景收益尤其明显。注意缓存要设置过期时间——文档更新后，对应的缓存必须失效，否则用户会一直得到旧答案。
5.2 超时、重试与优雅降级
生成式 AI 服务会遇到普通服务几乎不会遇到的问题——模型接口不稳定。要么响应慢，要么干脆超时。我在网关层做了三档降级策略：
- 一档降级：模型首次调用超时后，自动切换到备用模型供应商或备用区域。这层需要你至少在两家供应商都有账号。
- 二档降级：如果备用模型也不行，调用离线答案模板——针对高频问题预先写好的固定答案，让用户不白等。
- 三档降级：直接返回"系统繁忙，请稍后再试"，但不让它出多深的错。
这几层降级看起来复杂，但实现起来就是一个链式调用的封装。花一个下午做好，能避免深夜被报警电话吵醒。
5.3 成本控制：给模型分级
生成式 AI 项目的成本大头在大模型 API 调用。我采取的方案是模型分级：意图识别用轻量模型（响应快、便宜），RAG 检索的向量化用本地开源模型（不额外收费），最终回复生成用旗舰模型（效果好、贵）。这样一套下来，旗舰模型的 token 消耗只占全部调用链路的约 50%，剩下的都是低成本组件的活。项目整体 cost-per-conversation 降了约 35%，效果几乎没有可见损失。
另外有个细节：把系统提示词和文档资料尽量做静态缓存，不要每次请求都重新拼一遍。长 system prompt 的 token 占比其实很高，静态化之后能省不少。
5.4 监控与持续调优
生成式 AI 应用不能"上线就跑路"，因为它本质上是个概率系统，今天的准确率和明天可能不一样。我在监控面板上盯三个核心指标，每一个都对应一个行动项：
- 平均回复延迟：超过 3 秒就查链路瓶颈，重点看模型调用时长。
- 缓存命中率：持续走低说明用户问法越来越分散，可能需要补充文档或优化意图识别。
- 用户反馈不满意度：每天抽看负反馈日志，一周汇总一次，用来驱动 prompt 和工具描述的迭代。
这套指标配合日志里的 session 级留痕，能让你在用户反馈之前发现系统退化。举一个真实例子：某次上游文档改了格式，导致切分质量骤降，检索出来的内容开始变得碎片化，但当时模型接口和延迟指标都正常。最终是抽取了 50 个真实问题的答案，逐条核对引用来源，才发现问题。这提醒我：准确率的监控不能只看系统指标，定期人工抽检答案质量，才是生成式应用最可靠的质检手段。
写在最后的实际操作体会
这篇写到这儿，内容已经比较长了。回到开头那个问题——生成式 AI 怎么从"能生成"变成"能干活"，我的回答是：把精力从"模型"挪到"链路"上来。模型本身只是生成器，让它变可靠的是你围绕它构建的信息检索、工具调用、降级兜底这一整套系统。
如果只让我从这篇里挑一条最有价值的经验，那就是——别迷信模型的单一能力，要把模型当成一个组件嵌进系统里，用工程手段去补足它的短板。RAG 补足了它的知识短板，Agent 补足了它的行动短板，缓存和降级补足了它的稳定性短板。这四层短板补齐了，这个系统才真正能交付给业务方。
最后分享一个操作层面的小技巧：在开发 RAG 和 Agent 的时候，给你的大模型调用统一封装一个带日志的接口，每次调用都记录输入、输出、模型名、耗时、token 数。这个日志在后期的效果排查里价值极大，能让你在用户反馈一句"最近回答怎么变差了"的时候，不是抓瞎，而是直接打开日志精准定位是文档更新、切分变化还是模型侧衰退导致的。这个小习惯给我省下的排查时间，比任何调优技巧都多。