最近有个做产品的朋友来找我开口就是“帮我做个AI客服能自动回复消息的那种”。我问他“你的知识库整理了吗用户问的东西从哪里检索多轮对话要不要保持上下文答不上来要不要转人工”他愣了半天。这个场景几乎就是大多数“从零开始做AI”的真实写照——大家都以为AI工程的核心是调用一个模型真正走下来才发现模型只是最后那层皮真正的工程量全在模型外面。这篇文章记录的是我自己从0到1跑通一个AI应用项目的完整复盘。它不是理论教程而是一套我在实际项目里反复调整后沉淀下来的思考方式和实操路径。你可能是刚接触AI工程的开发者也可能是有过一些调用经验、但还没把模型落地成稳定功能的人。我会从问题定义、Prompt工程、Agent编排、部署调优到成本控制一条线讲下来尽量说人话能直接照着做。这篇的核心就一句话AI工程的本质不是写代码调用API而是用工程方法把模型的随机性约束成可依赖的产品能力。1. 为什么先谈问题定义而不是选模型我见过太多团队第一步就是“选个大模型”然后拿个Demo到处演示最后却发现离能上线的产品还差十万八千里。问题不出在模型不够强而出在根本没人把“要做的事”定义清楚。1.1 一个Demo和一个产品之间的距离Demo很容易做。拿一个开源模型或者调一下公共大模型接口输入问题、输出答案三分钟就能跑出看起来还不错的效果。但这其中缺失了很多关键环节用户的输入可能错别字连篇、问题可能带情绪回答可能引用一个不存在的知识也可能在用户多问两句之后就把之前的对话忘光了。我当时接的项目是一个内部知识库问答助手。Demo阶段所有人都说“效果很好”但真要把知识库导进去开始测试问题全冒出来了。比如同事问“上次分享会提到的那个报价方案在哪”系统根本不知道“上次”“那个”指什么也不知道该去哪个文档里找答案。这些问题不是换一个更强的模型就能解决的而需要在工程上设计“怎么理解需求、怎么检索内容、怎么生成答案、怎么处理失败”这一整套逻辑。所以我现在的习惯是动手写代码之前先逼着自己把需求拆成一张表。每一行是一个子任务要有输入、输出、依赖和失败时的替代方案。如果这个表画不出来说明需求根本还没想清楚。1.2 把模糊需求拆成可执行的子任务拿“AI客服”来说看起来就一个功能但背后至少包括这些子任务子任务输入输出依赖失败兜底意图识别用户原话分类标签售后/售前/闲聊无走默认流程实体抽取用户原话意图标签产品名、订单号等关键实体意图识别结果反问用户补齐知识检索实体历史消息相关文档片段知识库索引转人工答案生成检索片段上下文回答文本检索结果告知“无法确认”兜底决策置信度用户情绪转人工/继续对话上述结果一律转人工这张表的价值在于它把“AI”变成了普通的后端模块。每个子任务都可以先写一个最朴素的最小实现单独测试再串起来。你会发现很多问题根本不需要大模型参与比如实体抽取如果只是订单号正则表达式就够了意图识别如果只有几个固定场景分类模型也比大模型便宜得多。1.3 模型选型的判断标准我的选型标准从来不是“哪个评测分数高”而是“哪个模型和我的任务足够匹配且成本可控”。同一个系统里可以同时用多个模型更轻的模型做意图识别和判断更强的模型做生成和推理甚至可以用本地小模型处理敏感数据。具体怎么选我会看四个维度任务复杂度、数据隐私要求、响应延迟上限、单请求成本预算。拿这个知识库助手举例答案生成需要读大量文档并推理所以用最强的生成模型但识别用户是提问还是闲聊用一个很小的分类模型就够了。很多团队一上来就把所有能力塞给一个大模型结果延迟高、费用贵还经常在处理简单任务时表现得不如小模型稳定。2. Prompt工程从“会说话”到“会说指令”如果AI工程的骨架是任务拆解那血肉就是Prompt。大部分人把Prompt当成“写一段话告诉AI要做什么”这没错但工程化的Prompt讲究的不是说人话而是像写接口文档一样写指令。2.1 为什么Prompt是AI工程的灵魂模型的本质是“根据概率续写文本”同一个问题换个说法结果可能完全不同。Prompt就是我们用来约束这个概率分布的工具。它决定了模型的角度、格式、语气以及遇到边界条件时的行为。真正的工程化Prompt至少要包含四部分角色与目标模型以什么身份、达成什么目标。任务上下文输入数据从哪里来、怎么组织。输出格式规范JSON还是纯文本字段怎么定义。边界与兜底行为答不出来时怎么办哪些话题不处理。我见过很多项目模型效果在离线测试里不错一上真实流量就崩80%的原因出在Prompt没写清楚边界。比如你需要AI只能基于给定资料回答如果Prompt里不强调这一点模型就会自由发挥“编”出相关内容你要求输出JSON如果不给一个具体示例它就可能输出带Markdown代码块标记的JSON解析逻辑直接报错。2.2 一个真实Prompt的演进过程拿我的知识库问答助手举例第一版Prompt是这样的你是公司内部知识库助手请根据文档回答用户问题。上线前测试效果惨不忍睹模型经常从自己的常识里找答案完全无视资料。后来我迭代成了这样你是一名企业内部知识库问答助手。请严格基于你得到的“参考资料”回答用户问题。 规则 1. 只允许使用参考资料里的信息禁止自行补充或猜测。 2. 如果参考资料里找不到答案回答“资料库中暂无相关内容请转人工处理”。 3. 回答控制在150字以内使用中文用列表或短句组织。 4. 每一步先判断用户问题是否明确不明确则先反问一个澄清问题。 参考资料 {retrieved_docs} 用户问题 {user_question} 请按以下JSON格式输出 { need_clarify: true或者false, answer: 你的回答 }这里每一句话都是在约束模型的“自由发挥空间”。给它一个JSON输出结构对后面接程序处理特别重要——我可以直接解析返回值不需要再做一个自然语言后处理。Prompt不是写得越长越好而是要写得具体把可能跑偏的所有路口都堵上。2.3 Prompt版本管理与回归测试Prompt改一次整体效果就变一次。我一开始没意识到这一点经常“随手修了一下话术”结果过了两周才发现有些历史问题开始答非所问。后来我学乖了每个Prompt都有版本号修改前先跑一套回归用例。做法很简单准备50到100条覆盖常见问题的测试集每次改动Prompt后全量跑一遍。我维护了一张Prompt版本表版本核心改动回归通过率备注v1.0初始版本62%经常乱补知识v1.1增加“只基于资料”规则78%乱补减少v1.2增加不明确时反问85%对模糊问题处理更好v1.3调整JSON格式描述88%解析错误率下降这个回归集不一定要自动化手动也行但必须固定下来每次改动前后对比。没有对比就没有资格谈“优化”。3. 让AI动起来Agent与多步工作流设计有了PromptAI还只是在“回答”要让它真正干活就需要把它放进一个能决策、能调用工具、能自我纠错的循环里。这就是Agent。3.1 从单次生成到Agent循环我一开始把AI看作一个函数进文本出文本。但很多需求不是一次生成能搞定的。比如“帮我把大模型的API调用封装成Python函数”模型需要先理解需求然后检索相关的API文档再利用工具执行代码可能还要根据执行结果修复报错。这一长串动作就是Agent的感知-规划-行动循环。工程上最简单的Agent循环可以概括为四步把用户目标和当前状态组织成上下文发给模型。模型决定下一步动作可能是调用某个工具也可能是输出最终答案。程序执行该动作把结果追加到上下文里。再把新上下文发回给模型直到模型输出“结束”或达到最大步数。这里有个很多人踩过的坑不加步数上限。模型可能会在一个错误里来回循环把上下文撑爆。所以我在Agent设计里一定会设最大迭代次数默认5次超过就强制终止并降级到人工。3.2 一个可跑的Agent工作流示例我常用Python做Agent原型核心思路不复杂用伪代码展示是这样def run_agent(user_request): context [{role: user, content: user_request}] for step in range(MAX_STEPS): response call_llm(context, toolsTOOLS) if response.is_final_answer(): return response.content tool_name response.tool_name tool_input response.tool_input tool_result execute_tool(tool_name, tool_input) context.append({role: assistant, content: response.message}) context.append({role: tool, content: tool_result}) return fallback_to_human(user_request)实际做的时候我会给模型提供几个预设工具搜索知识库、查询订单状态、发提醒消息。模型需要先用工具还是直接回答由它自己判断但工具的入参和返回结构都必须提前严格定义。工具返回的结果要用一个结构化文本塞回上下文而不是直接把一段乱七八糟的HTML丢进Prompt否则模型会迷失方向。3.3 多AI协作的编排套路做复杂业务时单个Agent往往又长又笨。我更倾向多AI协作让不同模型负责不同环节。比如这个知识库助手我会安排一个轻量模型先做用户意图分类和追问一个强模型负责综合检索结果做最终答案再安排一个小模型做答案安全性和格式的校验。多模型并用最怕的是上下文互相污染。我的经验是每个环节只把“必要的信息”传给下一个环节尽量缩减Prompt长度也在一定程度上降低了费用。举个例子意图分类模型只需要输出一个标签和置信度检索模块根据标签和实体去搜文档最终生成模型看到的永远是“检索结果切片当前问题历史关键摘要”而不是把所有中间过程全灌给它。4. 工程化落地的关键数据、评估与监控我在这个项目做到一半的时候发现一个问题模型还可以Prompt也在调但缺少“怎么算好”的标尺。AI工程和传统软件最大的区别就是结果不是确定性的没有标准化测试根本没法判断改动是好是坏。4.1 数据是AI工程的地基所有效果都建立在数据上。刚开始做知识库问答我直接把几十个PDF一股脑喂给模型效果很差因为它连文档结构都分不清。后来我把数据整理成三类FAQ对的自然语言问答、长文档切片、用户反馈工单。每种数据分别处理FAQ对用来构造训练和评测集长文档切片用来做检索索引用户反馈工单用来看真实问题和个人感受。这里想提醒一个新朋友别急着上向量化。很多人一看“知识库”就想到Embedding和向量数据库。但如果你只有几百个结构化问答对用传统关键词索引甚至直接查表都比向量检索可靠得多。向量检索适合“语义相似”场景但得先保证切片质量和元数据完整否则检索回来的就是一堆噪音。4.2 离线评估与回归集我搭了一个很简单的离线评测流程。每次改动Prompt或底层模型我就跑一遍回归集。评估指标不追求高深主要看三类命中率参考答案要点是否出现在AI输出里。胡编率AI输出里有没有资料中不存在的事实。格式合规率输出能否被程序正常解析处理。回归集我一般只挑真实用户提过的问题再加上一些故意刁难的边界问题比如“你昨天说的和今天怎么不一样”这类。跑完以后每项打分记录到一张表里。这样每次改动看数据说话不靠感觉。4.3 线上监控的三板斧上线之后我发现自己最需要的不是看Prompt模板而是看每个真实请求到底发生了什么。我做了三样东西请求日志记录每条消息的输入、输出、耗时、调用的模型版本和Prompt版本。反馈按钮在界面上加“有帮助/没帮助”按钮用户点了以后回传结果。坏例回放每天把用户标记“没帮助”的对话提取出来重新跑一遍离线评测确认是模型问题还是检索问题。这套监控体系帮我解决了很多隐形问题。比如有段时间发现“没帮助”率突然升高一查日志发现是上游知识库更新后某个类别的文档没有切干净导致检索混乱。如果没有日志回放我根本想不到是这个原因。5. 部署与成本从一个Python脚本到稳定服务很多教程到“调用API成功”就结束了但真实项目里最磨人的往往是把Demo变成稳定服务的过程。你需要应对延迟、并发、超时、成本还有模型升级带来的行为变化。5.1 自部署还是调API我的取舍标准做AI工程首先得决定模型放哪跑。我的判断标准不复杂就三问数据能出内网吗不能就自部署。并发和延迟要求能接受商业API的成本吗可以就调API。团队有没有能力维护推理服务没有就别自找麻烦。下面是我常用的对比表维度调用商业API自部署模型启动速度快一个Key就能跑慢要装环境、买卡、调显存成本模型按Token付费用适合中低并发固定GPU成本适合高并发或敏感数据可控性弱模型可能会悄悄升级强版本锁定行为稳定运维复杂度低高要盯监控做扩容我自己的项目一开始先用商业API验证效果后来因为数据隐私原因改成了自部署。建议你也先跑API产品逻辑稳定了再考虑自部署不要一上来就买卡。5.2 部署一个LLM服务时踩过的坑自部署这件事纸上谈兵容易真上手全是不一样。我踩过的几个坑值得专门说一下显存崩溃模型是FP16加载的但推理框架默认会申请额外显存并发一高就直接OOM。我把队列长度限到比较低并开启张量并行才稳定下来。具体参数要看你的GPU型号但原则是先跑一轮压测再放量。并发与连接池一开始每次请求都新建连接延迟高还容易连不上。改成复用连接池并设置超时重试效果好很多。流式输出被网关截断我们用了流式输出但网关只允许几秒响应体缓冲导致用户看到一半就断了。最后改为关闭缓冲或直接走长连接才解决。加载时间与冷启动模型加载要几十秒如果实例经常销毁重建体验很糟糕。我保留了一个常驻的推理实例闲时把并发降到最低也不去动它。5.3 成本控制经验AI工程如果没控制好成本产品做得再好也可能亏本。我的成本控制三板斧是缓存、分层、限流。缓存是最直接的。用户问的问题经常重复尤其是内部知识库场景。我建了一个语义缓存层将用户问题做Embedding先查缓存如果和过去问题相似度超过一个阈值就直接返回历史答案不再调用大模型。这个优化直接省了40%的生成费用。分层是说便宜模型能干的事就不让贵模型干。意图识别、格式整理用本地小模型真正需要复杂推理的才调用大模型。我统计过项目中70%以上的请求其实不需要最强模型参与。限流则是保护预算。每个用户每天的最大请求次数、单次请求的最大Token数都要有硬限制。不要觉得这是对用户不好反而先限制后面再放开比一开始敞开最后失控好得多。6. 复盘我认为AI工程最值钱的四个习惯项目收尾之后我回看整个过程最终沉淀下来的不是某个具体技术而是几个做事的习惯。这些东西比任何模型参数都值钱。6.1 先跑通最小闭环再谈优化我的毛病是容易陷在一个环节里抠细节比如花三天调一个Prompt结果整体链路根本没通。后来我强制自己先走通一个最简单的闭环哪怕答案质量一般先把“用户提问→意图识别→检索→生成→返回”整条链路跑起来。闭环通了后面每个环节的优化才有实际意义否则你优化的东西根本没法验证。6.2 每一次改动都要有对比数据没有数据支撑的改动我心里是不安的。现在我对任何Prompt修改、任何模型切换都要求先跑一遍统一的回归集回答三个问题效果变好了吗成本变高了吗延迟变长了吗如果三个指标里有任何一个恶化就必须重新评估这次改动是否值得。AI是概率系统没有AB对照就上线是拿用户当测试集。6.3 保留决策上下文很多踩过的坑当时重复犯错的原因是没记录。现在我会为每个重要变化写一份简短说明包括原因、可能的副作用、涉及哪些Prompt版本。这个文档不给自己设什么复杂模板就半页纸但后面排查问题时它是救命稻草。曾经有一次我发现效果回退查了半天才发现是另一个同事改了一个共享Prompt的措辞。如果那份变化记录在的话五分钟就能定位。6.4 重视人机边界别迷信全自动最后一点也许是最重要的一点AI工程不等于把所有环节都交给AI。在关键流程上要设人工兜底比如客服系统里只要用户情绪强烈或置信度低就立刻转人工知识库助手答非所问时允许用户一键反馈而不是硬撑着继续对话。这不是退步反而是负责任的做法。用户不会因为一个AI偶尔回答问题而信赖你但会因为它在不确定时知道找人来解决而信任你。AI工程从零到落地没有一条通天捷径。它更像是在确定性系统和不确定性模型之间搭桥。我们没法让模型不胡说但可以通过工程手段给每一条输出加上约束、验证和兜底。这条路走下去你会发现“会调用模型”只是起点真正的能力是把一个概率玩具打磨成能被人依赖的工具。
从0到1落地AI应用：工程化约束模型随机性的完整复盘
最近有个做产品的朋友来找我开口就是“帮我做个AI客服能自动回复消息的那种”。我问他“你的知识库整理了吗用户问的东西从哪里检索多轮对话要不要保持上下文答不上来要不要转人工”他愣了半天。这个场景几乎就是大多数“从零开始做AI”的真实写照——大家都以为AI工程的核心是调用一个模型真正走下来才发现模型只是最后那层皮真正的工程量全在模型外面。这篇文章记录的是我自己从0到1跑通一个AI应用项目的完整复盘。它不是理论教程而是一套我在实际项目里反复调整后沉淀下来的思考方式和实操路径。你可能是刚接触AI工程的开发者也可能是有过一些调用经验、但还没把模型落地成稳定功能的人。我会从问题定义、Prompt工程、Agent编排、部署调优到成本控制一条线讲下来尽量说人话能直接照着做。这篇的核心就一句话AI工程的本质不是写代码调用API而是用工程方法把模型的随机性约束成可依赖的产品能力。1. 为什么先谈问题定义而不是选模型我见过太多团队第一步就是“选个大模型”然后拿个Demo到处演示最后却发现离能上线的产品还差十万八千里。问题不出在模型不够强而出在根本没人把“要做的事”定义清楚。1.1 一个Demo和一个产品之间的距离Demo很容易做。拿一个开源模型或者调一下公共大模型接口输入问题、输出答案三分钟就能跑出看起来还不错的效果。但这其中缺失了很多关键环节用户的输入可能错别字连篇、问题可能带情绪回答可能引用一个不存在的知识也可能在用户多问两句之后就把之前的对话忘光了。我当时接的项目是一个内部知识库问答助手。Demo阶段所有人都说“效果很好”但真要把知识库导进去开始测试问题全冒出来了。比如同事问“上次分享会提到的那个报价方案在哪”系统根本不知道“上次”“那个”指什么也不知道该去哪个文档里找答案。这些问题不是换一个更强的模型就能解决的而需要在工程上设计“怎么理解需求、怎么检索内容、怎么生成答案、怎么处理失败”这一整套逻辑。所以我现在的习惯是动手写代码之前先逼着自己把需求拆成一张表。每一行是一个子任务要有输入、输出、依赖和失败时的替代方案。如果这个表画不出来说明需求根本还没想清楚。1.2 把模糊需求拆成可执行的子任务拿“AI客服”来说看起来就一个功能但背后至少包括这些子任务子任务输入输出依赖失败兜底意图识别用户原话分类标签售后/售前/闲聊无走默认流程实体抽取用户原话意图标签产品名、订单号等关键实体意图识别结果反问用户补齐知识检索实体历史消息相关文档片段知识库索引转人工答案生成检索片段上下文回答文本检索结果告知“无法确认”兜底决策置信度用户情绪转人工/继续对话上述结果一律转人工这张表的价值在于它把“AI”变成了普通的后端模块。每个子任务都可以先写一个最朴素的最小实现单独测试再串起来。你会发现很多问题根本不需要大模型参与比如实体抽取如果只是订单号正则表达式就够了意图识别如果只有几个固定场景分类模型也比大模型便宜得多。1.3 模型选型的判断标准我的选型标准从来不是“哪个评测分数高”而是“哪个模型和我的任务足够匹配且成本可控”。同一个系统里可以同时用多个模型更轻的模型做意图识别和判断更强的模型做生成和推理甚至可以用本地小模型处理敏感数据。具体怎么选我会看四个维度任务复杂度、数据隐私要求、响应延迟上限、单请求成本预算。拿这个知识库助手举例答案生成需要读大量文档并推理所以用最强的生成模型但识别用户是提问还是闲聊用一个很小的分类模型就够了。很多团队一上来就把所有能力塞给一个大模型结果延迟高、费用贵还经常在处理简单任务时表现得不如小模型稳定。2. Prompt工程从“会说话”到“会说指令”如果AI工程的骨架是任务拆解那血肉就是Prompt。大部分人把Prompt当成“写一段话告诉AI要做什么”这没错但工程化的Prompt讲究的不是说人话而是像写接口文档一样写指令。2.1 为什么Prompt是AI工程的灵魂模型的本质是“根据概率续写文本”同一个问题换个说法结果可能完全不同。Prompt就是我们用来约束这个概率分布的工具。它决定了模型的角度、格式、语气以及遇到边界条件时的行为。真正的工程化Prompt至少要包含四部分角色与目标模型以什么身份、达成什么目标。任务上下文输入数据从哪里来、怎么组织。输出格式规范JSON还是纯文本字段怎么定义。边界与兜底行为答不出来时怎么办哪些话题不处理。我见过很多项目模型效果在离线测试里不错一上真实流量就崩80%的原因出在Prompt没写清楚边界。比如你需要AI只能基于给定资料回答如果Prompt里不强调这一点模型就会自由发挥“编”出相关内容你要求输出JSON如果不给一个具体示例它就可能输出带Markdown代码块标记的JSON解析逻辑直接报错。2.2 一个真实Prompt的演进过程拿我的知识库问答助手举例第一版Prompt是这样的你是公司内部知识库助手请根据文档回答用户问题。上线前测试效果惨不忍睹模型经常从自己的常识里找答案完全无视资料。后来我迭代成了这样你是一名企业内部知识库问答助手。请严格基于你得到的“参考资料”回答用户问题。 规则 1. 只允许使用参考资料里的信息禁止自行补充或猜测。 2. 如果参考资料里找不到答案回答“资料库中暂无相关内容请转人工处理”。 3. 回答控制在150字以内使用中文用列表或短句组织。 4. 每一步先判断用户问题是否明确不明确则先反问一个澄清问题。 参考资料 {retrieved_docs} 用户问题 {user_question} 请按以下JSON格式输出 { need_clarify: true或者false, answer: 你的回答 }这里每一句话都是在约束模型的“自由发挥空间”。给它一个JSON输出结构对后面接程序处理特别重要——我可以直接解析返回值不需要再做一个自然语言后处理。Prompt不是写得越长越好而是要写得具体把可能跑偏的所有路口都堵上。2.3 Prompt版本管理与回归测试Prompt改一次整体效果就变一次。我一开始没意识到这一点经常“随手修了一下话术”结果过了两周才发现有些历史问题开始答非所问。后来我学乖了每个Prompt都有版本号修改前先跑一套回归用例。做法很简单准备50到100条覆盖常见问题的测试集每次改动Prompt后全量跑一遍。我维护了一张Prompt版本表版本核心改动回归通过率备注v1.0初始版本62%经常乱补知识v1.1增加“只基于资料”规则78%乱补减少v1.2增加不明确时反问85%对模糊问题处理更好v1.3调整JSON格式描述88%解析错误率下降这个回归集不一定要自动化手动也行但必须固定下来每次改动前后对比。没有对比就没有资格谈“优化”。3. 让AI动起来Agent与多步工作流设计有了PromptAI还只是在“回答”要让它真正干活就需要把它放进一个能决策、能调用工具、能自我纠错的循环里。这就是Agent。3.1 从单次生成到Agent循环我一开始把AI看作一个函数进文本出文本。但很多需求不是一次生成能搞定的。比如“帮我把大模型的API调用封装成Python函数”模型需要先理解需求然后检索相关的API文档再利用工具执行代码可能还要根据执行结果修复报错。这一长串动作就是Agent的感知-规划-行动循环。工程上最简单的Agent循环可以概括为四步把用户目标和当前状态组织成上下文发给模型。模型决定下一步动作可能是调用某个工具也可能是输出最终答案。程序执行该动作把结果追加到上下文里。再把新上下文发回给模型直到模型输出“结束”或达到最大步数。这里有个很多人踩过的坑不加步数上限。模型可能会在一个错误里来回循环把上下文撑爆。所以我在Agent设计里一定会设最大迭代次数默认5次超过就强制终止并降级到人工。3.2 一个可跑的Agent工作流示例我常用Python做Agent原型核心思路不复杂用伪代码展示是这样def run_agent(user_request): context [{role: user, content: user_request}] for step in range(MAX_STEPS): response call_llm(context, toolsTOOLS) if response.is_final_answer(): return response.content tool_name response.tool_name tool_input response.tool_input tool_result execute_tool(tool_name, tool_input) context.append({role: assistant, content: response.message}) context.append({role: tool, content: tool_result}) return fallback_to_human(user_request)实际做的时候我会给模型提供几个预设工具搜索知识库、查询订单状态、发提醒消息。模型需要先用工具还是直接回答由它自己判断但工具的入参和返回结构都必须提前严格定义。工具返回的结果要用一个结构化文本塞回上下文而不是直接把一段乱七八糟的HTML丢进Prompt否则模型会迷失方向。3.3 多AI协作的编排套路做复杂业务时单个Agent往往又长又笨。我更倾向多AI协作让不同模型负责不同环节。比如这个知识库助手我会安排一个轻量模型先做用户意图分类和追问一个强模型负责综合检索结果做最终答案再安排一个小模型做答案安全性和格式的校验。多模型并用最怕的是上下文互相污染。我的经验是每个环节只把“必要的信息”传给下一个环节尽量缩减Prompt长度也在一定程度上降低了费用。举个例子意图分类模型只需要输出一个标签和置信度检索模块根据标签和实体去搜文档最终生成模型看到的永远是“检索结果切片当前问题历史关键摘要”而不是把所有中间过程全灌给它。4. 工程化落地的关键数据、评估与监控我在这个项目做到一半的时候发现一个问题模型还可以Prompt也在调但缺少“怎么算好”的标尺。AI工程和传统软件最大的区别就是结果不是确定性的没有标准化测试根本没法判断改动是好是坏。4.1 数据是AI工程的地基所有效果都建立在数据上。刚开始做知识库问答我直接把几十个PDF一股脑喂给模型效果很差因为它连文档结构都分不清。后来我把数据整理成三类FAQ对的自然语言问答、长文档切片、用户反馈工单。每种数据分别处理FAQ对用来构造训练和评测集长文档切片用来做检索索引用户反馈工单用来看真实问题和个人感受。这里想提醒一个新朋友别急着上向量化。很多人一看“知识库”就想到Embedding和向量数据库。但如果你只有几百个结构化问答对用传统关键词索引甚至直接查表都比向量检索可靠得多。向量检索适合“语义相似”场景但得先保证切片质量和元数据完整否则检索回来的就是一堆噪音。4.2 离线评估与回归集我搭了一个很简单的离线评测流程。每次改动Prompt或底层模型我就跑一遍回归集。评估指标不追求高深主要看三类命中率参考答案要点是否出现在AI输出里。胡编率AI输出里有没有资料中不存在的事实。格式合规率输出能否被程序正常解析处理。回归集我一般只挑真实用户提过的问题再加上一些故意刁难的边界问题比如“你昨天说的和今天怎么不一样”这类。跑完以后每项打分记录到一张表里。这样每次改动看数据说话不靠感觉。4.3 线上监控的三板斧上线之后我发现自己最需要的不是看Prompt模板而是看每个真实请求到底发生了什么。我做了三样东西请求日志记录每条消息的输入、输出、耗时、调用的模型版本和Prompt版本。反馈按钮在界面上加“有帮助/没帮助”按钮用户点了以后回传结果。坏例回放每天把用户标记“没帮助”的对话提取出来重新跑一遍离线评测确认是模型问题还是检索问题。这套监控体系帮我解决了很多隐形问题。比如有段时间发现“没帮助”率突然升高一查日志发现是上游知识库更新后某个类别的文档没有切干净导致检索混乱。如果没有日志回放我根本想不到是这个原因。5. 部署与成本从一个Python脚本到稳定服务很多教程到“调用API成功”就结束了但真实项目里最磨人的往往是把Demo变成稳定服务的过程。你需要应对延迟、并发、超时、成本还有模型升级带来的行为变化。5.1 自部署还是调API我的取舍标准做AI工程首先得决定模型放哪跑。我的判断标准不复杂就三问数据能出内网吗不能就自部署。并发和延迟要求能接受商业API的成本吗可以就调API。团队有没有能力维护推理服务没有就别自找麻烦。下面是我常用的对比表维度调用商业API自部署模型启动速度快一个Key就能跑慢要装环境、买卡、调显存成本模型按Token付费用适合中低并发固定GPU成本适合高并发或敏感数据可控性弱模型可能会悄悄升级强版本锁定行为稳定运维复杂度低高要盯监控做扩容我自己的项目一开始先用商业API验证效果后来因为数据隐私原因改成了自部署。建议你也先跑API产品逻辑稳定了再考虑自部署不要一上来就买卡。5.2 部署一个LLM服务时踩过的坑自部署这件事纸上谈兵容易真上手全是不一样。我踩过的几个坑值得专门说一下显存崩溃模型是FP16加载的但推理框架默认会申请额外显存并发一高就直接OOM。我把队列长度限到比较低并开启张量并行才稳定下来。具体参数要看你的GPU型号但原则是先跑一轮压测再放量。并发与连接池一开始每次请求都新建连接延迟高还容易连不上。改成复用连接池并设置超时重试效果好很多。流式输出被网关截断我们用了流式输出但网关只允许几秒响应体缓冲导致用户看到一半就断了。最后改为关闭缓冲或直接走长连接才解决。加载时间与冷启动模型加载要几十秒如果实例经常销毁重建体验很糟糕。我保留了一个常驻的推理实例闲时把并发降到最低也不去动它。5.3 成本控制经验AI工程如果没控制好成本产品做得再好也可能亏本。我的成本控制三板斧是缓存、分层、限流。缓存是最直接的。用户问的问题经常重复尤其是内部知识库场景。我建了一个语义缓存层将用户问题做Embedding先查缓存如果和过去问题相似度超过一个阈值就直接返回历史答案不再调用大模型。这个优化直接省了40%的生成费用。分层是说便宜模型能干的事就不让贵模型干。意图识别、格式整理用本地小模型真正需要复杂推理的才调用大模型。我统计过项目中70%以上的请求其实不需要最强模型参与。限流则是保护预算。每个用户每天的最大请求次数、单次请求的最大Token数都要有硬限制。不要觉得这是对用户不好反而先限制后面再放开比一开始敞开最后失控好得多。6. 复盘我认为AI工程最值钱的四个习惯项目收尾之后我回看整个过程最终沉淀下来的不是某个具体技术而是几个做事的习惯。这些东西比任何模型参数都值钱。6.1 先跑通最小闭环再谈优化我的毛病是容易陷在一个环节里抠细节比如花三天调一个Prompt结果整体链路根本没通。后来我强制自己先走通一个最简单的闭环哪怕答案质量一般先把“用户提问→意图识别→检索→生成→返回”整条链路跑起来。闭环通了后面每个环节的优化才有实际意义否则你优化的东西根本没法验证。6.2 每一次改动都要有对比数据没有数据支撑的改动我心里是不安的。现在我对任何Prompt修改、任何模型切换都要求先跑一遍统一的回归集回答三个问题效果变好了吗成本变高了吗延迟变长了吗如果三个指标里有任何一个恶化就必须重新评估这次改动是否值得。AI是概率系统没有AB对照就上线是拿用户当测试集。6.3 保留决策上下文很多踩过的坑当时重复犯错的原因是没记录。现在我会为每个重要变化写一份简短说明包括原因、可能的副作用、涉及哪些Prompt版本。这个文档不给自己设什么复杂模板就半页纸但后面排查问题时它是救命稻草。曾经有一次我发现效果回退查了半天才发现是另一个同事改了一个共享Prompt的措辞。如果那份变化记录在的话五分钟就能定位。6.4 重视人机边界别迷信全自动最后一点也许是最重要的一点AI工程不等于把所有环节都交给AI。在关键流程上要设人工兜底比如客服系统里只要用户情绪强烈或置信度低就立刻转人工知识库助手答非所问时允许用户一键反馈而不是硬撑着继续对话。这不是退步反而是负责任的做法。用户不会因为一个AI偶尔回答问题而信赖你但会因为它在不确定时知道找人来解决而信任你。AI工程从零到落地没有一条通天捷径。它更像是在确定性系统和不确定性模型之间搭桥。我们没法让模型不胡说但可以通过工程手段给每一条输出加上约束、验证和兜底。这条路走下去你会发现“会调用模型”只是起点真正的能力是把一个概率玩具打磨成能被人依赖的工具。
