刚开始接手“ai-engineering”这类项目的时候我特别容易陷入一个误区以为把模型API接上调一调prompt能跑出几个看起来不错的结果这事儿就算干完了。直到业务方把真实数据怼到我脸上我才意识到AI工程从零开始真正难的地方不是让模型“听懂人话”而是让它在各种脏数据、模糊指令、异常输入面前还能稳定输出一个可用的结果。这篇文章我想把整套从头搭建AI工程能力的路径拆开揉碎讲一讲我是怎么一步步把散装脚本变成有条理的系统以及过程中踩过哪些坑、哪些决策最后被证明是值得的。如果你正准备在自己的项目里引入AI能力或者已经开始写了一些调用模型的胶水代码但总觉得不踏实这篇文章应该能给你一套可以直接上手的坐标。我尽量不堆术语但该给的代码、参数和步骤一样不少你照着走就能少走几周弯路。1. AI工程不等于调包先分清层级再动手1.1 AI工程与算法研究的边界我在团队里见过不止一次这样的情况一个后端工程师拿到了大模型API的访问权限第一个想法就是“我prompt写得好一点是不是就能让模型帮我干活了”。prompt本身当然重要但它只属于AI工程里很靠上的一个层级。真实的AI工程体系从上到下大致分这么几层模型层选什么模型、用API还是私有化部署推理层输出解析、结构化生成、函数调用、并发控制数据层知识库切片、向量化、检索、样本回流评测层离线指标、线上回归、badcase分析应用层业务逻辑、状态机、兜底策略、权限控制如果你把所有精力都花在“模型层”和“prompt写得更花哨”上后面的工程化内容就全是空中楼阁。模型输出一旦不稳定应用层就不可控这是很多AI项目从demo走向生产时突然崩溃的根本原因。所以我的第一个建议是动手之前先画一张你的系统分层图从底层往上列清楚每一层各自要解决什么问题各层的输入输出接口是什么。这张图就是整个项目的骨架。1.2 从零开始的一套可复制路线图我经历过几个从零到上线的AI项目之后总结出一个比较通用的推进顺序分享出来供你参考先定评估标准没有eval就谈不上优化这一步不做后面全白搭搭最小数据管线拿到真实样本、清洗、切分形成初始的评估集做基线实验用最简单的RAG加一个通用模型跑通整条链路优化单点效果针对badcase逐个分析决定是改检索还是改prompt工程化加固加入缓存、限流、重试、降级、监控、日志上线与回流设计线上反馈机制把真实用户行为转成下一轮评估集每一次迭代都围绕“评估集上的分数变好”来进行而不是凭感觉“我觉得这个prompt更顺了”。AI工程必须靠指标说话这是我跟纯研究背景的朋友合作时反复强调的一点。1.3 第一个项目该选什么我不太建议你一上来就做一个“全功能AI助手”之类的宏大项目。第一个AI工程项目的理想选择应该满足三个条件单点场景、边界清晰、有可对比的基准。比如内容审核、摘要生成、客服意图识别都比“做一个AI能帮我管所有事”要合适得多。我当时第一个跑通的项目是给内部知识库做问答助手。看似简单但涉及文档解析、表格处理、召回策略、引用溯源、多轮对话几乎把AI工程的核心模块都覆盖了一遍。也正是因为在这样一个场景里把流程磨顺了后面再做其他项目的时候我只需要替换数据源和评估标准骨架是可以复用的。2. 先把数据问题弄干净才有资格聊模型2.1 创建评估集这是整个项目的定海神针很多人觉得评估集是“最后上线前才做的”这个顺序完全反了。AI工程的现实是没有评估集你根本不知道怎么改prompt是有效的也不知道换一个向量模型到底带来了多少提升。评估集不需要一开始就很庞大。我建议从100条真实业务样本起步覆盖正常场景、边缘场景和错误输入。重点不是数量而是覆盖度。哪怕最初只有50条也要确保每一条都代表一类你预判可能出现的情况。数据来源通常有三条路历史工单、人工标注、线上日志。其中线上日志是最有价值的因为你设定的“正常情况”往往跟用户的真实提问方式有很大偏差。用户不会按照你设计的prompt里的格式来提问他们可能错字连篇、没头没尾、口语化严重。所以我会在项目第一天就把日志采集代码埋好哪怕前端页面还没做完后端接口也要把request和response记下来。2.2 标注和指标定义要提前定好评估集里的每一条样本都需要一个“参考答案”。为了保证答案质量建议前期由领域经验最丰富的人亲自标注而不是甩给外包或实习生。因为标注的过程本质上就是在定义“什么是一个好回答”这个标准会直接影响模型优化的方向。指标定义上我的习惯分两类来设计客观指标答案是否包含指定实体、是否匹配正确格式、检索结果中Top10是否包含正确答案主观指标内容是否准确、是否完整、是否友好主观指标用评分制1到5分。实际操作时找两三个人一起打分分歧大的样本正好可以用来发现标准模糊的地方。打分流程尽量固定避免同样的答案今天7分明天8分。我在团队里会建一个简单的评分规范文档里面包含“什么情况扣分”“什么情况判零分”的示例评分时对照执行。3. 核心实现Prompt的工程化3.1 从最容易翻车的场景开始设计Prompt工程不是“写个开场白、列出要求、给个例子”这么简单。真正有效的做法是先收集10个最典型的badcase然后反推prompt应该怎么约束。举一个我实际处理过的例子。某次需求是让模型从用户留言里提取“订单编号”和“退款原因”。我第一版prompt写得很泛结果模型经常把“订单编号”从正文里挑错位置或者把“不想等了”这种情绪表达也当成退款原因。后来我把badcase摊开来看发现问题是“没有告诉模型什么叫合法格式”。于是我在prompt里明确了几条硬规则订单编号必须是类似ORD-开头的12位字符串否则回答“未找到订单编号”退款原因必须是从原文摘录的短句不能自行总结。加了这两条之后提取准确率直接从78%跳到了92%。这就是prompt工程的核心方法论不要试图用一段话覆盖所有情况而是用有限的结构化规则把最容易出错的部分卡死。3.2 结构化输出别再靠人眼从文本里抠内容了另一个关键点从模型返回的文本里用正则去匹配JSON这是极其脆弱的做法。大模型经常会在输出里加入多余的说明性文字或者把JSON格式写得不够严整。正确的做法是利用结构化输出能力比如JSON Mode或Function Calling把输出直接约束成对象。我用一个简单的Python示例说明from pydantic import BaseModel, Field class RefundInfo(BaseModel): order_id: str Field(description订单编号如 ORD-20240101-0001) reason: str Field(description退款原因从原文摘录) confidence: float Field(description提取置信度0到1之间) # 调用模型时强制输出为JSON schema response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: 用户说ORD-20240101-0001 这个订单我不想要了因为发货太慢}], response_format{type: json_object, schema: RefundInfo.model_json_schema()} )这条路走通之后下游代码就不需要再解析文本了直接把返回值映射到数据模型里。更重要的是模型“跑飞”的概率会小很多因为它在生成之前就知道自己要输出一个合规的JSON。实测下来这类结构化输出方案能把后处理逻辑的错误率降低一个数量级。3.3 把Prompt变成代码版本的一部分Prompt不是一次性的文案它会随业务调整而频繁变化。因此我建议从第一天开始就把prompt视为代码的一部分纳入版本管理。具体做法是在项目里建一个prompts/目录每个场景一个文件用模板引擎渲染变量。配合标准化工具可以做自动化回归每次prompt改动都能在eval集上跑一遍分数防止“改好了A砸坏了B”。这里有一个值得注意的细节prompt里不要写死版本号或日期因为模型本身也在更新版本号没有任何约束力。更重要的是在prompt旁边写change note记录“为什么改”和“测试时用的模型版本”这对后续排查线上问题极有帮助。4. 检索增强生成RAG比你想的更费心4.1 RAG的流程拆解从文档到可检索的知识块RAGRetrieval-Augmented Generation检索增强生成是当前AI工程里最实用的技术栈原因很简单你没法让模型记住你们公司的内部资料但检索可以让模型在回答问题时“临时翻书”。我搭建RAG的第一个版本非常简陋把几十个PDF转成文本直接丢进向量库用户提问后找出最相似的3段文本塞给模型。结果效果极差模型经常引用不相关的内容来回答。后来我逐步拆解才发现问题出在“文档切分”上。切分是RAG乃至整个检索工程里最容易被低估的环节。好的切分不是简单按字数分段而是按语义边界切。比如一篇PDF里包含多个章节、多个表格、多个并列条目如果你一刀切成定长块同一块里往往混入了多个话题检索出来自然不精确。我推荐使用“结构感知的切分”策略也就是说要考虑文档本身的格式信息标题层级、段落边界、表格行数、列表项。以下是一个示例思路from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap64, separators[\n\n, \n, 。, , , , ], ) chunks text_splitter.split_documents(documents)这里chunk_size512和chunk_overlap64是经验值我试过很多组合后发现不同文档类型的最优值差异很大。当你处理的文档里大量出现“对仗式条款”比如说明书里一条一条的注意事项时512字一个块往往够用但如果文档是连续的大段论述1024字表现更好。关键不是记住某个固定值而是理解这两个参数的作用chunk_size决定模型一次能看到多少上下文chunk_overlap用于连接上下文的语义缝隙。切片之后我强烈建议你人工抽看20个chunk不要只看数量要看内容是否完整、是否出现话题断层。4.2 向量化与检索参数背后的原理把文本切片之后下一步是向量化。向量模型的选择没有一个“最强”的通用答案主要取决于你的数据语言、领域和噪音水平。我一般会准备两到三个候选模型在同一个检索任务上对比召回率再做选型而不是直接用某个排行榜第一的模型。检索的另一个关键参数是TopK。TopK太小正确答案可能根本进不了候选集TopK太大模型会被无关内容干扰甚至“淹没”在噪声里。我常用的做法是先设TopK10跑一遍评估观察“正确答案是否出现在前5个结果里”根据结果调节。如果前5个结果里没有正确答案不是加大TopK能解决的而是说明检索质量本身有问题这可能涉及切分方式、向量模型或查询改写。4.3 混合检索与重排真实场景的必选项纯向量检索在实际业务中往往不够原因在于向量相似度对专有名词、型号代码等“精确匹配”场景支持不好。比如你搜“型号ABC-123”语义上它可能匹配到“型号456”但用户其实只要“ABC-123”的精确信息。这时候就需要加入关键词检索BM25让精确令牌参与召回。把向量检索和关键词检索的结果合并之后还会出现排序不稳定的问题。我推荐在粗召回之后加一个重排rerank模型对一批候选结果做精细排序。这一步不是必须的但如果你足够重视答案质量它是性价比极高的投入。演示一下思路# 粗召回向量检索 关键词检索合并 candidates vector_hit bm25_hit # 去重 candidates deduplicate(candidates) # 重排用rerank模型精排 reranked reranker.rerank(query, candidates, top_n3)重排序模型比普通向量模型更“费钱”但通常只在候选集上跑量小可控。线上测试里加了重排之后答案命中率通常能提升5到15个百分点具体数值取决于你的数据质量。4.4 RAG响应质量的两条兜底策略RAG并不能保证每一次回答都准确所以要为“模型乱编”的情况设计两道防线第一道是“引用溯源”让模型在给出结论时顺带返回内部资料的引用位置比如“根据XX文档第X节”。这样既方便用户自查也方便你做badcase定位。第二道是“不确定就拒答”在prompt里明确写“如果检索结果不足以支撑回答请直接说知识库中未找到相关信息”。很多人怕模型说“不知道”觉得这样显得产品笨——但实际上一个敢于承认“不知道”的系统比你硬撑着编造出来的答案可靠得多长期看用户信任度是上升的。这两道防线合在一起基本能把RAG最常见的“一本正经胡说八道”问题压到很低的水平。5. 成本、延迟与可观测性跑通和跑好是两回事5.1 大模型调用的账单逻辑只调API可能感知不到成本压力但如果你做的是一个日请求量过万的产品token费用会以非常惊人的速度涨起来。我开始做AI工程时对成本没有体感直到一张账单把我惊醒原来模型“每说一句话”都要花钱。成本控制的一个基本框架是把所有大模型调用拆成token来度量。相比直接看总费用按token记账才能定位到哪个环节在“烧钱”。我通常会维护一张表统计每个功能模块的input token、output token、单次请求成本以及日请求量和总成本。5.2 便宜和快的路线缓存、小模型、批量处理成本优化有几个立竿见影的手段缓存相似请求的结果对用户输入做归一化处理后做向量相似度匹配如果和之前的请求高度相似直接返回历史答案跳过模型调用。这个对“FAQ类问题”的场景效果显著实测可以节省30%以上的调用量。用模型分级不是所有请求都需要最强的大模型。意图分类、关键词提取这类简单任务完全可以用更小型号处理只有主答案生成才调用能力最强的模型。批量处理离线任务尽量用异步批处理避免逐条请求带来的额外开销和延迟波动。延迟方面第一优先级是减少“无效往返”。比如一次问答不需要非得经过“全文检索→重排→两次大模型调用”的串联流程很多情况下一次RAG检索加大模型生成就绰绰有余。把链路中不必要的步骤砍掉是最直接有效的降延迟方案。5.3 可观测性给系统装上记录仪AI系统的可观测性和传统后端系统不太一样。传统后端你关心状态码、耗时、堆栈信息AI系统你还要关心“模型输入是什么、输出是什么、检索命中了什么、用户最终有没有点有帮助”。我会在每个请求的关键节点埋点把请求参数、检索结果、模型输出、延迟、费用都结构化存起来。这个日志系统不只服务于排查问题更是后续评估集迭代的重要数据来源。你有多少badcase可分析决定了下一轮优化能做多快。这里不要再纠结“用户级联分析”复杂不复杂先做起来哪怕是JSONL落盘也比什么都没有强。6. 评估、回归与持续迭代6.1 搭一个能自动跑的评测流程评估集搭好之后手动评测当然可以但效率太低尤其是每次微调都要从头看一遍错漏难免。我建议把评测流程脚本化至少做到“输入一批case自动跑完输出一份分数对比表”。我的做法是写一个evaluate.py读入一个JSONL的eval集对每一条case调用线上系统的核心接口然后根据参考答案计算客观指标再用大模型打分器LLM-as-a-judge对答案质量做主观评分。打分器本身也需要校准我会手工复核10%到20%的case确保打分器和人类判断基本一致。这个流程跑起来之后“改prompt”就再也不用来回仰仗人工抽检每次提交一个prompt版本自动跑一遍评测分数有没有掉一目了然。6.2 建立“线上反馈→新评测样本”的闭环评估集不能是死的它是系统进步的养料。线上用户的每一个反馈点赞、点踩、澄清追问、直接关闭都在泄露当前系统的短板。我建议设计一个流式管道每天把线上badcase自动汇聚到待标注队列隔几天人工筛选一次把高质量的badcase沉淀到评估集里。这个关键词“沉淀”有个隐含动作不只是把badcase塞进评估集还要判断这个badcase代表的是“数据缺失”“检索失败”“prompt歧义”还是“模型能力不足”。分类之后再决定下一步的优化动作。6.3 上线前要跑的通关清单上线之前我总是会过一遍自己的通关清单你可以直接抄走评估集是否包含50条以上的真实badcase是否跑过至少两个baseline模型并记录过分数是否对prompt版本做了diff和对失效风险的评估是否设计了拒答兜底和引用溯源是否存在单点依赖模型服务挂了系统要不要降级是否埋了响应日志和token费用日志是否有可利用用户反馈回流迭代的机制这份清单每次都帮我挡住至少一两个“上线后才发现”的问题。7. 常见问题与排查技巧实录7.1 高频问题排查速查表我在多个AI工程项目的推进过程中整理了一份高频问题速查表建议收藏备用问题可能原因排查方法解决办法模型回答经常“跑题”检索命中的内容与问题不相关打印检索引文逐条核对Top5与query的语义相关性调整切分粒度、换向量模型、增加重排输出解析偶尔失败模型输出了非结构化文本查看解析错误日志确认模型输出是否混入多余文本启用结构化输出增大重试频次用户投诉“答案变差了”模型版本更新导致行为变化对比历史日志和当下输出锁定模型版本或把prompt改得更显式延迟飙升链路过长或模型排队查看各环节耗时分布砍掉多余环节引入异步批处理成本快速增长请求被高频重复调用统计同一问题的命中次数加语义缓存、做结果复用RAG检索不到答案文档切分把关键信息截断抽查chunk内容检查关键信息是否单块独立修改separators调整chunk_size7.2 多次实战中最重要的三条心得第一不要过度prompt。我见过把prompt写到几千字、塞满各种例子的做法结果模型反而在琐碎约束里迷路了。prompt应该“够用就好”别把整个领域的规则都往里头塞。与其在prompt里堆砌边界情况不如把边界情况做成前置的规则和校验逻辑。第二模型输出一定要前置校验。不要相信模型给出的JSON字段都合法一定要在拿到输出后立刻做运行时校验。用pydantic加output parser是性价比最高的方式它会在字段缺失或类型错误时直接抛异常而不是把一个“坏数据”送到下游逻辑导致各种诡异问题。第三上线前务必备好“无模型降级模式”。当外部服务不稳定或费用超过阈值时系统可以降级为纯规则、纯检索模式。用户体验可能变差但总比整个服务不可用要好。这个兜底看起来不起眼但真出了问题时它就是救命的。7.3 新人常犯的低级错误最后提醒几个我见过无数次的低级错误它们造成的损失往往比技术难点更大用id号作为向量化的内容单元比如文本中有“用户ID123456”向量化之后相似度就被这些随机数字干扰了。分块时不保留上下文信息一个单独的Chunk没有所属文档的标题、章节号检索和阅读都失去上下文。没有对随机性做控制很多人忘了设置temperature0模型每次回答都不一样评测结果也悬在半空中。只测正常案例评测集里全部是“标准问法”一个脏输入或恶意输入都没有系统上线必然翻车。8. 从零到一之后留给未来的路AI工程从零到一的路其实没有太多玄学。把数据弄干净、把评估立起来、把链路拆开看、把兜底做扎实这四个动作做完你已经跑赢了绝大多数这波热潮里只会在demo上“哇塞”的人。我自己的体会是AI工程一半是跟模型对话另一半是跟自己系统里的各种意外对话——而这另一半往往才真正决定一个项目能走多远。如果你正在经历从零搭建的阶段不要急着跟风做各种大而全的功能先把最小闭环跑起来一个评估集、一条检索链路、一个稳定的生成接口。在这个闭环上不断迭代你会发现所谓“AI能力”背后真正可积累的其实是一套有反馈、有度量、有兜底的工程系统。最后分享一个小技巧把你每次改动prompt或检索策略前后的评测分数变化记到一个固定的地方几个月后回看你会清楚地看到自己是怎么一步步把准确率从70%磨到90%以上的。这种记录比任何所谓的“AI工程标准流程”都更有说服力也是你在这个领域最值钱的经验沉淀。