AI应用生产化15问与Agent风险清单：从Demo到上线的工程化实战

1. 从一句判断说起模型的能力边界到底在哪“模型是放大器不是发电机”这句话我在过去一年里跟团队内部至少重复过几十遍。每次有新的业务方跑过来问“能不能用大模型把这块业务从零做起来”我都会先把这句话甩出去。它的意思很直白大模型本身不产生业务价值它只能放大你已经有的东西——你有的数据、你有的流程、你有的判断标准它帮你放大十倍效率但你如果没有这些东西指望模型凭空给你造出来那基本就是烧钱听响。这个判断背后对应的是一个很现实的问题AI 应用从 demo 走到生产中间隔着的不是模型能力而是工程化能力。我见过太多团队拿着一个效果惊艳的 demo 去汇报然后卡在“怎么扛并发”“怎么控成本”“怎么保证输出稳定”这三座大山前面。所以这篇内容我打算把生产化过程中最常被问到的问题拆成 15 个再单独拉一份 Agent 的风险清单出来。适合正在做 AI 应用落地的人看也适合刚接触 RAG、Agent 想搞清楚工程侧到底要关注什么的人。核心关键词会贯穿全文AI、Agent、RAG、LLM、Token。这几个词不是并列关系而是层层嵌套——LLM 是底座Token 是计量单位RAG 是给 LLM 补知识的手段Agent 是在 LLM 之上加规划和工具调用的架构。搞清楚这层关系后面很多问题就顺了。2. AI 应用生产化 15 问从 demo 到线上的真实关卡2.1 前 5 问模型选型与 Token 成本第 1 问到底该选哪个 LLM这个问题没有标准答案但有一个决策顺序。先看你的任务类型如果是纯文本生成、摘要、改写中等规模的模型基本够用如果涉及复杂推理、多步规划、代码生成那就得上旗舰模型。再看你的部署约束数据能不能出内网如果能API 调用最省事如果不能就得考虑本地部署这时候显存和推理速度就是硬约束。最后看成本这个放到第 2 问说。我自己的经验是不要一上来就锁定一个模型。生产环境里做一层模型抽象是必须的把调用接口统一封装后面换模型只改配置不改业务代码。很多团队一开始图省事直接把某家 SDK 写死在业务逻辑里后面想换模型的时候改到吐血。第 2 问Token 成本怎么算才不亏Token 是 LLM 的计量单位输入和输出分开计费输出通常比输入贵。算成本的时候不能只看单次调用要算“单次业务请求的总 Token 消耗”。一个 RAG 请求的 Token 构成大概是系统提示词 检索回来的文档片段 用户问题 模型输出。其中检索片段是大头也是最容易失控的地方。我一般会做一个简单的成本模型假设每次请求输入 3000 Token、输出 500 Token按某旗舰模型的价格算单次成本大概在几分钱。听起来不多但如果你日活一万、每人每天五次请求一天就是几万次调用一个月下来就是一笔不小的开支。所以生产环境必须做 Token 预算控制比如限制检索片段数量、限制输出长度、对简单问题走小模型。第 3 问怎么控制 Token 用量几个实操手段。第一检索环节做重排序只把最相关的 top-3 到 top-5 片段塞进上下文而不是一股脑塞十个。第二系统提示词精简很多人写的提示词又臭又长里面一半是废话这部分每次请求都在烧钱。第三做缓存相同或相似的问题直接命中缓存返回尤其是 FAQ 类场景。第四输出长度限制明确告诉模型“用不超过 200 字回答”比让它自由发挥省很多。第 4 问小模型能不能扛生产能但要分场景。分类、意图识别、简单抽取这类任务小模型完全够用而且速度快、成本低。复杂推理和长文本理解还是得靠大模型。我比较推荐的做法是“大小模型组合”小模型做前置的路由和分类大模型只处理真正需要它的请求。这样整体成本能降一半以上。第 5 问模型更新了要不要跟不要盲目跟。新模型发布通常意味着效果提升但也可能带来行为变化——原来调好的提示词可能失效原来稳定的输出格式可能变了。我的做法是新模型先在测试集上跑一遍对比关键指标确认没有回归再灰度上线。生产环境永远保留回滚能力这是底线。2.2 中 5 问RAG 的坑与知识库工程第 6 问RAG 到底解决了什么问题RAG 解决的是“模型不知道你的私有知识”这个问题。LLM 的训练数据有截止时间也不包含你公司内部的文档。RAG 的思路是把相关知识检索出来塞进上下文让模型基于这些知识回答。它不改变模型本身只是给模型临时补课。但这里有个常见误解很多人以为上了 RAG 就不会胡说了。实际上 RAG 只能降低幻觉概率不能消除。如果检索回来的片段本身是错的或者模型没理解对照样会输出错误答案。所以 RAG 的效果上限取决于你的知识库质量。第 7 问RAG 的瓶颈通常在哪我踩过的坑里瓶颈基本不在模型而在检索。具体来说有三个一是切分策略文档切得太碎会丢上下文切得太大检索精度下降二是向量模型的选择不同向量模型对中文、对专业术语的表现差异很大三是召回和精排的配合只做向量召回往往不够需要加关键词召回做混合检索。第 8 问知识库怎么建才靠谱几个原则。第一文档要清洗PDF 里的页眉页脚、乱码、表格错位都要处理掉脏数据进去脏答案出来。第二切分要带重叠相邻片段之间保留一定重叠避免关键信息被切断。第三元数据要打全来源、时间、部门这些信息在检索和展示时都有用。第四建立更新机制知识库不是建完就完事文档变了要能同步。第 9 问怎么评估 RAG 效果不能只看“感觉还行”。我一般会建一个评测集包含几十到上百个问题每个问题标注标准答案和应该命中的文档。然后看两个指标检索命中率该召回的文档有没有召回和答案准确率最终输出对不对。这两个指标分开看才能定位问题出在检索还是生成。第 10 问RAG 和微调怎么选简单说知识类问题用 RAG风格和格式类问题用微调。RAG 适合知识频繁更新的场景改知识库就行不用重新训练。微调适合让模型学会特定的输出风格或遵循特定格式但微调成本高、周期长而且知识更新还得重新训。实际项目里两者经常结合用。2.3 后 5 问并发、稳定性与上线第 11 问AI 应用怎么扛并发这是被问得最多的问题。核心思路是异步化加队列。用户请求进来先入队后端用 worker 池消费避免请求直接打到模型接口上。模型调用本身是慢操作同步等待会拖垮整个服务。另外要做限流超过阈值的请求直接拒绝或降级保护后端。第 12 问模型接口不稳定怎么办重试加降级。重试要带退避策略不能死循环重试。降级是指主模型不可用时切到备用模型或者返回缓存结果或者给用户一个友好的提示。生产环境不能假设任何外部依赖永远可用。第 13 问怎么保证输出稳定几个手段。第一提示词里明确输出格式最好给示例。第二用结构化输出能力让模型直接返回 JSON。第三加输出校验格式不对就重试或修正。第四温度参数调低减少随机性。但要注意温度太低会让输出变得死板需要根据场景权衡。第 14 问上线前要做什么检查我一般会过一遍清单成本预算有没有算过、限流有没有配、降级方案有没有、日志有没有打全、敏感内容过滤有没有、评测集有没有跑过、回滚方案有没有。这几项缺一个都不建议上线。第 15 问上线后怎么持续优化靠数据。把用户的实际请求和反馈收集起来定期分析哪些问题答得好、哪些答得差。差的案例就是优化方向可能是检索没召回可能是提示词没写清楚可能是知识库缺内容。没有数据反馈的 AI 应用就是闭着眼睛开车。3. Agent 风险清单能自动干活的东西风险也是自动的3.1 Agent 和普通 LLM 应用的本质区别普通 LLM 应用是“你问它答”Agent 是“你给目标它自己想办法”。这个区别听起来不大但风险量级完全不一样。普通应用最坏情况是答错Agent 最坏情况是执行了错误的操作。所以 Agent 的风险管理必须比普通应用严格得多。Agent 的核心能力是规划加工具调用。它会把一个目标拆成多步每步选择一个工具去执行根据执行结果决定下一步。这个循环里任何一步出错都可能被放大。比如它误解了目标后面所有步骤都白做比如它调用了不该调用的工具可能造成实际损失。3.2 Agent 风险清单速查表风险类别具体表现缓解手段目标误解Agent 理解的任务和用户意图不一致执行前让用户确认计划工具滥用调用了权限过高的工具工具权限最小化敏感操作二次确认循环失控Agent 陷入反复调用停不下来设置最大步数上限和超时成本失控多步调用导致 Token 消耗暴涨单任务 Token 预算上限数据泄露Agent 把敏感数据传给外部工具数据分级敏感数据不出域错误累积前一步的小错误导致后续全错关键步骤加校验点不可解释出问题后不知道 Agent 为什么这么做全链路日志记录3.3 几个必须设的硬约束第一最大步数。任何 Agent 循环都必须有步数上限超过就强制停止。我见过没有上限的 Agent 在某个边界情况下疯狂调用工具一晚上烧掉几百块。第二工具白名单。Agent 能调用的工具必须是明确列出的不能动态发现。每个工具的权限要最小化只读工具和写工具严格区分。第三敏感操作确认。涉及资金、数据删除、对外发送这类操作必须有人工确认环节不能让 Agent 自己决定。第四全链路日志。Agent 的每一步思考、每一次工具调用、每一个返回结果都要记录。出问题的时候日志是唯一能还原现场的东西。4. 实操落地一个 RAG 项目的完整搭建过程4.1 环境准备与依赖选择假设我们要搭一个本地知识库问答系统零基础也能跟着做。技术栈选型上我倾向于用成熟框架加本地模型避免一开始就依赖外部服务。核心依赖包括一个 LLM 推理框架本地跑模型用、一个向量数据库存文档向量、一个编排框架把检索和生成串起来。编排框架我推荐用 LangChain 这类成熟的生态全、文档多遇到问题好搜。向量库用轻量级的就够数据量不大的话本地文件存储也能扛。模型方面如果机器显存够本地跑一个中等规模的模型如果不够就用 API。这里要注意本地模型和 API 模型的调用方式不同编排框架一般都能兼容配置改一下就行。4.2 文档处理与向量化第一步是文档加载。支持 PDF、Word、Markdown、纯文本这些常见格式。加载进来之后要清洗去掉页眉页脚、多余空行、乱码字符。第二步是切分。我一般用递归切分先按段落切段落太长再按句子切保证每个片段在 300 到 500 字之间相邻片段重叠 50 字左右。这个参数不是固定的要根据文档特点调。技术文档可以切小一点叙述性文档可以切大一点。第三步是向量化。用嵌入模型把每个片段转成向量存进向量库。嵌入模型的选择很关键中文场景要选对中文优化过的模型。存的时候把原文、来源、时间这些元数据一起存进去。# 文档切分的核心逻辑示意 from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_text(document_text)4.3 检索与生成链路检索环节用户问题先向量化然后在向量库里找最相似的片段。这里我建议加一层重排序先用向量召回 top-20再用重排序模型精选 top-5。重排序能明显提升相关性。生成环节把检索到的片段拼进提示词加上用户问题一起发给模型。提示词里要明确告诉模型“只根据提供的资料回答资料里没有的就说不知道”。这句话能显著降低幻觉。# 检索加生成的链路示意 def rag_query(question): query_vector embed(question) candidates vector_store.search(query_vector, top_k20) reranked rerank(question, candidates, top_k5) context \n.join([c.text for c in reranked]) prompt f根据以下资料回答问题资料中没有的信息不要编造。\n资料{context}\n问题{question} return llm.generate(prompt)4.4 评测与调优搭完之后不能凭感觉说好不好。建一个评测集准备 50 个左右的问题每个问题标注应该命中的文档和标准答案。跑一遍看检索命中率和答案准确率。如果检索命中率低检查切分策略和嵌入模型。如果检索命中但答案不对检查提示词和模型。如果都还行但用户反馈不好可能是评测集和真实场景有偏差需要补充真实问题。5. 常见问题与排查技巧实录5.1 检索相关的问题问题检索总是召回不相关的内容。排查顺序先看切分是不是太碎碎片化会导致语义不完整再看嵌入模型是不是不适合你的领域通用模型对专业术语可能不敏感最后看是不是该加关键词检索做混合召回。问题明明知识库里有就是检索不到。大概率是表述差异。用户问“怎么退款”文档里写的是“退货流程”向量相似度可能不高。解决办法是加同义词扩展或者用查询改写让模型先把用户问题改写成多个相关查询再检索。5.2 生成相关的问题问题模型不按资料回答自己编。提示词要加强约束明确说“只根据资料”。另外可以降低温度减少自由发挥。如果还不行考虑换模型有些模型遵循指令的能力就是差一些。问题输出格式不稳定。用结构化输出让模型返回 JSON。如果框架支持 function calling优先用这个。格式要求写在提示词里并给一个示例。5.3 工程相关的问题问题并发一高就超时。模型调用是瓶颈必须异步化。请求进来先入队worker 池消费。同时做限流保护后端。另外模型接口本身可能有并发限制要提前确认。问题Token 消耗比预期高很多。检查检索片段数量是不是塞太多了。检查系统提示词是不是太长了。检查有没有缓存重复问题是不是每次都重新调模型。提示生产环境的任何 AI 应用上线前必须做一次成本压力测试按峰值流量估算一个月的 Token 开销确认在预算内再上线。5.4 独家避坑经验第一个坑不要用生产数据直接做测试。我见过团队拿真实用户数据跑测试结果把测试环境的脏数据写进了知识库。测试和生产必须隔离。第二个坑不要忽略冷启动。新知识库刚上线检索效果往往不好因为文档少、覆盖不全。这时候要有兜底策略检索不到就明确告诉用户而不是硬答。第三个坑不要迷信大模型。有些任务小模型加好的提示词效果不比大模型差成本却低很多。选型的时候多对比别默认越贵越好。第四个坑日志要打全。Agent 和 RAG 的链路长出问题的时候如果没有详细日志排查就是大海捞针。每一步的输入输出都要记包括检索到的片段、模型的原始输出。6. 关于模型能力边界的一点个人体会做了这么多项目我越来越觉得“模型是放大器”这个判断是对的。模型能把你的数据价值放大能把你的流程效率放大但它放大的前提是你得有东西可放大。那些指望靠一个模型解决所有问题的项目最后基本都卡在数据质量和流程梳理上。Agent 也是一样。Agent 的自主性越强你对它的约束就得越严。能自动干活的东西风险也是自动的。所以我现在做 Agent 项目第一件事不是想它能做什么而是想它不能做什么边界画清楚了再谈能力。最后分享一个我常用的判断方法拿到一个 AI 需求先问“如果模型完全不可用这个业务还能不能跑”。如果答案是能那模型是锦上添花可以慢慢优化如果答案是不能那说明业务本身还没准备好先把基础流程理顺再说。这个方法帮我挡掉了很多不靠谱的需求也帮我聚焦在真正有价值的场景上。