1. AI工程到底在做什么先把概念掰开。标题里“from scratch”说得不是“从零训练模型”而是“从零把AI做成一个能用的东西”。这两件事差别非常大也是我见过最多人搞混的地方。一个业务方说“想要一个AI客服”算法工程师第一反应是“用什么模型”而AI工程师的反应是数据从哪来用户以什么方式提问答案要不要溯源模型答错了怎么兜底延迟能不能压到3秒内监控怎么做这些问题加起来才是AI工程。它不等于调参跑模型而是把模型能力装进真实业务流程里的一整套工程实践。这个领域适合谁来学你可以是后端开发想往AI应用方向延展也可以是算法工程师想把模型真正落地还可以是刚入门不久、想在AI方向建立体系化能力的新人。只要你现在做的事是“把大模型用起来”那这篇内容就是为你准备的。我自己是半路出家做AI工程实践的前面也走过弯路——花了大把时间看论文、刷榜结果真做一个AI问答助手时最耗精力的反而是数据清洗、Prompt调优、服务并发这些“不太性感”的活。这篇就把从零开始做AI工程的完整主线拆开来讲包括思路、实操步骤、工具选型和踩坑记录都是试过的。2. 从零起步的关键主线数据、模型、工程化三条线从零开始的第一件事不是学框架而是建立整体认知。AI工程的能力结构可以拆成三条主线数据、模型、工程化。这三条线一个都不能少。2.1 数据决定AI应用上限的隐形主角多数人学AI时会把注意力放在模型上但真做业务时会发现数据才是决定效果上限的瓶颈。一个模型能发挥多少能力很大程度上取决于给它什么数据。这里的“数据”不只是训练集。即使你用的是现成大模型API数据同样重要。做知识库问答时你需要准备企业内部的文档切片做客服助手时你需要历史对话语料做法律辅助时你需要结构化的法条数据。数据是否干净、格式是否统一、切片是否合理、更新是否及时都会直接影响返回质量。我做过一个小工具的时候用同样的模型、同样的Prompt仅仅因为换了不同的文档切片策略准确率就从65%提到了85%。那次之后我就把数据准备列成了AI工程的第一优先级。数据要关注的维度至少有四点数据的覆盖度能不能覆盖用户可能问的各类问题数据的噪声水平有没有互相矛盾的表述数据的结构是否方便后续检索和引用数据的更新机制过期信息会不会造成误导很多团队上AI项目时第一周就调模型第二周发现效果不行回头才补数据工程来回折腾的成本非常高。更好的做法是先把数据管线大致搭建好再在这个稳定的底座上逐步调优模型侧策略。2.2 模型分清用模型和训模型从零做AI工程不需要一上来就钻研模型怎么训练。绝大多数场景里直接调用成熟的大模型API或基于开源模型做微调就够了。只有极少数场景需要从头预训练一个模型而那通常是超大公司或科研机构才要做的事。真正需要思考的是选型方案适合场景成本技术门槛大模型API通用问答、文本生成、内容总结按Token计费可控低开源模型微调垂直领域、数据敏感、需要私有化GPU成本高中高知识库模型增强RAG基于私有知识问答中低中我最开始做的项目选择的是“大模型API 知识库”路线也就是RAG架构。数据不需要训练进模型而是通过检索相关片段再喂给模型由模型根据检索结果作答。它的好处非常实际数据更新只需要更新知识库不用重新训练模型回答可以溯源到原文出问题时方便排查。这个路线特别适合从零起步的团队。你不需要深度学习框架不需要GPU服务器只要把工程链路打通就能做出一个体验不错的应用。2.3 工程化模型抵达用户的最后一公里AI工程的“工程”体现在哪就是把模型从Notebook搬到生产环境让它稳定对外提供服务。这一层涉及的东西很传统但又必须扎实API服务封装、调用鉴权、并发控制、超时处理、日志采集、效果监控。举个例子。一个简单的问答功能在本地跑通只需要几行代码但上线后你要面对多人同时提问时怎么控制速率模型接口超时了怎么降级返回格式不符合预期时怎么兜底用户对同一个问题连续追问时怎么处理上下文这些都是工程问题不是AI问题。我的建议是先把最基础的服务封装做扎实再考虑接入更复杂的框架。很多人一上来就用各种编排框架结果框架本身成了最大的坑。服务不稳定、整个链路都跑不通的例子我见得太多了。3. 实操主线从零搭建一个可用的AI问答助手下面用一个典型案例把整个流程串起来做一个基于私有知识库的AI问答助手。这个项目麻雀虽小五脏俱全是最适合复刻的AI工程起点。我按自己的实操过程来讲每一步都可以直接参考。3.1 需求拆解与场景定义拿到需求后先不要急把场景问清楚。我做这个项目时的需求是“让用户用自然语言查询内部文档并获取有依据的答案”。围绕这个需求我拆出了五个核心环节用户提交问题系统对问题做语义检索找到知识库中最相关的候选片段将“问题候选片段”组装成Prompt发送给大模型大模型生成带引用出处的回答结果展示并记录日志这个拆解决定了后续所有技术选型。检索用什么方案、Prompt怎么设计、返回格式怎么约定都在这个环节就定下来了。场景定义还有一个容易被忽略的维度给答案设定边界。解答不了的问题怎么答知识库里没有相关片段时是直接说“不知道”还是让模型强行编造我和团队的做法是检索结果的相关度低于阈值时直接返回“未找到相关资料”不强行生成内容。这个设计在后面防止“幻觉”上起了很大作用。3.2 数据准备与Prompt设计知识库数据来自一批内部文档。我先把文档统一转成纯文本做了基础清洗去掉页眉页脚、无意义空行、特殊符号。然后按语义完整性做切片每片控制在500~2000字之间同时保留标题信息作为切片的元数据。Prompt设计是这个项目最耗时的部分。我的调试方式是搭一个简单的测试面板左侧输入问题右侧展示模型原始返回中间显示Prompt和检索到的片段。这样一个一个问题的调比凭感觉写模板高效得多。最终用到的Prompt核心结构是这样的系统指令描述角色和任务规则然后拼接检索片段最后是用户问题。规则里特别强调了两点只能根据提供的资料回答资料中找不到时明确说明“知识库中没有相关信息”不要自行编造。这两句话的有效性超出预期极大的降低了幻觉出现的概率。3.3 应用骨架搭建技术栈我选了Python FastAPI 向量数据库。选择FastAPI的原因很简单异步性能好、类型提示友好、自动生成API文档对AI服务来说开发效率很高。向量数据库选的是本地可部署、支持Docker运行的开源方案避免引入太重的基础设施。整个服务分成两个模块离线索引模块和在线问答模块。离线模块负责把清洗后的文档切片向量化写入向量数据库在线模块接收用户请求先检索再调用模型接口最后返回结果。两个模块分开的好处是更新知识库不影响线上服务索引构建可以在空闲时间段跑。搭建服务的过程不复杂但有个工程细节值得注意模型调用时要设置合理的超时时间并做好重试与降级。我在调用大模型API时加了两层保护第一层是超时重试连续失败两次就切换备用模型通道第二层是如果模型服务完全不可用就返回检索到的原始片段给用户至少能保留一定的可用性。3.4 效果评估与上线效果评估是AI工程里最容易被忽略、也最容易翻车的一环。模型返回的结果经常“看起来对”这时候单靠人工抽查无法保证质量。我建了一套简单的评估集准备了几十条覆盖典型问题的测试用例每条都标注了期望答案或答案要点每次迭代后跑一遍评估脚本计算准确率和未命中率。评估数据后发现即使检索到的片段是正确的模型回答时也有几率省略关键信息。为了解决这个问题我在Prompt里增加了一项要求先对检索内容做概括再核对问题和内容的匹配度。这一改动把评估集的得分提升了近10个百分点。上线部署我用的是Docker容器加单机服务。先压测确认吞吐量满足预期再挂到正式环境。上线后还加了日志监控每一条问答都记录问题、检索到的片段ID、模型返回结果和耗时。这些日志是后续优化最重要的依据。4. 实操心得与避坑记录真实做项目的过程中坑远比想象中多。这里挑几个我自己踩过且非常有代表性的记录下来。4.1 文档切片策略的坑切片大小直接影响检索效果。切得太细查出来的片段信息不完整切得太粗一个片段里混了多个主题检索精准度也会下降。我先按固定长度切效果一般后来改成按标题结构切尽量保证每个片段都是一个完整的语义单元效果明显改善。处理切片重叠也需要留意。相邻切片之间留有少量重叠能在检索时减少上下文断裂的问题但重叠太多会引入大量冗余数据反而干扰排序。我实际测试下来10%~15%的重叠率是个较为稳妥的区间。4.2 Prompt调优里的反直觉有些Prompt看起来“逻辑很完备”但实际效果反而不稳定。比如我在早期版本里给模型写了一大段背景说明结果模型回答问题变得啰嗦输出格式也偶尔漂移。后来精简规则把最关键的约束前置反而稳定了。另一个反直觉的点是否定式指令的效果存在不确定性。你告诉模型“不要编造”它在大部分时候确实会遵守但少数情况下还是会一本正经地胡说。更有效的做法是正面引导——让模型“只在资料中找到答案时才回答”同时提供可选的“未找到”回应模板。减少对它自行发挥的暗示空间比单纯禁止更有效。4.3 工具选型的坑从零开始时最容易犯的错误就是“什么火用什么”。我早期想引入一个Agent编排框架觉得这样能自动完成很多事。结果发现自动编排的逻辑过于黑盒出了问题很难排查。后面回到“显式流程”的方案自己控制每一步代码虽然多了几行但每个环节都有日志可查。这给我一个很深的教训工具的价值在于降低确定性工作的成本而不是掩盖不确定性问题的复杂度。对AI工程来说可观测性比自动化重要得多。4.4 成本控制与性能平衡大模型API按Token计费这个成本很容易失控。我在一次联调时因为Prompt里拼接了过多历史上下文单次调用的Token消耗比预期高出近四倍。处理办法是控制上下文长度、限制历史对话轮数、对长文档做分段摘要。延迟也需要持续观察。检索阶段如果向量库数据量大全量暴搜会慢到不可接受这时就需要用HNSW这类索引来加速。我实测同一个向量库用暴力检索平均耗时700毫秒换成HNSW索引后降到30毫秒左右。这个优化几乎是零成本白捡的。5. 常见问题与排查技巧实录做AI工程和写传统业务代码的排查思路不太一样。传统代码的问题往往是确定的AI系统的输出却有概率性这让排查更需要方法论。我把实操中遇到的常见问题整理成速查表再讲一套排查思路。5.1 常见问题速查表现象可能原因排查方案回答内容与问题无关检索到错误片段检查检索排序逻辑与向量化质量答案很假但语气笃定模型幻觉约束失效增强Prompt限制增加无法回应分支同一问题结果飘忽温度参数过高降低temperature增加确定性输出知识库更新后无变化索引未重建重新执行文档切片与向量入库流程请求超时增多并发过高或模型API限流增加队列、限流、重试、降级引用出处对不上内容切片元数据丢失检查索引构建时是否保留来源字段这张表是我平时排查问题时最先翻的一张表。大多数问题都能从这几类原因里找到方向。5.2 排查思路三步法第一步复现与分离。把问题拆成检索、Prompt组装、模型生成三段定位问题到底出在哪一段。最简单的做法是在日志里分别打印检索结果、Prompt内容和模型输出。看是没检索到还是检索到了但回答不对能定位方向就行。第二步控制变量。改一个参数看一次效果。很多时候同时调整了Prompt、切片策略和模型版本结果变好或变坏根本说不清是哪个因素起作用。一次只动一个变量才是可靠的做法。第三步数据观察优先于直觉修改。AI应用的大部分问题背后都是数据分布的问题。当你发现某个类型的提问效果特别差时不要急着改Prompt先收集一批这类问题样本看看它们在知识库中能检索到什么内容。通常你会发现不是模型答不好而是根本检索不到合适的内容。这三步走完大部分疑难杂症都能定位到根因而不是靠“调调试”碰运气。5.3 上线后的持续监控最后提一点持续监控。AI服务上线不是终点持续观察才能发现问题。我建议至少盯住三个指标回答耗时、检索命中率、负面反馈率。三个指标分别对应了性能、知识覆盖质量和用户体验。我当时做了一个简单的看板把每天的日志统计出来。有两个发现是比较意外的一是工作日白天用户提问的准确率比晚上高原因是白天大多在工作场景内提问二是回答时带出处引用的内容用户满意度明显更高。后面一个发现直接推动了产品的改进方向——把“可溯源”做成核心卖点。6. 最后分享一点个人体会做AI工程最忌讳的就是“神化”模型把大模型当成能解决所有问题的万能引擎。实际上模型只是一个推理引擎它需要有好的输入、好的上下文、好的约束才能稳定地输出好结果。工程的核心价值恰恰是把“不一定靠谱”的模型能力用系统的方式尽可能变得可控。我自己踩过最多的坑就是在效果出问题时急着调整模型侧参数而忽略数据和工程侧的问题。后来形成一套完整的流程——先看数据再查检索再调Prompt最后才去动模型侧参数——解决问题的效率大幅提升。这个领域变化确实很快但你如果能把基础的数据处理能力、工程化意识和系统排查方法练扎实就不会被工具迭代甩下车。毕竟今天流行的明天可能被替换但那套从零搭建AI应用的骨架是可以长期复用的。
