1. 项目概述与核心问题1.1 “AI工程”到底是什么这个项目起名“ai-engineering-from-scratch”翻译过来就是从零开始的AI工程实践。先别急着划走这里说的“AI工程”不是让你去复现一篇Transformer论文也不是教你怎么调包跑通一个MNIST手写识别。我理解的AI工程是把大模型从“能跑通”变成“能落地、能维护、能迭代”的那套完整方法包括提示词工程、模型编排、评估测试、数据流转、成本控制这些环节的组合。我跟不少朋友聊过很多人最开始接触AI项目都是从ChatGPT或者各种开源模型平台开始的。跟模型对话、让它写个周报谁都会。但一旦想把模型接入自己的业务流程比如做一个知识库问答机器人或者让Agent自动处理工单问题就来了模型回答不稳定怎么办检索出来的资料不对怎么办上下文窗口不够用怎么办幻觉怎么控制这些问题模型本身不会回答你需要你从工程侧去解决。这个项目的目标就是把我自己走过的弯路、验证过的方案、踩过的坑从头到尾梳理一遍。你如果是有编程基础、但没正经做过AI应用开发的人这篇文章可以当你的第一份实践地图。如果你已经在做AI应用里面的一些排查思路和工程经验应该也能给你一些启发。1.2 传统软件工程思维在大模型面前为什么不好使做传统软件的时候输入是确定的逻辑是确定的输出理论上是可控的。你写一个函数传入参数返回结果行为可预期。但大模型不是这样同一个问题换个说法输出完全可能不同同一个提示词温度调到0.2和0.8出来的风格可能天差地别。这种“不确定性”是很多传统工程师转型做AI时最难受的地方。我刚开始做的时候也习惯性地用传统思路去管理AI应用先定需求再写接口然后联调最后上线。结果发现根本没法这么干。需求定了但提示词怎么算“写对”接口好了但模型的回复没法用单元测试去断言联调完了但换个用户换个问法效果立刻崩盘。问题的根源在于传统软件工程关心的是“有没有做出来”AI工程关心的是“做出来的效果稳不稳、好不好”。这就要求我们把一部分注意力从“编写代码逻辑”转移到“设计模型行为”上来。Prompt不是写一遍就完事需要不断迭代评估不能靠主观感觉需要建立基准集上线不能一劳永逸需要持续观测。这些恰恰是AI工程最核心的命题也是我在这个项目里最想讲清楚的东西。2. 整体思路拆解从“会用模型”到“驾驭模型”2.1 三个阶段的工程化转型路径我把从零开始做AI工程的路分成三个阶段这个分法不一定权威但对入门的人来说会很实用能帮你定位自己现在处在哪个阶段以及下一步该补什么。第一个阶段叫“会用模型”。这个阶段你熟悉了API调用知道怎么发请求、怎么解析返回也了解了一些基础概念比如token、温度、max_length这些参数的含义。说白了你具备了跟模型对话的“语法能力”。这个阶段最容易犯的错误是把模型当成一个无所不能的黑盒所有问题都往里丢然后祈祷输出满意。第二个阶段叫“调教模型”。从这里开始你要系统性地学习提示词工程。你要学会用角色设定约束模型的行为边界用思维链引导模型的推理过程用少样本示例告诉模型你要的输出格式。同时你还要理解为什么同样的提示词换一个模型效果就变了以及怎么针对不同的模型做适配。第三个阶段才是真正的“AI工程化”也就是这个项目的重点。到了这个阶段你要考虑的不只是模型本身而是整套系统的工程架构数据怎么处理、检索怎么做、上下文怎么拼、模型怎么编排、结果怎么评估、异常怎么兜底。在这一层模型只是你系统里的一个组件而组件是可替换的、可监控的、可评估的。2.2 为什么必须建立“评估集”意识讲到工程化第一件要做的事就是建立评估集。很多人做AI应用效果好不好全靠自己“试两句”——觉得回答得不错就觉得行了。这在小规模demo上勉强能应付但一旦应用上线、面临真实的用户流量这种主观判断的可靠性几乎为零。所谓评估集就是一批覆盖典型场景的测试问题每个问题都配有期望的答案倾向或评分标准。比如你做一个法律知识问答机器人评估集里应该包含“试用期被辞退有补偿吗”“公司拖欠工资怎么办”“劳动仲裁的流程是什么样的”这一类真实高频问题。你每次修改提示词、调换检索策略、更换模型版本之后都用同一套评估集去跑一遍对比效果有没有变好或者变坏。我见过太多团队花了大把时间调提示词结果越调越差而不自知。为什么因为他们没有基线没有参照物。有了评估集你就有了“尺子”每一次改动都可量化。这是一切AI工程实践的基石没有这个意识后面的可观测性、回归测试、模型选型对比全部无从谈起。2.3 自研与采买工程框架选型的现实考量做AI工程还有一个绕不开的问题要不要用现成的框架市面上的选择很多有LangChain这类集成度高的框架也有轻量级自己做编排的做法。我的建议是刚开始接触AI工程最好自己手动拼一遍完整链路然后再决定要不要引入框架。手动拼链路是什么意思就是说你从调用模型API开始自己写一个函数接收用户问题把检索的资料和提示词模板拼好发给模型拿回结果再做一些后处理。这一套流程本身不难但完成一遍以后你会对数据在系统里怎么流转有非常清晰的体感。直接上来用框架框架封装得太好出了问题你连排查的方向都找不到这是我见过很多新手朋友最大的困扰。我自己的路径是第一版项目的链路完全手写跑通以后再用框架重构。这样做的好处是当我使用框架的时候心里知道每个封装背后真正发生的是什么而不是盲目调用。3. 核心细节解析与实操要点3.1 Prompt Engineering不是“说清楚话”那么简单关于Prompt Engineering网上教程多如牛毛但大多数只停留在“模板怎么写”的层面。我想从工程化和控制风险的角度拆解几个我实测最有效的要点。第一给模型明确的“边界约束”而不只是“目标描述”。很多新手写的提示词是这样的“你是一个智能助手请回答用户的问题。要求准确、专业、详细。”这句话看似没毛病其实什么都没说。真正可落地的提示词要告诉模型什么能做更要告诉它什么不能做。举个我实际用过的回复——你做客服机器人的时候提示词里不仅要有“你是客服助手”还要写清楚“如果你不确定答案请告诉用户你需要查询后台不要编造信息”。这个“不要编造”的负向约束比任何正向描述都能有效降低幻觉。第二用结构化方式组织提示词。我在实践中发现把提示词拆成“角色定义”“任务描述”“输入数据”“输出格式”“限制条件”五个部分比全堆在一大段话里要稳定得多。格式上的分隔符例如“输入数据”对模型来说就是非常明确的信号指示它该从哪里开始读取哪部分是上下文哪部分是需要响应的内容。第三别忘了给模型“思考空间”。如果你需要模型做复杂推理与其直接让它给结论不如在提示词里加一句“请先逐步分析再给出最终结论”也就是所谓的思维链Chain of Thought。实操中我会说“一步一步思考并把思考过程用简短的方式写在回答里”。这一招对逻辑推理类问题效果提升非常明显。3.2 Harness Engineering给Agent装上缰绳最近圈子里“Harness Engineering”这个概念很火。其实“harness”是马具、挽具的意思用在这里更像是给Agent套上缰绳让你能控制它、引导它、约束它。这个思路在大模型应用里特别重要因为大模型天然不受控你要把它变成能用的产品就需要缰绳。落到实操层面Harness Engineering的核心是“可控性”而可控性主要靠几个手段来实现路由、护栏和上下文管理。路由是把用户请求分发到不同处理链路的机制。比如一个智能客服系统用户问“什么时候发货”应该走订单查询的API而不是直接让大模型编一个发货时间用户问“退货政策是什么”应该走知识库检索从官方文档里找答案。通过路由你把大模型的能力限制在它擅长的领域范围而不是让它回答一切——这本身就是一种很好的可控性。护栏则是定义大模型的“行为边界”。常见的做法包括设置禁区关键词让模型在某些话题上拒绝回答设置输出校验器检查模型输出是否符合格式要求设置降级方案当模型回答置信度不高时自动转接人工。这些措施单独看都很简单但组合起来就是一套完整的护城河架构。上下文管理则要精打细算。大模型的上下文窗口是有限的你不能把用户所有历史消息全都塞进去也不可能把整个知识库都放在每个请求里。所以你要做选择哪些信息进Prompt哪些信息不进每次对话携带多长的历史记录检索出来的文档块怎么排序、怎么截断。这些细节直接决定了模型回答的质量上限。3.3 AI测试开发把模型输出从“玄学”变成“可度量”AI测试跟传统测试最大的区别在于传统测试可以断言YES or NOAI测试只能评估“好不好”“像不像”“跑偏没跑偏”。这是两种完全不同的哲学你得接受它。我在项目里搭了一套三层测试结构。第一层是“单元测试”针对提示词模板和解析函数。输入构造好的用例验证模型返回的JSON能不能被正确解析字段有没有缺失、类型对不对。第二层是“评估测试”跑全量评估集记录每一道题的回答打上质量标签。这里又要区分客观题和主观题客观题比如“这份合同里违约金比例是多少”可以用关键词命中率或者相似度来判定主观题比如“帮我写一份活动策划案”就需要人工看或者用更强的模型来打分。第三层是“回归测试”每次修改提示词或更换模型后跑一遍评估集对比分数有没有下降。这一套测试体系如果把评估基准维护好就是AI应用质量保障的护城河。你换模型厂商的时候可以先用评估集批量跑一遍用数据说话选哪个模型一目了然——而不是看市场宣传。4. 实操过程从零搭建一个知识库问答机器人4.1 技术选型与架构设计空谈理论太虚了接下来我拆解一个实际项目一个企业内部知识库问答机器人。用户问问题机器人从企业文档里找到答案并回答同时附上出处链接。选型上我建议第一版用python写主逻辑。原因是Python生态丰富不管是调用大模型API还是做文本处理都有现成的库。向量数据库用轻量级的FAISS或者如果是正式项目建议上Milvus。这个阶段不要纠结先用自己最顺手的跑通链路再说。架构上整个链路分四层。第一层是入口层接收用户提问第二层是召回层把用户问题和知识库向量做相似度匹配取回最相关的文档片段第三层是生成层把用户问题和召回的片段拼装好发给大模型请求回答第四层是校验层检查模型输出是否合规、是否需要附上引用来源。这四层逻辑清晰、职责单一后续无论替换哪个环节都非常方便。4.2 数据索引文档清洗与向量化知识库问答的第一步是把你的文档处理成模型可以检索的形式。这一步直接决定检索质量但非常容易被忽视。我见过太多人直接把PDF丢进系统检索出来的内容根本没法看。数据处理有几条硬性要求。一是转格式PDF、Word先转成纯文本注意保留章节结构。二是清洗去掉页眉页脚、水印、乱码字符把中文标点统一。三是分块Chunking这是最关键的一步。整篇文章太长丢进向量数据库会模糊语义必须切成合适大小的块。块太大会混入无关内容块太小会丢失上下文。我的经验是中文文档平均每块300到500字比较稳妥但具体要看文档的语言风格和主题结构你可以多试几组参数对比实际检索效果后再定。清洗完成后每一块文本用Embedding模型转成向量连同原文和来源信息一起存入向量数据库。Embedding模型的选择也会影响效果如果你主要处理中文内容建议选择针对中文做过优化的模型比如BAAI/bge系列。切记上线前把所有文档向量化并落库后再让用户提问。4.3 检索策略相似度之外的细节从向量数据库召回相关内容听起来很简单最相似的取前几个就行实操里玩法很多。问题核心在于单纯用向量相似度往往会召回一些“字面相似但语义不对”的片段。我建议第一版可以额外加一层“重排Rerank”机制。先用少量向量检索召回top20的候选片段再用一个专门的排序模型对候选片段和用户问题的相关性逐一打分取最高的top3到top5。重排模型计算量比较大但这一步效果提升非常显著几乎是我做过AI问答项目里“性价比最高”的优化。另一个细节是混合检索。如果你的知识库里有大量专有名词、产品型号、编号之类的文本仅靠向量检索很容易漏。我建议在向量检索之外并行跑一个基于关键词的BM25检索然后把两个结果合并去重。这就像既用语义理解找朋友又用通讯录直接搜名字两手都有覆盖更全。4.4 上下文拼装与模型调优检索到的文档片段不能原样一股脑塞给模型。你需要先做一个“去噪”的动作去掉重复片段、去掉明显跟问题无关的片段然后按相关性排序拼装成上下文。拼装的时候要给清晰的起始和结束标记。我常用的模板是system_prompt 你是企业知识库的智能助手。请根据【参考资料】中的内容回答用户问题。 要求 1. 回答内容仅基于【参考资料】不要使用你自己的常识进行补充。 2. 如果参考资料中没有明确答案请回复“资料库中暂无相关信息”。 3. 回答时请标注引用来源编号格式如[1]。 【参考资料】 {context} 这个模板看起来简单但包含了三个关键的控制点限定信息源、定义兜底策略、要求引用来源。其中“不要使用你自己的常识进行补充”这句话是抑制模型“自由发挥”的关键。你不加这句话模型很容易在文档内容不足时通过“联想”来补充答案从而产生幻觉。模型参数方面知识库问答的应用场景建议把temperature调低一点我一般在0.1到0.2之间降低随机性提高答案稳定度。Top_p保持默认或者配合调低一些能让输出更聚焦。5. 常见问题与排查技巧实录5.1 高频问题速查表做这类项目时间长了遇到的问题翻来覆去其实就那几类。我把它们汇总成了一张表方便你遇到问题的时候直接对号入座。现象常见原因排查思路回答明显错误或答非所问检索到的上下文与问题无关看看实际拼进Prompt的上下文是什么是不是召回环节丢了关键文档模型“编造”文档里没有的信息提示词缺少禁止性约束在当前模型下如果加了“仅基于资料回答”仍然编造检查检索到的片段是否不完整或尝试补充更多相关片段找得到文档但回答不精确文档分块有问题关键信息被切断调整分块策略尝试按标题结构切块而不是机械按字数切回答每次都不一样温度参数太高调低temperature必要时固定seed引用来源对不上内容引用标注逻辑有Bug检查上下文标号顺序和拼接位置是否一致系统响应太慢检索内容过多或请求内容过大缩小召回数量精简历史记录必要时对问题做改写压缩5.2 排查思路与调试经验首先是“打开黑盒”把中间过程摊开看。我在最初定位问题的时候最常用的工具就是“日志全打”。用户问的是什么、检索到的Top5文档分别是什么、拼装后的上下文是什么、模型返回的原文是什么——这些全部打印出来。很多问题看一遍这些日志就能定位。其次是“控制变量”。如果回答有问题先别一口气改三个地方——又是换模型又是改提示词又是调参数。一次只改一个变量跑评估集对比效果。改完后如果效果变好了保留变差了回滚。这种“单一改动”的习惯让我少走了很多弯路。最后是“不要盲目迷信网上流传的提示词模板”。同一个模板在不同的模型上表现可能天差地别。你唯一的判断标准就是自己的评估集。把模板A和模板B跑同一组问题对比结果胜者为王。别轻信所谓的“最佳实践”适合你的场景、你的模型、你的数据才是最好的。5.3 几个容易忽视的运营细节技术上打通了还有几个容易在运营阶段栽跟头的细节。第一个是知识更新的问题。知识库文档不是静态的今天加了一个新政策后天删了一个旧规则如果我们的系统没有同步更新向量库回答就会过时甚至错误。所以上线前一定要规划好数据更新机制至少要做到每日构建一次向量索引而且要有增量更新的能力而不是每次全部重建。第二个是用户问题的“预处理”。用户提问往往很口语化、很碎片化比如直接说“退货”“发票”。如果直接把这种短问题拿去检索效果不好。我建议在检索前加一道“改写”流程先用一个轻量级的模型把用户问题改写成一个更适合检索的完整问句再去做向量检索。这一步对实际用户体验的提升效果非常直接。第三个是对模型输出安全性的兜底必须在Prompt层面做明确限制。模型不是你的员工不会天然遵守你的底线。做任何面向真实用户的产品都要在提示词里明确设定后果严重的话题怎么应对比如“如果用户询问违法违规或危险内容请直接拒绝回答并建议联系官方渠道”——这类内容必须写清楚做产品的底线不能含糊。6. 学习路径建议与资源方向关于学习路径我收到最多的提问是“我到底该学什么”。这个问题背后其实是“AI工程太泛了我不知道从哪里下手”。我的建议是先把路线粗分为两条一条偏“交互层”一条偏“系统层”。交互层就是Prompt Engineering。这是最基础也是最容易上手的技能。你不需要写什么代码只需要反复跟模型对话尝试不同的提示词写法在实战中摸索。比如你试着让模型写一份策划案可以把需求越写越细加上目标人群、预算约束、时间节点、输出格式观察模型的输出变化。多试几次你会慢慢找到“哪些词对模型更有约束力”的语感。进阶一点可以研究思维链、少样本、结构化提示词这些东西并尝试把它们落地到具体的代码逻辑里。系统层就要学RAG检索增强生成、Agent架构、模型评估和微调。这一层的特点是技术栈深、环节多非一日之功。学习这一层最有效的方式是直接做项目比如复制我上面这个知识库问答机器人的实践。做完一遍你就掌握了RAG的完整链路再往里加路由、加工具调用、加多轮对话管理你的Agent能力就慢慢起来了。资源方向上不盲目推荐付费课程我的建议是先从开源项目看起把主流程读一遍不理解的地方去查官方文档。例如LangChain、LlamaIndex这些框架的官方文档本身就是很系统的学习材料内容质量相当高。然后对着自己手头的场景动手改造、运行、测试这比看一百个小时的网课都有用。7. 最后分享一些个人体会做AI工程这段时间我最深的一个感受是这个领域的门槛不在技术而在思路转变。会调用API的人多的是但能把一个AI功能真正做成稳定、可用的产品的人目前依然稀缺。如果你刚入行不必焦虑自己懂得不够多。按“先跑通最简链路再逐步优化”的节奏走就对了——第一版能做出一堆问题的系统都没关系有了评估集你就能一步步把它改好。最怕的就是只想不做在脑子里把路线图规划得尽善尽美手却从来不动。我做第一版知识库问答的时候检索逻辑写得非常粗糙只用了向量相似度也没有重排。用户问一个简单的问题经常检索回来一堆无关文档模型答案自然乱七八糟。后来我把它一点点补齐加习惯Elasticsearch做关键词并行检索加重排模型加提示词约束效果是一步一步变好的。这中间没有任何一个步骤是我一开始就全部想明白的全部是被问题推着走、被评估数据牵着往前优化出来的。所以别怕问题多AI工程就是一个不断跟不确定性共舞然后把不确定性一步一步驯化成确定性的过程。上手做把第一个项目完整做完你学到的绝对比看一百篇文章都多。