AI工程化实战：从提示词、RAG到Agent的落地避坑指南

1. AI工程为什么和“调API”完全不是一回事两年前我第一次用大模型做一个信息抽取工具时觉得这事简单得不像话把文档喂给模型写几行提示词结构化输出就出来了demo效果惊艳得让我差点以为AI工程就是写提示词。直到真正要把它部署上线、面对真实用户的海量输入我才发现自己踩的坑一个接一个同样的提示词在不同输入下结果时好时坏、模型偶尔胡说八道、评测效果完全凭感觉、数据一换环节就崩。那段经历让我意识到所谓“AI工程”核心不在于模型本身而在于怎么把模型的概率性输出变成可控、可测、可持续迭代的生产能力。这也是我写这篇内容的核心目的抛开会话机器人这类浅层玩法把从零开始建设AI工程能力要面对的技术选型、开发链路、评测机制、落地避坑完整过一遍。适合三类人看刚转行做AI应用的后端工程师、在团队里被迫从零搭AI基础设施的技术负责人、以及学了半年模型原理却没完整做过一个线上级项目的初学者。先说一个必须纠正的认知很多人觉得AI工程和普通软件开发只是“多接了一个大模型API”的区别这个想法成本很高。传统软件工程构建的是确定性系统——同一个输入永远产生同一个输出逻辑出错有明确的堆栈可以查。AI应用构建的是概率性系统——模型给你的是一个分布哪怕你输入完全一样输出的措辞甚至内容都可能不同。这个差异波及工程的每一个环节。拿测试来说传统后端接口验证直接断言返回值字段不对就是Bug。AI应用你没法做这种断言因为本来就存在多个正确答案。你要测的是语义对不对、信息全不全、引用靠不靠谱。拿调试来说传统代码出问题日志、断点、堆栈能定位到具体行AI应用效果不对你到底该改Prompt、换模型、调参数、补数据还是修检索逻辑五个变量互相牵连定位成本远高于普通Bug。还有一点经常被忽略数据在AI工程里既不是输入文件也不是配置项而是一等公民。传统开发里调一条SQL逻辑数据有问题顶多是脏数据。AI工程里数据直接决定模型行为的上限你的语料、你的评测集、你的反馈回流全都需要像代码一样做版本管理。你想想一个模型系统跑着跑着线上用户反馈越来越多你以为在迭代提示词其实你是在手动做数据标注。从零做AI工程先把这个心智模型翻转过来后面所有环节才不会跑偏。2. 从零起步的AI工程底座环境、模型与工具链2.1 环境与工程基建先解决“复现”两个字很多人从零搭AI项目时环境管理是用什么装什么跑通了就进下一步觉得这是在浪费时间。实际上AI项目的依赖复杂程度远超普通后端项目Python版本、CUDA版本、PyTorch版本、各模型SDK之间经常互相打架。我建议在最开始就用环境管理工具把依赖隔离做好比如uv或conda别直接在系统级Python里装包否则一周后你就会被一堆依赖冲突逼疯。工程基建方面除了代码用Git我强烈建议把Prompt、评测集、数据集也纳入版本管理。Prompt变更往往比代码变更影响还要大你得知道线上那个版本效果不好是在哪一次提示词修改引入的。数据集的版本管理更不用说了没有稳定的评测集你连“这次改动到底是变好了还是变差了”都判断不了谈什么工程化。下面给一个最小可用的项目目录结构参考的是我这几年跑下来的习惯ai-engineering-project/ ├── app/ # 应用服务代码 │ ├── workflows/ # Agent/工作流编排代码 │ └── tools/ # 工具函数定义 ├── prompts/ # 提示词模板版本控制 │ ├── system/ │ └── fewshot/ ├── datasets/ # 评测集与回归集 │ ├── golden_set.jsonl │ └── adversarial_set.jsonl ├── evals/ # 评测脚本与指标 │ ├── metrics.py │ └── run_evals.py ├── scripts/ # 数据清洗、回流等脚本 └── pyproject.toml # 项目依赖这套结构你可以直接抄作业。看似繁琐但对工程化太重要了。我见过太多AI项目代码只有一个main.py提示词直接写死在字符串里测试集靠记忆维护最后想回归验证一下之前修过的Bug是否复发只能翻聊天记录。那不是工程那是手工作坊。2.2 模型选型凭Benchmark选模型是最贵的错模型选型永远是AI工程里最不该拍脑袋的决策。闭源API和开源模型各有各的适用场景我的建议是“先按场景约束排除再做基准测试选型”而不是“哪个分数高用哪个”。搞清楚你的核心约束是哪些数据是否允许出域合规红线、单次调用的成本上限、响应时延要求、需要多长的上下文窗口、对中文还是英文更敏感。这几个条件一列很多模型根本不用纠结。我整理过一个简易对比表供选型时参考维度闭源API开源本地部署效果能力通常更强迭代快取决于参数规模和微调质量数据安全数据出域需合规评估完全私有化数据不出内网成本结构按Token计费量越大成本越高前期硬件成本高跑起来边际成本低运维负担几乎为零需要维护GPU集群、模型版本定制能力有限只能提示词/微调可以全参/LoRA微调可以剪枝量化上线速度快慢需考虑部署方案另外有一条经验别拿公开榜单一刀切拿自己的真实数据去跑。公开榜单里全是干净的标准数据集你的业务数据长什么样它们不知道。Pattern上差一点点真实效果可能差很远。每次选型抽一百条真实业务数据跑一遍同一套流程人工打分对比比自己看十篇评测报告都管用。2.3 开发框架与调试手段别只盯LangChain目前开发AI应用可选的框架很多LangChain、LlamaIndex、以及各家模型SDK自带的原生工具链。我的建议是框架选型要按项目复杂度来不要为可用而用。早期项目阶段快速验证时直接用原生SDK完全够了。一旦流程复杂到需要多个路由分支、多次工具调用、多种记忆策略再用LangChain或类似框架来管理编排逻辑会省力很多。还有一定要学会利用各家平台的结构化输出能力。现在主流模型厂商的API都支持JSON Schema约束输出或者函数调用Function Calling。这类能力能解决大量“模型输出非预期结构”的问题比你在提示词里写一百遍“请严格按照JSON格式输出”管用得多。我自己的经验是用结构约束把模型的输出压缩到程序可解析的范围内再靠程序逻辑兜底是AI工程里稳定性的第一道防线。调试方面两句心得日志一定要结构化每轮调用把模型版本、提示词版本、Token消耗、输入输出原文都记录下来复现一定要固定排查问题时把采样参数temperature、top_p都记录清楚否则你永远不知道某个错误是Bug还是模型随机的。温度调成0也不能完全消除随机性但能显著提高复现概率。3. 核心开发链路逐个拆解提示词、RAG与Agent架构3.1 Prompt Engineering不只是“写几句话”Prompt Engineering是所有AI应用的底层能力但我见过很多把这事理解窄了的团队——以为就是把需求描述得花哨一点。真正的Prompt工程包含三个层次系统提示词设计、少样本示例设计、输出协议约束。系统提示词定义模型的“角色和边界”。一个成熟的系统提示词至少要覆盖五件事角色定位你是谁、任务定义你要做什么、输入说明你会收到什么、输出规范你要给出什么格式、边界约束哪些不做、哪些拒绝回答。以我的经验很多提示词翻车不是因为写得不够多而是任务边界没划清模型自由发挥的空间太大。少样本示例的作用常被低估。大模型的In-Context Learning能力决定了“你给什么例子它就默认任务长什么样”。你丢三条高质量的输入-输出对往往比在提示词里写三百字规则更有效。写少样本示例时尽量选择题型覆盖全面的几条别都挑同一种情况。输出协议方面能用结构化输出的API就别用纯提示词约束。以现在的主流模型API为例把响应格式Response Format设为JSON对象再配合一个字段说明模型就会严格按指定Schema吐结果。这能省掉大量解析报错和重试逻辑。分享一个我踩过的坑早期做信息抽取时我尝试在提示词里加一句“如果文中没有相关信息请输出空字符串”结果发现模型在模棱两可时还是会编造内容。后来改成“如果信息不全你可以输出null”并在输出协议中把字段设为可空问题才解决。这类“幻觉边界”问题提示词的设计比你想的影响大得多。3.2 RAG让模型拥有你的私有数据RAG几乎是从零做AI应用第二条必走的路。光靠大模型训练时的知识做业务是远远不够的你的内部FAQ、私有文档、实时数据都需要通过RAG的方式注入上下文。一个最小可用的RAG链路长这样文档加载 - 文本切分 - 向量化 - 存入向量库 ↓ 用户提问 - 向量化 - 向量检索 TopK - 拼装上下文 - 模型生成每一步都有坑。文本切分不是按固定字符数硬切要尊重语义边界按标题、段落、句子切否则检索回来的片段上下文不完整。向量化阶段要选一个和业务文本领域匹配的Embedding模型通用Embedding处理专业术语效果不好。向量库选型方面小规模用开源的Chroma或FAISS就行规模上来了再考虑高可用方案。检索策略上我的配置建议是召回数量TopK设在4到8之间配合重排序Rerank模型精排。有些同学把TopK设成50指望模型从巨大上下文里自己捞重点结果上下文越长模型越容易被无关信息干扰回答质量下降。检索的精度比召回量更重要——上下文里的噪声多模型输出会发散。RAG还有一个特别容易翻车的环节检索到空结果或检索结果与问题不匹配时模型会“强行回答”这时候最容易产生幻觉。工程上要加一道程序判断如果检索相似度低于某个阈值直接返回“知识库中暂无相关答案”别让模型硬编。这道防线的优先级比任何提示词优化都高。3.3 Agent与工具调用自主性是把双刃剑近两年Agent是绝对的热点但很多团队从零起步就直奔“全自主多Agent协作”这其实是个危险的起手式。Agent的本质是让模型自主决策“调用什么工具、以什么顺序调用、怎么处理结果”当这个决策链变长错误率是指数级累积的。我的实践建议是分两步走先用确定性的工作流Workflow落地再逐步给关键环节赋权Agent化。举个例子一个客服机器人第一步分类问题类型、第二步查知识库、第三步组装答案这三步在初期完全可以写成固定的代码流程每一步分别调用一次模型或检索。等流程跑顺了、每一步的输入输出都稳定了再考虑让模型自主决定某些场景跳步或调用额外工具。工具调用的设计是Agent工程质量的决定因素。每个工具函数一定要有清晰、无歧义的功能描述和参数定义因为模型就是靠这些描述来“理解”能不能用这个工具的。描述写得含糊模型要么不调用要么乱调用。另外所有工具调用都要加超时、限流、异常兜底工具不可用时Agent要能优雅降级而不是报错中断。多Agent协作更要克制。我的经验是能单Agent解决的场景不要上多Agent。两个模型互相传递信息时每一轮都会有信息损耗和随机误差Agent越多整体效果越难收敛。除非你的任务天然分角色且信息隔离需求很强比如一个检索、一个审核、一个汇总各自上下文独立否则单个Agent加工具编排在小规模场景里效率更高。3.4 先做工作流再做Agent一个能直接复用的判断标准在具体落地时怎么判断一个任务到底该用确定性工作流还是Agent我提供一个简单的判断标准如果这个任务的决策路径是可枚举的比如就是“分类-检索-生成”三选一或五选一就写死代码路由如果路径不可预知、需要模型动态探索比如开放域的调研整理才考虑Agent。大多数业务场景其实是前者。把可枚举的流程硬交给Agent得到的不是智能是难以Debug的随机性。从零做AI工程最稳的路径其实是先用工作流把业务跑通积累数据再看哪些环节模型自主决策带来的收益显著高且风险可控再把局部改成Agent。这一步的克制决定了项目是可控迭代还是失控返工。4. 评测体系与上线监控质量不是“感觉”出来的4.1 传统QA在AI应用上失灵了评测体系怎么重新搭很多从传统开发转过来的团队面对AI应用的第一反应是“我写一堆单测来断言输出”。这个思路需要修正你不能断言“模型必须输出这句话”但你可以断言“输出是否满足了业务约束”。所以AI评测体系的搭建逻辑是把质量拆成可检测的维度分别建模。以RAG问答为例我习惯把评测拆成四个维度评估维度考察内容常用方法答案正确性生成的回答是否正确人工打分/强模型评审/参考答案相似度忠实度回答是否基于给定上下文有无幻觉检查回答中的关键信息是否在上下文中上下文相关性检索回来的内容是否与问题相关计算检索结果与问题的语义相似度鲁棒性面对恶意/歧义/超出范围的问题的表现对抗样例集的通过率测试集的建设是评测的地基。我常用的结构包括三类数据黄金集golden set——覆盖核心业务场景的典型问题加上的标准答案边界集——语义模糊、包含陷阱、故意误导的问题回归集——历史上出过Bug、修过的Case的存档。每次改动上线前拿这三类数据全量跑一遍效果差不得过阈值。没有这个机制你的系统就是在一艘漏水的船上不断补洞永远不知道前面补的洞是不是又裂了。4.2 自动化评估LLM-as-Judge能用但别迷信人工评测最准但成本高、效率低不可能每次迭代都拉一批人打分。所以工程化的评估体系一定要做自动化这里面最主流的方案就是LLM-as-Judge——用一个更强的模型给另一个模型的输出打分。LLM-as-Judge的好处是成本可控、标准统一、能规模化运行但它有一个根本局限裁判模型自己也会犯错、也会偏见。比如它可能偏好更长的回答长度偏见、偏好某个模型自认为的风格或者在某类问题上和业务方的判断不一致。所以我的建议是用“规则判定 LLM-judge”的混合评估策略。凡是有明确规则可查的全部用代码断言JSON结构合法吗必须包含关键字段吗引用来源存在吗这些别省。只有真正的语义判断比如“这个回答是否充分回答了用户问题”、“语气是否合适”才交给裁判模型。评测Prompt的质量决定裁判的可靠性。判定维度要拆细判定标准要写清楚最好让裁判先列根据再给分。你如果想搭这个体系可以参考下面的四步法定义维度 - 写评分标准 - 抽样本标定人工分 - 调裁判Prompt直到和人工分相关性达目标。4.3 上线后的成本、延迟与数据回流AI工程的长期主义系统上线只是开始后面真正烧钱烧精力的是成本控制、性能优化和数据回流这三件事。成本控制是我认为最容易被从零起步团队忽视的。按Token计费的模式下一旦流量上来费用会是肉眼可见的速度上涨。三个实用的降本手段一是加缓存层对高度相似或重复的用户请求直接用缓存结果二是模型级联简单请求先用便宜的小模型复杂请求才路由到大模型三是提示词压缩减掉冗余指令和不必要的上下文。这三个手段组合下来成本能降到原来的30%到50%我实测过。性能优化方面大模型接口天然是长尾延迟直接同步阻塞调用对用户体验很不友好。能流向式输出就流式输出能并行调用就并行。RAG检索要控制耗时向量检索本身很快瓶颈通常在文档解析和重排序环节。把链路的时间预算列一张表逐项优化你会发现最耗时的往往不是模型生成而是那些被忽略的串行环节。数据回流是把AI应用从“能跑”推向“越跑越好”的引擎。线上收集用户反馈——点赞、点踩、纠错、改写——这些数据定期清洗后进评测集再拿评测集筛选和微调。没有回流你的系统永远停留在一个静态水平模型能力涨了你的应用也吃不到红利。从工程第一天就把反馈埋点做好这是我这几年最后悔没更早做的事。5. 从零到一的学习路线与实战建议5.1 千万别从论文开始一条更高效的上手路径很多初学者一上来就扎进Transformer论文、注意力机制推导里半年后理论基础有了仍然不会做一个能上线的AI应用。我的建议恰恰相反先学会使用再理解原理让具体工程问题反向驱动理论学习。具体路径我建议走四步。第一步把Prompt Engineering基础打牢学会用主流模型的API做任务——信息抽取、摘要、对话熟悉模型的行为边界。第二步做一个完整的RAG问答应用覆盖从文档切分、向量化、检索到上下文拼装的全流程在这里你会第一次理解“为什么模型效果差不一定怪模型”。第三步把评测体系搭起来给你的问答应用建一套黄金集跑自动化评估建立“改动的可验证性”。第四步反向去补理论为什么Embedding能把语义映射到向量空间为什么注意力机制能处理长依赖带着问题学效率完全不同。技术资料方面直接啃主流框架的官方文档和开源项目的源码是最快路径。我特别建议找一个几千Star的成熟AI应用开源项目完整读一遍它的工程组织方式看它是怎么组织Prompt、怎么管理数据、怎么做评测的。真实项目的工程细节远比教程里的原理图有价值。5.2 团队协作视角角色补齐比单点技术更重要如果你是在团队里推动AI工程落地有个比技术更重要的层面角色协同。一个成熟的AI应用团队至少要覆盖四类工作应用开发搭服务、写工作流、做前端交互、算法与模型选模型、调提示词、做微调、数据与评测管语料、建评测集、跑评估、工程运维部署、监控、成本与稳定性保障。很多团队的AI项目死在数据与评测这个角色空缺上——大家都在研究怎么调模型没人认真建数据集、跑回归系统的质量基线一直悬空。从零起步我建议哪怕人少也一定要把“评测负责人”这个角色单列出来这个角色不对“实现功能”负责只对“质量数据可信”负责。5.3 一个必须避开的坑在项目第一天就“追求完美”AI工程项目最容易陷入的陷阱叫“过度工程化”。刚开始做时你可能想着要把多模态、自我进化、多Agent协作、流式工作流全都配上。我的经验是先砍出一个跑通核心链路的最小版本上线、收集真实反馈再按数据驱动逐步加复杂度。我做过一个信息抽取工具第一版就是一个模型API加一段JSON解析总共没几行代码但跑通了。随后根据真实用户反馈逐步加了自动重试、置信度过滤、人工审核界面。每次只加一个关键能力每次加完都有评测数据证明“确实有用”。这个节奏保证了每次改动都是前进而不是消耗。最后说一点我从零走过来的个人体会AI工程的门槛不仅在技术更在对不确定性的容忍和管理。你有没有把提示词当成和代码一样需要更新维护的资产有没有把评测当成和测试一样的质量关卡有没有把数据回流当成和日志监控一样的运维常态这三点做到了哪怕你的应用功能很简单它也是真正的“AI工程”。做不到即使你的模型调得天花乱坠也只是个漂在Demo阶段的玩具。