从零搭建AI工程系统：模型选型、RAG、Agent与评测实战

1. 从零开始做AI工程到底在做什么先说结论ai-engineering-from-scratch不是教你调一个API、写一段Prompt也不等于用Python调库跑通一个模型。它是一门关于怎么把AI能力稳定地放进真实业务系统里的工程学科。如果你已经在用AI辅助写代码、写文案、做表格那只是使用AI。真正做AI工程是把自己变成那个造工具的人——你要设计Prompt体系、搭Agent流程、接模型服务、做效果评测、管控成本与错误率最后让一套AI系统在无人值守的情况下持续输出合格结果。这个过程的完整链条才是AI工程。我见过太多人卡在某一环有人写Prompt写得很好一上生产就崩有人模型调得飞起业务方一句结果不可控就全部推翻还有人天天刷模型榜单却不知道自己的场景真正需要什么。AI工程化最核心的一件事是把模型能力翻译成业务确定性。模型本身有随机性工程的职责就是通过提示词设计、上下文控制、流程编排、评测兜底把这种随机性压制到业务可接受的范围内。这篇文章适合三类人想从普通用户进阶到AI应用开发者的技术人正在做企业内部AI落地但找不到方法论的工程师以及想系统学习AI工程却不知道从哪下手的自学者。我们不讲花哨的模型原理只讲一条从零到能交付的务实路径。2. 从零搭建AI工程的完整设计思路2.1 先拆解一条完整的AI工程链路我把AI工程化的完整链路拆成了七个环节任何一个项目你都可以套这个框架业务定义明确这个AI要解决什么问题输入是什么输出是什么失败的代价有多大。模型选型根据效果要求、成本预算、响应时延、数据隐私约束确定用哪一类模型。上下文工程决定让模型看到什么信息包括系统提示词、知识库内容、历史对话记录。提示词工程把业务规则翻译成模型能稳定遵循的指令体系。Agent编排复杂任务拆解成多步调用让模型学会用工具、查资料、做判断。评测与监控用测试集量化效果上线后持续追踪表现。迭代闭环根据评测结果和线上数据循环优化Prompt、上下文和流程。这个链路最容易被忽视的是第一环和最后一环。很多团队一上来就扎进Prompt调试里结果业务方根本说不清合格是什么标准后面全白做。我强烈建议任何AI工程项目的第一个交付物不是代码而是一份效果验收表——哪怕刚开始很粗糙也要把什么算好、什么算坏白纸黑字定下来。2.2 为什么不能只靠调Prompt解决工程问题大家都有一个直觉模型效果不行就调Prompt。这是对的但远远不够。我见过一个典型案例一个客服机器人Prompt写得已经很精细了结果一上线发现用户的问题有一半跟预设场景无关模型开始胡编。问题根本不在Prompt而在上游——没有做意图识别和路由所有问题都丢给同一个Prompt处理。工程化的思维是用系统设计来兜底模型的不确定性而不是指望模型自己变稳定。具体来说有三个手段分流先判断问题类型不同类别走不同Prompt流程而不是一个万能Prompt硬扛。兜底模型置信度低的时候不硬答而是给出我不确定请转人工之类安全回复。校验模型输出之后加一层程序化校验比如格式检查、范围校验、关键词过滤不合格就重试或拒绝。这三个手段搭配Prompt优化效果上限远高于单纯调词。Prompt解决的是模型理解力问题工程解决的是系统控制力问题两条腿走路才稳。2.3 以文档问答Agent为例的工程目标拆解拿最常见的文档问答场景来说。假设你要做一个企业内部知识库问答系统让员工用自然语言问HR政策、IT规范、报销流程。这个任务看起来简单实际做起来坑很多。先拆业务目标用户输入问题系统返回答案同时标注答案出处。合格标准是什么第一答案准确率要达标特别是政策类问题不能答错第二回答必须基于给定的知识库不能胡编第三找不到答案时要明确说不知道而不是编一个。技术方案上你需要四个模块文档解析把PDF、Word变成可检索的文本块、召回根据问题找到相关文档片段、生成把片段组织成答案、校验检查答案是否与原文一致。这就是一个完整的RAG应用。很多人以为RAG就是embedding加向量库再加LLM实际工程里文档怎么切分、检索怎么排序、答案怎么约束每个环节都有大量细节后面我会逐个讲。3. AI工程六大核心技术点详解3.1 模型选型别只盯着榜单先算这笔账选模型是AI工程的第一步也是最容易犯错的环节。技术圈有个通病谁分数高就用谁完全不考虑成本结构。我建议你从四个维度打分效果在你自己的评测集上跑分而不是盲信公开榜单。公开榜单的测试集跟你的业务差距可能非常大。成本包括Token费用、调用延迟、并发上限。一个答案如果生成要10秒那它再好也接不进客服系统。隐私数据能不能出域涉密信息能不能走公有API很多企业卡在这条直接选了私有化部署。生态模型厂商的工具链、SDK、社区成熟度决定了你踩坑时能不能快速找到答案。有一个容易被忽略的参数叫推理性价比。举例来说A模型输出质量90分每千Token成本1元B模型质量85分成本0.1元。如果你的业务对效果不那么敏感B模型的综合ROI可能远高于A。我实际做过一个关键词抽取项目用大模型一个月成本好几千换成中等模型把准确率放宽5个百分点成本直接降了一个量级。先算钱再谈效果。3.2 上下文工程给模型喂什么比模型本身更重要上下文工程的核心问题是模型一次能处理的Token有限而业务知识无限怎么选、怎么放、怎么避免信息打架。先讲结构。一次完整的大模型调用上下文包括四个部分系统指令定义角色和规则、对话历史多轮上下文、检索结果外部知识、用户问题。我见过大量的失败案例是把一堆内容不加区分地塞进去模型根本分不清哪些是规则哪些是背景资料。结果是规则被忽略资料被当成指令执行。再讲筛选。文档问答场景里知识库可能有几万个文档块一次只能挑最相关的十来个。所以你要有一个好的检索策略——先用关键词或向量相似度召回候选再用重排序模型精挑。这里我强烈建议引入rerank环节只用向量召回Top5里经常混进两三个不相关的Rerank能显著提升命中率。实际效果上一个700M的Rerank模型经常能把检索准确率从70%拉到90%以上。最后讲对抗。模型有个毛病上下文越长越容易被无关信息干扰。解决方案是控制单轮检索数量宁可少给不要多给。我给过一个通用经验一次送入模型的相关文档块控制在3到5个多了容易注意力稀释。3.3 提示词工程从写人话到写机器能稳定执行的规则很多人觉得Prompt Engineering就是把需求写清楚。这话对了一半。真正的Prompt工程是把人的表达习惯翻译成模型执行逻辑还得经得起批量测试。我总结了三个核心技巧。第一用结构化输出约束格式。告诉模型请输出JSON格式包含字段answer、source、confidence远远比请简明扼要地回答可靠。配合模型自带的JSON模式可以把输出解析错误率降到接近零。下面是我常用的一种模板你是公司政策助手。请基于给定的资料回答问题。 要求 1. 如果资料中有答案直接回答并给出引用来源编号。 2. 如果资料中找不到答案输出未找到相关信息。 3. 输出格式严格为JSON { answer: 你的回答, source: [来源1, 来源2], confidence: high | medium | low } 资料如下 {context} 用户问题{question}这段模板的核心价值不在文采而在边界清晰。模型是概率生成器你给它的路越窄它跑偏的概率越低。第二用Few-shot示例代替抽象描述。你写十句要准确、要简洁不如给模型两个标准样例。比如你想让模型改写文章风格直接给输入-输出对照模型理解速度比读规则快得多。第三职责分离。如果一个系统要处理多类任务不要写一个大而全的Prompt而是做一个路由Prompt先判断类型然后每类任务各用一个专用Prompt。我见过很多团队为一个任务写了500字通用Prompt导致模型什么都干不好。单一职责的Prompt每个都不长但都极其精准。3.4 Agent编排让模型动手干活的关键技术Agent是这两年AI工程最火的方向但很多人对它理解错了。Agent不是让模型自己做事而是一个由模型做决策、由代码做执行的系统。核心设计模式有三种ReAct模式模型生成Thought思考、Action调用工具、Observation观察结果循环直到任务完成。Plan-and-Execute模式先让模型拆解计划再按计划逐步执行每一步可以调用不同工具。多Agent协作模式多个角色分工比如一个负责拆解问题一个负责检索一个负责审核。以自动生成项目周报为例。一个单次调用的做法是把一堆工作记录丢给模型让它写周报——效果一般因为信息量太大模型处理不过来。用Agent的做法是先调用项目数据查询工具拉取本周的工作项再调用分类工具把工作项按类型归类最后才让写作文模型生成周报再由审核模型检查有没有遗漏。每一步都在做信息减熵最终结果质量远高于一把梭。做Agent工程最重要的是工具设计。工具就是模型的手脚参数定义越清晰模型调用越准确。比如你给模型一个查询函数def search_documents(query: str, top_k: int 5) - list[dict]: 根据关键词搜索知识库返回最相关的文档片段。 Args: query: 搜索关键词或自然语句 top_k: 返回结果数量默认5 # 实现向量检索 ...注意工具描述写得越详细模型就知道什么时候用、怎么用。我见过一个项目工具描述写得模糊模型把查询天气功能用来查用户订单驴唇不对马嘴。每一个工具都要回答三个问题它是干嘛的、什么时候用、输入参数是什么格式。3.5 评测体系没有评测就没有优化评测是AI工程里最容易被偷懒的部分但恰恰是它决定了项目能不能持续迭代。没有评测你改Prompt就是盲人摸象——改好了不知道哪里好改坏了也不知道哪里坏。一个最小可用的评测体系需要三件东西测试集收集50到100条典型问题覆盖正常场景、边界场景、错误输入。注意测试集必须来自真实用户数据不能自己凭空编否则评测结果与线上表现严重脱节。评测指标按任务类型选。问答类看答案准确率、召回率、幻觉率生成类看相关性、格式正确率Agent类看任务完成率、工具调用正确率。最好能让业务方参与打分否则技术指标再高业务不认也白搭。回归机制每次改Prompt或改流程后都跑一遍测试集对比前后得分。保存历史版本效果下降就回滚。我自己的习惯是维护一个效果基线表。每次上线前跑一遍基线测试集把各项指标记录成表格。改完Prompt再跑一遍对比差异。这个习惯让我省了无数无用功。举个例子有次我改了一个Prompt让回答更详细结果准确率下降了8%靠回归测试秒级发现赶紧回滚挽救了线上服务。3.6 工具链与代码实践手把手搭一个最小AI工程我把整个最小工程讲透。技术栈用Python核心组件是LangChain或纯手写流程模型接口用OpenAI兼容格式向量库用轻量级的Chroma。第一步搭项目结构。ai-engineering-from-scratch/ ├── app/ │ ├── __init__.py │ ├── router.py # 意图路由 │ ├── prompts.py # 所有Prompt模板 │ ├── retriever.py # 检索模块 │ ├── agent.py # Agent编排 │ └── validator.py # 输出校验 ├── data/ │ └── documents/ # 知识库原始文档 ├── tests/ │ ├── testset.json # 评测测试集 │ └── evaluate.py # 评测脚本 └── main.py # 服务入口第二步实现一个最小检索模块。重点在文档切分——不要按固定字数硬切而是按标题、段落结构切这样语义更完整。切分后做向量化存入向量库查询时先取Top20候选再用Rerank模型精排到Top5。第三步实现带校验的生成流程。模型输出后先用JSON解析器解析解析失败就重试一次再用validator检查answer里面有没有包含source里没有的内容如果有判定为幻觉重新生成。这一步是AI工程区别于调API的关键差别。response model.generate(prompt, json_modeTrue) try: result json.loads(response) except json.JSONDecodeError: # 解析失败重试 result model.generate(prompt, json_modeTrue, retry_count2) if not validator.is_answer_grounded_in_sources(result): result[answer] 未找到足够可靠的信息请转人工处理。第四步写评测脚本。加载测试集逐条调用系统把结果和期望答案对比输出准确率和失败样例。这个脚本要能一键运行否则团队根本不会坚持评测。4. 实操过程全记录从0到1构建一个客服问答Agent4.1 环境准备与基础配置先说环境。Python用3.10以上版本安装openai、chromadb、langchain-core几个核心库。如果你本地有OpenAI兼容的模型服务直接用没有的话用国产开源模型跑本地部署也行接口是一样的。这一步最关键的是把模型层抽象成统一接口后面换模型不影响业务代码。pip install openai chromadb langchain-core pandas接着准备一个配置文件把模型参数集中管理MODEL_CONFIG { primary_model: gpt-4o-mini, # 主模型负责生成 router_model: gpt-4o-mini, # 路由模型负责分类 rerank_model: BAAI/bge-reranker-base, # 重排序模型 embedding_model: BAAI/bge-large-zh, # 向量化模型 temperature: 0.1, # 生成温度问答场景尽量低 max_tokens: 2048, }这里有个经验值问答类任务temperature设0.1以下需要创造性任务可以到0.7但别超过1.0超过就失控了。路由模型的temperature设0保证分类稳定。4.2 数据准备从原始文档到可检索的索引数据准备占AI工程一半的功夫我这里详细展开。原始文档可能是PDF、Word、Excel、网页先统一转成纯文本。注意PDF里经常有表格、页眉页脚、多栏排版转换时容易乱。清洗之后做切分。我的经验是按层级结构切分先用一级标题切大块再把超过500字的块按二级标题或段落切小块。每块控制在200到500字之间。为什么是这个范围太短了语义不完整太长了一个块里塞了多个主题检索时容易命中混乱。有个技巧切分时保留标题上下文比如把第二章 报销流程作为前缀拼接在每个块开头这样检索命中的时候模型能知道这段内容的归属。切分完成之后做向量化。向量化就是用模型把文本转成一组数字让语义相近的文本数字也相近。选Embedding模型时注意中文场景要选支持中文的比如BGE系列。然后存入向量库入库时顺便把原文、来源路径、标题元数据一起存进去方便后续溯源。text_chunks split_document_by_structure(doc_text) # 结构切分 for chunk in text_chunks: vector embedding_model.encode(chunk.text) collection.add( ids[chunk.id], embeddings[vector.tolist()], documents[chunk.text], metadatas[{source: chunk.source, title: chunk.title}] )我第一次做这个环节时踩过一个坑把所有PDF一股脑切完入库结果检索时经常命中书里的目录部分答案驴唇不对马嘴。后来在预处理阶段先做了一次去噪把目录、页眉、空白页全部过滤掉效果才正常。预处理是脏活但偷不得懒。4.3 Prompt体系设计路由、生成、校验三层分离我设计的Prompt体系分三层每层职责单一。第一层是路由Prompt。它只做一件事判断用户问题属于什么类型。比如客服系统里问题类型分为政策咨询技术故障投诉建议闲聊无关问题五类。路由Prompt用文本分类的方式写你是问题分类器。判断用户的提问属于哪个类别只输出类别名称。 类别政策咨询、技术故障、投诉建议、闲聊、无关问题 用户输入{query} 分类结果这一步不需要大模型很强的推理能力关键是快和稳。我实测这种单标签分类用小型模型就够而且配合logit_bias强制只输出预定义词表可以做到100%格式正确。第二层是生成Prompt。每个场景单独一个绝不混用。政策咨询的Prompt强调严格按公司制度回答注明政策编号技术故障的Prompt强调先问清楚现象再给排查步骤。为什么要分开因为不同任务的指令重心完全不同混在一个Prompt里模型会淡化次要指令。第三层是校验Prompt。核心是检查模型回答是否忠于来源。我之前让它判断回答中的关键信息是否都能在给定资料中找到依据用另一个模型打分。这层非常有用但会额外增加Token消耗所以只在低置信度场景触发——先用规则粗筛规则判不出再用模型复核。4.4 Agent调用链与关键代码实现整个Agent的调用链是用户输入 - 路由分类 - 按类别执行 - 检索 - 生成 - 校验 - 返回。核心代码结构如下def handle_query(user_query: str) - dict: # 第一步路由 category route(user_query) # 第二步根据类别生成检索query search_query preprocess_query(user_query, category) # 第三步检索重排序 candidates retrieve(search_query, top_k20) top_results rerank(queryuser_query, docscandidates, top_k5) # 第四步组装Prompt并生成 prompt build_generation_prompt(category, top_results, user_query) result generate(prompt) # 第五步输出校验 if not validator.check(result, top_results): result fallback_response() return result这个链路的巧妙之处在于每个模块都极简但组合起来很稳。路由模块只有30行代码检索模块只有50行生成模块是一个Prompt调用校验模块是一组规则加一次模型调用。但每个模块各自做好自己的事整体效果就能稳定地跑。有一个细节检索query的预处理。直接用用户原始问题去检索经常因为口语化表述导致召回不准确。我加了一步query改写让模型把口语问题改写成一个标准的检索语句。比如用户问我昨天提交的报销怎么还没到账改写为报销到账时间 流程 查询检索命中率显著提升。4.5 效果评测与上线监控项目写完之后我建了一个50条左右的测试集覆盖各种问题类型。评测脚本输出一张表格包含每一条问题的命中情况、回答内容、是否成功、失败原因。我第一次跑的时候准确率只有62%大量问题集中在技术故障类目上——原因是知识库里技术文档的格式太乱检索经常抓到没头没尾的片段。后来专门优化了技术文档的预处理逻辑准确率拉到88%。上线之后监控比评测更重要。我在服务里埋了两个日志点每个请求的输入、输出、检索结果、路由分类、耗时、Token消耗。每天跑一个脚本统计当天的成功率、平均耗时、失败样例Top10。真正的AI工程项目优化素材来源不是模型榜单而是这批每日线上日志。我特别建议做**预测失败监控**。给系统加一个置信度评分如果模型输出时confidence字段为low或者校验失败重试了两次就标记为疑似失败。这类请求人工抽检可以用极小成本发现系统性问题。5. AI工程实战高频问题与排查实录5.1 输出总是乱来从三个方向排查模型输出不受控制是新手遇到最多的问题。不要急着加攻击性词语按顺序排查看Prompt结构。是不是把规则、背景、示例全混在一起了把必须做什么和参考什么分开写。看格式约束。如果要求输出JSON用JSON Mode或者最后加一句只输出JSON不要任何解释。很多模型默认话痨你必须在Prompt里把闭嘴也写清楚。看温度参数。如果输出五花八门temperature降到0如果任务需要确定性甚至可以用贪婪解码。有一个排查技巧把同样的Prompt发到不同的模型上看是否都乱。如果只有特定模型乱说明这个Prompt风格与该模型不匹配如果全军覆没那问题一定在你的Prompt设计上。5.2 检索不到相关内容不是模型问题是前面没做好文档问答系统最头疼的一句话是它根本搜不到答案。这个问题90%出在数据预处理上而不是模型上。我总结三个最常见原因第一文档没有切好。有些PDF转出来的文本是乱序的特别是双栏排版的论文切割后语义完全断裂。你先肉眼看一下切割后的文本乱就先用布局还原工具修一遍。第二Query和文档的语言风格不一致。用户的问法口语化文档是书面语直接向量匹配容易失配。先用Query改写模块把口语转书面语再检索。第三Embedding模型选得不对。很多场景里通用Embedding模型表现很差比如专业领域术语、古文、代码。可以试试领域微调的Embedding模型或者改用稀疏检索BM25与向量检索的混合方案很多场景混合检索能打全域。5.3 幻觉问题模型一本正经地胡说八道幻觉是生成式AI绕不过去的坎。我的处理策略分三层事前防、事中控、事后查。事前防Prompt强制要求只能依据提供的资料回答超出资料范围请回答不知道同时给足参考资料。事中控检索环节保证资料与问题相关不给模型胡编的空间生成时降低temperature输出时限制长度减少发散空间。事后查用校验系统检查回答与资料来源的一致性。最简单的方法是引用校验——要求模型输出答案时必须标注使用了哪几条资料然后程序检查这些资料是否真的存在于检索结果中。更严格的做法是用另一个模型对回答是否有事实依据打分。有人问这能100%消灭幻觉吗不能。但三层防护能把幻觉率从每三四条就一次压到几十条一次在绝大多数业务场景已经可用。追求100%无幻觉目前阶段没有模型做得到工程能做的是让它可控、可发现、可兜底。5.4 成本控制Token烧得太快了怎么办AI工程的成本大头是Token调用。一个失败的设计往往是每个请求都塞一大堆历史记录和参考资料结果大部分Token都浪费在无效信息上。我的省钱策略缓存。完全相同的用户问题直接命中缓存不调模型。客服场景里用户问题重复率高这个优化能降30%以上的调用量。压缩上下文。多轮对话里不要把所有历史都传进去只保留最近三轮和关键摘要。超过时效的历史让模型先做摘要再传摘要。分级调用。简单问题用小模型复杂问题才用大模型。路由模块本身就是天然的成本控制系统。缩短输出。每一步的Prompt都明确简洁回答不超过N字长输出是按Token计费的省输出就是省钱。我现在做一个系统的习惯是上线第一天就接上Token用量仪表盘按天统计每个模块的消耗占比。哪个模块烧钱一眼就看出来针对性优化才有方向。5.5 业务方说效果不可控建立可解释性机制最后分享一个很考验工程师软实力的场景业务方总觉得AI不可靠。问题往往不在AI效果本身而在于系统是个黑盒——出了结果不知道是怎么来的自然不敢信。解决思路是把系统变成可解释的。我的做法是每个回答后面都附上系统决策轨迹——这个问题被路由到了哪个类别、用到了哪几条知识库资料、模型置信度是多少、有没有触发过校验重试。把这条轨迹展示给业务方他们就能自己判断这次回答是靠不靠谱的信任感会大幅提升。这个机制技术上非常便宜无非是把链路中间变量存下来打印出来价值却极高。AI工程不只是技术工作还是一项信任工程。可解释性做好了项目推进阻力小一半。6. 从能跑到好用AI工程落地的最后一公里我做了不少AI项目一个很深的体感是技术原型跑通只完成了30%剩下70%都在打磨确定性。模型能力天花板在那儿但工程质量决定了你有没有触碰到那个天花板。如果你正准备从零做一个AI工程项目我的建议是别急着写代码。先把业务问题量化成一张效果验收表把合格和优秀的标准写清楚再动手。过程中遇到模型不听话、检索不准、效果不稳这些都是正常的按本文的排查思路逐层解决就好。多轮迭代之后你会发现真正让你做出成果的不是某个神奇模型而是这套工程方法论本身。最后分享一个实操习惯每次项目结束我都会把整个流程图、Prompt版本、测试集结果、踩坑记录存成一个项目复盘文档。看起来琐碎但这些积累能让你在下一次项目里至少节省一半的时间。AI技术迭代太快真正的复利来自方法论而不是某个具体的实现。这套从零到一的路径你自己完整走一遍收获会远超你只追最新模型的效果。