1. 先给AI工程祛个魅它不是调库是搭系统这几年AI工程四个字被讲得太玄了。打开招聘网站AI工程师的JD能列十几条技能树从Transformer源码到K8s部署全要会看着就让人想打退堂鼓。但真在行业里做久了你会发现AI工程从零起步这件事难的不是某个算法推不出来而是大多数人一开始就把方向搞错了。先说个我反复跟新人强调的观点AI工程不是用AI做东西是把AI做成产品。这两者的差别非常大。前者是你在笔记本上跑通一个notebook模型输出了看起来很聪明的话你发给朋友看朋友说哇。后者是你把这些能力封装成一个服务别人能稳定地用、出错了能查、流量来了不崩、模型升级了不影响旧功能。这背后涉及的不只是模型本身还有数据怎么管、成本怎么控、效果怎么评、系统怎么运维。说个生活化的类比。会炒一道拿手菜和开一家餐厅是完全不同的两件事。炒菜是模型餐厅是工程——你得管采购、排菜单、定流程、培训厨师、处理差评、控制翻台率。AI工程做的就是把一道好菜变成一家能稳定营业的餐厅的活儿。这篇文章就围绕ai-engineering-from-scratch这条路来写。我不会一上来就给你扔一堆论文链接也不会让你先啃三个月的线性代数再动手。我会按我实际走过的路径告诉你哪些东西是真必须的、哪些是可以后面补的、哪些坑是几乎所有人都会踩的。适合正在转行做AI应用、或者刚入职做AI相关开发但觉得什么都还不会的读者参考。2. 从零起步到底要先学什么三层地基别搞反顺序网上关于AI学习路线的争议比甜咸豆腐脑还大。有人说数学不好别碰AI有人说Python不熟别碰AI也有人说直接干就完了。我的答案是都要学但顺序和深度极其重要。2.1 第一层地基Python工程习惯不是Python语法如果你现在连Python都不会那确实得先补语法基础。但请务必搞清楚一个点你需要的不是能写脚本的Python而是能协作的Python。这两者的差距在真实项目里会被无限放大。我看过太多新人函数写了两百行不拆、变量名叫a1/b2/c3、没有任何类型注解、错误处理全靠try-except吞掉。这种代码在notebook里跑没问题一旦要上服务、接监控、有人review基本就是灾难现场。所以第一步除了基础语法外你至少要建立这几个工程习惯项目用虚拟环境管理依赖requirements.txt或者pyproject.toml写清楚代码用函数和类组织一个函数只干一件事关键路径上写类型注解方便自己和别人读代码配置和代码分离API Key这类敏感信息绝不硬编码这些建议看起来平平无奇但它们决定了你能不能在真实团队里存活。我可以负责任地说一个人Python基础是否扎实不用聊算法看他的目录结构就八九不离十。2.2 第二层地基机器学习常识但别陷进去AI工程确实需要懂模型但懂的程度需要拿捏。我见过两类极端的人一类是完全不懂模型原理把AI当黑盒出了问题只能瞎猜另一类是沉浸在数学推导里出不来一个self-attention能推三天问到工程上怎么做缓存就摇头。正确的姿态是把模型当工具但理解工具的脾气。你不需要从零实现一次反向传播但你需要清楚这几个问题大语言模型本质上是根据上文预测下文所以它的理解和你不一样模型有上下文窗口限制不是所有信息都能塞进去同样的问题换一种问法输出质量可能天差地别这就是提示工程存在的意义模型输出不是确定性的同样的输入每次可能都不一样工程上必须处理这种不确定性这些认知不需要三个月两周就能建立。但它们是后续所有工作的地基。2.3 第三层地基系统工程思维最容易被忽略如果你去问一个算法研究员和一个AI工程师最大的区别是什么我的答案是算法研究员追求的是模型效果的上限AI工程师追求的是系统运行的确定性。这句话怎么理解模型效果再好如果调用一次要等30秒、偶尔还给你返回一段乱码、一个月要烧掉几十万API费用那这个产品就是不合格的。AI工程的核心矛盾就是要在一个充满不确定性的模型之上构建一个确定性的系统。所以在动手做第一个AI项目之前请你先在脑子里植入一个框架任何AI功能落到工程上都要拆成这几个环节——输入处理、模型调用、输出校验、失败兜底、效果评估、成本监控。你后续所有工作都是围着这个框架转的。3. 第一个能跑的项目用LLM API搭一个最小可用系统好多教程让你第一步就训练模型、微调模型我觉得这是劝退新手最快的方式。从零开始做AI工程第一个项目选错了热情就烧没了。我的建议是第一枪务必选一个投入低、反馈快、能看到完整链路的项目。3.1 项目选型为什么是文档问答机器人我在带新人时最推荐的第一项目是基于自有文档的问答机器人。原因有三第一它不需要训练数据。训练、微调LLM需要准备数据集这对新手来说是巨大的隐性成本很多人卡在这一步就放弃了。而文档问答走的是检索增强生成路线也就是常说的RAG不需要你准备标注数据你只需要有文档就行。第二它覆盖了AI工程的核心链路。这个看似简单的项目实际上包含了文本加载、内容切分、向量化、向量存储、检索召回、大模型生成、流式输出、对话管理、效果评估几乎覆盖了所有AI应用开发的环节。做完这一个项目你对AI工程的整个流程就有了体感。第三它有着清晰的应用价值。做完之后你可以真的把它用起来比如把你的博客文章做成一个问答机器人或者把你的学习笔记做成一个知识库助手。我希望你的第一个AI项目做完之后是真有用的不是跑完demo就扔在那里吃灰。3.2 选型清单新手少踩坑的推荐组合说几个我用下来最顺手的组合直接抄作业就行模型调用OpenAI的GPT-4o-mini或者国产的DeepSeek、通义千问都行选你有渠道能稳定调用的那个向量化文本向量嵌入用OpenAI的text-embedding-3-small或者BGE系列开源模型向量存储先别上Milvus、Weaviate这些重量级选手用Chroma或者FAISS就够本地跑通全链路再说RAG框架LangChain或者LlamaIndex都可以但我更建议第一遍先别用框架最后一条多说两句。LangChain早期版本封装得太狠新手出了问题根本不知道背后的机制我身边不少人被它折磨得够呛。我的建议是第一个版本不用任何RAG框架直接用脚本方式把链路写出来——文档加载、切分、调向量化接口、存入向量库、检索、拼prompt、调LLM。这个过程写下来大概两百行代码你得亲手摸一遍之后再上框架就能理解它替你做了什么。这个先裸写、再框架的顺序值得每个从零开始的人都试一试。3.3 核心代码骨架两百行摸清全链路下面这段代码展示了最小闭环的核心逻辑我把每一步都写了注释你照着搭就能跑通# 步骤1读取文档内容 from pathlib import Path text Path(my_notes.md).read_text(encodingutf-8) # 步骤2按固定长度切分文本块 # 注意切分是RAG效果的根基块太小语义不完整块太大检索不精准 chunk_size 500 chunks [text[i:ichunk_size] for i in range(0, len(text), chunk_size)] # 实践中更推荐按章节/段落结构切分不要无脑按字符切 # 步骤3调用向量化接口为每个文本块生成向量 from openai import OpenAI client OpenAI() def embed_texts(texts): resp client.embeddings.create(modeltext-embedding-3-small, inputtexts) return [item.embedding for item in resp.data] vectors embed_texts(chunks) # 步骤4存入本地向量库 import chromadb chroma_client chromadb.Client() collection chroma_client.create_collection(my_docs) collection.add( documentschunks, embeddingsvectors, ids[fchunk_{i} for i in range(len(chunks))] ) # 步骤5用户提问 - 检索 - 组装上下文 - 生成回答 question 我的博客上关于Python虚拟环境的最佳实践是什么 q_vec embed_texts([question])[0] results collection.query(query_embeddings[q_vec], n_results3) context \n\n.join(results[documents][0]) prompt f请基于以下资料回答问题。如果资料中没有相关内容请直接说明不知道不要编造。 资料 {context} 问题 {question} response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}] ) print(response.choices[0].message.content)这段代码看着简单其实信息量很大。你仔细品一下第2步的切分逻辑和第5步的检索逻辑它们决定了整个系统的回答质量。后面我展开讲。3.4 跑通之后别急着欢呼先做三件不性感的事Demo跑通只是万里长征第一步很多人就是死在这个节点上。接下来这三件不性感的工作才是从跑通到能用的真正分水岭。第一写一个最小化的测试集。准备20个问题一半是文档里明确有的一半是文档里完全没提的。跑一遍把答案记下来。这是你后面所有改进的基准线。第二给API调用加上日志。每次调用记下用了哪个模型、输入了多少token、输出了多少token、耗时多久、花了多少钱。没有这些数据你的系统就是个黑洞出了问题完全无从下手。第三做一个最简陋的Web界面。不用花里胡哨Flask起个页面能输入问题、显示答案就行。哪怕你自己一个人用这个界面也会逼着你去思考用户会怎么用——而这个过程就是产品思维的起点。4. 真正卡住我的三个问题工程化视角下的隐形陷阱进入AI工程这个领域之后你会发现真正让你掉头发的往往不是模型效果本身而是一些看起来应该很简单的工程细节。我挑三个几乎所有人都会碰到的典型问题把排查链路完整讲一遍。4.1 文档问答答非所问检索环节失效了这是我第一个项目最大的翻车现场。我把一篇技术文章做成知识库问如何配置环境变量模型回答的内容跟文章完全不沾边。第一反应是模型不行但我换了更强的模型后问题依旧才意识到根本不是生成环节的锅。排查过程是这样的。我先手动把用户问题拿去向量库里检索看召回的前三条结果到底是什么。结果发现召回的文本块内容跟环境变量这个主题完全无关。再往下查发现文章的正文里虽然频繁出现环境变量但切分后的文本块把标题和正文拆散了每个块里只有零散的句子语义不完整检索自然匹配不准。这个坑的根源就在切分策略上。我当时是按500字符硬切把完整段落从中间一刀切断了。后来改成按Markdown的标题层级和段落结构切分先按##分割大章节再按段落分割成块召回效果立刻就好起来了。这件事给我的教训是在RAG系统里检索效果决定了系统效果的上限而切分策略是检索效果的基石。你问得再好模型再强检索出的资料是错的答案就不可能对。优化顺序一定是先优化数据侧再考虑模型侧。4.2 成本失控一个月的API账单翻了三倍第二个问题来得更隐蔽。系统上线两周后我查账单吓了一跳——API费用高得离谱而且还在加速增长。当时第一反应是是不是有用户疯狂调用结果一查日志调用频率没有明显异常。后来我把费用拆解到每次调用才发现真正的问题在对话历史里。我的问答系统会在每次请求时把完整的对话历史回传给模型看起来是为了多轮上下文连贯但对话一旦长了历史里的token数量指数级膨胀。用户问10轮之后光是回传历史就要消耗几万token而真正对回答有用的往往只有最近两三轮的内容。这不是个例几乎每个初做对话系统的人都会栽在这里。解决方式也很直接做滑动窗口只保留最近N轮对话同时定期做摘要压缩把久远的对话内容概括成几句话再塞进上下文。另外还有一个习惯要养成所有prompt模板里的固定内容也占token模板写得越啰嗦成本越高精简模板能省出一笔不小的钱。4.3 同样的输入答案忽好忽坏输出不确定性被低估了第三个问题是最容易让非技术背景的人崩溃的同一个问题早上问和晚上问答案风格不一样同一分钟问两次一次好一次差。这在LLM应用里是常态模型的采样参数决定了输出天然有随机性。工程上怎么处理首先把不该随机的地方固定下来调用API时设置temperature参数需要稳定输出的场景把它调到0甚至更低。其次如果你对回复格式有严格要求比如需要JSON输出、需要固定字段那必须在prompt里给出严格的格式说明并在代码侧做输出格式校验解析失败就重试一次。但还有一层更深的问题模型版本会变。你昨天调试好的prompt今天可能因为模型供应商升级了后端模型而效果突变。这个问题几乎无解唯一的应对措施是把prompt和模型版本都纳入版本管理每次模型升级后都跑一遍评估集用数据说话而不是凭感觉。这也是为什么我前面让你准备20个测试问题——它们就是你的回归测试集。5. 从最小可用迈向真正可用部署、评估与Agent实践如果你已经跑通了一个完整项目并且把前面那三个坑都踩了一遍、填平了那恭喜你你已经完成了从0到1的过程。接下来这个阶段是从1到100核心工作是让系统真正可交付。5.1 部署的克制别一上来就上K8s说句实在话现在很多教程特别喜欢让你上Kubernetes、容器化加微服务我觉得这是严重的本末倒置。作为一个从零起步的人你最大的敌人是复杂度——它会把你的精力从功能开发上全部抽走让你陷入YAML配置的泥潭里。我建议的部署路径是分层的。第一层单体应用加一个普通Linux服务器。用systemd管理Python服务进程加一个Nginx做反向代理再配一下HTTPS证书这就够了。第二层当你真的需要隔离环境、快速扩容时再引入Docker。第三层当你的服务需要自动伸缩、多实例管理时再去碰Kubernetes。我的经验是90%的AI应用垂直场景走到第二层就够了。这里有一个具体的建议部署之后一定要配一套最基础的可观测体系。至少包括三块——错误日志进程报了哪些异常、性能指标接口响应时间、模型调用耗时、业务数据每天有多少次调用、答了多少问题。这三样配齐你才有资格说这个系统是可运维的。5.2 用评估集倒逼效果提升让改prompt不再靠感觉很多人在优化AI应用效果时做法非常随缘觉得效果不好就换个措辞再试试了几次效果似乎好了就收工了。这种做法最大的问题在于你根本不知道变好是真的变好了还是只是这次碰运气。正确的姿势是建立一个可持续的评估机制。我做评估的方式很简单但也够用。先是准备一个评估集大概50到100条覆盖正常问题、边界问题、不该回答的问题这些类型。然后每次改动prompt、调整检索参数、更换模型版本时都跑一遍评估集记录每次的得分情况。评估打分不需要太复杂初期用三档制就够完全正确、基本可用、完全错误。你不需要给分数只需要一个相对标准。为了让打分者更客观我建议先把预期答案写好再跑模型输出逐个对比。凡是完全错误的案例一律拉出来归因是检索没召回到正确资料还是模型没理解资料还是prompt没说清楚输出要求。这样每轮迭代都有明确的方向不再是你跟模型之间的一场玄学博弈。5.3 从单次问答到Agent记住复杂度是渐进长出来的RAG做的问答机器人本质上是一次检索加一次生成它没有做事的能力。当你开始不满足于此想让AI帮你查天气、订机票、查数据库、自动执行多步骤任务时就进入了AI Agent的范畴。Agent的核心机制是什么拆开来看无非是三件事让模型理解当前任务、给模型提供可调用的工具列表、让模型在循环里决定下一步该调用哪个工具。中间涉及任务规划、工具调用、结果解析、循环终止判断等机制。但我要提醒你的是Agent的每一步都引入了新的不确定性。模型可能选错了工具、可能循环不终止、可能生成了格式正确的调用但参数是错的。我见过太多人看完Agent的概念之后热血沸腾一上来就要做一个全自动的智能体。我的建议非常保守从单步工具调用开始。先让模型学会根据用户意图调用一个查询函数稳定之后再加多步规划再稳定才考虑多个Agent分工协作。每一步都要用你的评估集卡一遍效果别让复杂度跑在你的掌控力前面。这个道理放在Agent上也成立复杂度是长出来的不是设计出来的。5.4 关于模型微调先别急等你真的撞到天花板再说随着项目深入你一定会动要不要微调一个自己的模型的念头。很多人在这个念头上一头扎进去花了几周时间准备数据、租GPU、训练最后发现效果提升极其有限。我要非常坦诚地说基于我见过的大量案例绝大多数人在做AI应用时真正需要的是更好的prompt、更好的检索、更好的上下文管理而不是微调模型。微调适合什么场景你的任务形态很稳定——比如你只要模型输出固定格式的JSON或者你的问答风格非常固定——同时提示工程无论如何都达不到你的要求那时候才轮得到微调上场。在那之前把精力花在数据侧和检索侧性价比高得多。6. 从零到一之后我的几点掏心窝建议文章写到最后不打算再给你灌输什么全景路线图就说说我自己走过来之后普遍会对后来者说的几句话。第一句话是AI工程从零开始最重要的不是学会某一个具体的工具而是建立用系统视角看AI的思维习惯。当你面对任何一项AI能力时脑子里自动浮现出输入处理、模型调用、输出校验、失败兜底、效果评估、成本监控这条链路就算入门了。这个思维的建立不靠刷教程靠的是亲手把一个项目跑起来再反复打磨它。第二句话是一定要善待你的评估集和日志。这两样东西是你最忠实的同事。你改prompt时它在、你换模型时它在、你调检索参数时它还在。有了它们你的每一次优化都是确定性动作而不是掷骰子。第三句话是保持好奇和动手的习惯。AI这个领域迭代速度快得惊人上个月还在用的工具下个月可能就过时了。但只要你已经建立起了拆解一条链路的能力任何新工具本质上都是往这条链路的某个环节填一个实现而已。我在实际使用中最大的体会就是有了从零搭建一次系统的经验兜底再学什么东西都快。最后再分享一个让这个项目可以继续扩展的小技巧把跑通的RAG项目改造成支持多知识库版本。同一个框架接不同的文档目录就能变成不同场景的问答助手。这一步做完之后你会发现AI工程的套路感一下子就出来了——原来不同的应用场景本质上是在复用同一套工程骨架。这也是我最想让你从这篇文章里带走的东西骨架在你手里剩下的事情就是往里填你想要的内容了。 AI工程从零起步：从RAG项目到系统化落地的完整路径
1. 先给AI工程祛个魅它不是调库是搭系统这几年AI工程四个字被讲得太玄了。打开招聘网站AI工程师的JD能列十几条技能树从Transformer源码到K8s部署全要会看着就让人想打退堂鼓。但真在行业里做久了你会发现AI工程从零起步这件事难的不是某个算法推不出来而是大多数人一开始就把方向搞错了。先说个我反复跟新人强调的观点AI工程不是用AI做东西是把AI做成产品。这两者的差别非常大。前者是你在笔记本上跑通一个notebook模型输出了看起来很聪明的话你发给朋友看朋友说哇。后者是你把这些能力封装成一个服务别人能稳定地用、出错了能查、流量来了不崩、模型升级了不影响旧功能。这背后涉及的不只是模型本身还有数据怎么管、成本怎么控、效果怎么评、系统怎么运维。说个生活化的类比。会炒一道拿手菜和开一家餐厅是完全不同的两件事。炒菜是模型餐厅是工程——你得管采购、排菜单、定流程、培训厨师、处理差评、控制翻台率。AI工程做的就是把一道好菜变成一家能稳定营业的餐厅的活儿。这篇文章就围绕ai-engineering-from-scratch这条路来写。我不会一上来就给你扔一堆论文链接也不会让你先啃三个月的线性代数再动手。我会按我实际走过的路径告诉你哪些东西是真必须的、哪些是可以后面补的、哪些坑是几乎所有人都会踩的。适合正在转行做AI应用、或者刚入职做AI相关开发但觉得什么都还不会的读者参考。2. 从零起步到底要先学什么三层地基别搞反顺序网上关于AI学习路线的争议比甜咸豆腐脑还大。有人说数学不好别碰AI有人说Python不熟别碰AI也有人说直接干就完了。我的答案是都要学但顺序和深度极其重要。2.1 第一层地基Python工程习惯不是Python语法如果你现在连Python都不会那确实得先补语法基础。但请务必搞清楚一个点你需要的不是能写脚本的Python而是能协作的Python。这两者的差距在真实项目里会被无限放大。我看过太多新人函数写了两百行不拆、变量名叫a1/b2/c3、没有任何类型注解、错误处理全靠try-except吞掉。这种代码在notebook里跑没问题一旦要上服务、接监控、有人review基本就是灾难现场。所以第一步除了基础语法外你至少要建立这几个工程习惯项目用虚拟环境管理依赖requirements.txt或者pyproject.toml写清楚代码用函数和类组织一个函数只干一件事关键路径上写类型注解方便自己和别人读代码配置和代码分离API Key这类敏感信息绝不硬编码这些建议看起来平平无奇但它们决定了你能不能在真实团队里存活。我可以负责任地说一个人Python基础是否扎实不用聊算法看他的目录结构就八九不离十。2.2 第二层地基机器学习常识但别陷进去AI工程确实需要懂模型但懂的程度需要拿捏。我见过两类极端的人一类是完全不懂模型原理把AI当黑盒出了问题只能瞎猜另一类是沉浸在数学推导里出不来一个self-attention能推三天问到工程上怎么做缓存就摇头。正确的姿态是把模型当工具但理解工具的脾气。你不需要从零实现一次反向传播但你需要清楚这几个问题大语言模型本质上是根据上文预测下文所以它的理解和你不一样模型有上下文窗口限制不是所有信息都能塞进去同样的问题换一种问法输出质量可能天差地别这就是提示工程存在的意义模型输出不是确定性的同样的输入每次可能都不一样工程上必须处理这种不确定性这些认知不需要三个月两周就能建立。但它们是后续所有工作的地基。2.3 第三层地基系统工程思维最容易被忽略如果你去问一个算法研究员和一个AI工程师最大的区别是什么我的答案是算法研究员追求的是模型效果的上限AI工程师追求的是系统运行的确定性。这句话怎么理解模型效果再好如果调用一次要等30秒、偶尔还给你返回一段乱码、一个月要烧掉几十万API费用那这个产品就是不合格的。AI工程的核心矛盾就是要在一个充满不确定性的模型之上构建一个确定性的系统。所以在动手做第一个AI项目之前请你先在脑子里植入一个框架任何AI功能落到工程上都要拆成这几个环节——输入处理、模型调用、输出校验、失败兜底、效果评估、成本监控。你后续所有工作都是围着这个框架转的。3. 第一个能跑的项目用LLM API搭一个最小可用系统好多教程让你第一步就训练模型、微调模型我觉得这是劝退新手最快的方式。从零开始做AI工程第一个项目选错了热情就烧没了。我的建议是第一枪务必选一个投入低、反馈快、能看到完整链路的项目。3.1 项目选型为什么是文档问答机器人我在带新人时最推荐的第一项目是基于自有文档的问答机器人。原因有三第一它不需要训练数据。训练、微调LLM需要准备数据集这对新手来说是巨大的隐性成本很多人卡在这一步就放弃了。而文档问答走的是检索增强生成路线也就是常说的RAG不需要你准备标注数据你只需要有文档就行。第二它覆盖了AI工程的核心链路。这个看似简单的项目实际上包含了文本加载、内容切分、向量化、向量存储、检索召回、大模型生成、流式输出、对话管理、效果评估几乎覆盖了所有AI应用开发的环节。做完这一个项目你对AI工程的整个流程就有了体感。第三它有着清晰的应用价值。做完之后你可以真的把它用起来比如把你的博客文章做成一个问答机器人或者把你的学习笔记做成一个知识库助手。我希望你的第一个AI项目做完之后是真有用的不是跑完demo就扔在那里吃灰。3.2 选型清单新手少踩坑的推荐组合说几个我用下来最顺手的组合直接抄作业就行模型调用OpenAI的GPT-4o-mini或者国产的DeepSeek、通义千问都行选你有渠道能稳定调用的那个向量化文本向量嵌入用OpenAI的text-embedding-3-small或者BGE系列开源模型向量存储先别上Milvus、Weaviate这些重量级选手用Chroma或者FAISS就够本地跑通全链路再说RAG框架LangChain或者LlamaIndex都可以但我更建议第一遍先别用框架最后一条多说两句。LangChain早期版本封装得太狠新手出了问题根本不知道背后的机制我身边不少人被它折磨得够呛。我的建议是第一个版本不用任何RAG框架直接用脚本方式把链路写出来——文档加载、切分、调向量化接口、存入向量库、检索、拼prompt、调LLM。这个过程写下来大概两百行代码你得亲手摸一遍之后再上框架就能理解它替你做了什么。这个先裸写、再框架的顺序值得每个从零开始的人都试一试。3.3 核心代码骨架两百行摸清全链路下面这段代码展示了最小闭环的核心逻辑我把每一步都写了注释你照着搭就能跑通# 步骤1读取文档内容 from pathlib import Path text Path(my_notes.md).read_text(encodingutf-8) # 步骤2按固定长度切分文本块 # 注意切分是RAG效果的根基块太小语义不完整块太大检索不精准 chunk_size 500 chunks [text[i:ichunk_size] for i in range(0, len(text), chunk_size)] # 实践中更推荐按章节/段落结构切分不要无脑按字符切 # 步骤3调用向量化接口为每个文本块生成向量 from openai import OpenAI client OpenAI() def embed_texts(texts): resp client.embeddings.create(modeltext-embedding-3-small, inputtexts) return [item.embedding for item in resp.data] vectors embed_texts(chunks) # 步骤4存入本地向量库 import chromadb chroma_client chromadb.Client() collection chroma_client.create_collection(my_docs) collection.add( documentschunks, embeddingsvectors, ids[fchunk_{i} for i in range(len(chunks))] ) # 步骤5用户提问 - 检索 - 组装上下文 - 生成回答 question 我的博客上关于Python虚拟环境的最佳实践是什么 q_vec embed_texts([question])[0] results collection.query(query_embeddings[q_vec], n_results3) context \n\n.join(results[documents][0]) prompt f请基于以下资料回答问题。如果资料中没有相关内容请直接说明不知道不要编造。 资料 {context} 问题 {question} response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}] ) print(response.choices[0].message.content)这段代码看着简单其实信息量很大。你仔细品一下第2步的切分逻辑和第5步的检索逻辑它们决定了整个系统的回答质量。后面我展开讲。3.4 跑通之后别急着欢呼先做三件不性感的事Demo跑通只是万里长征第一步很多人就是死在这个节点上。接下来这三件不性感的工作才是从跑通到能用的真正分水岭。第一写一个最小化的测试集。准备20个问题一半是文档里明确有的一半是文档里完全没提的。跑一遍把答案记下来。这是你后面所有改进的基准线。第二给API调用加上日志。每次调用记下用了哪个模型、输入了多少token、输出了多少token、耗时多久、花了多少钱。没有这些数据你的系统就是个黑洞出了问题完全无从下手。第三做一个最简陋的Web界面。不用花里胡哨Flask起个页面能输入问题、显示答案就行。哪怕你自己一个人用这个界面也会逼着你去思考用户会怎么用——而这个过程就是产品思维的起点。4. 真正卡住我的三个问题工程化视角下的隐形陷阱进入AI工程这个领域之后你会发现真正让你掉头发的往往不是模型效果本身而是一些看起来应该很简单的工程细节。我挑三个几乎所有人都会碰到的典型问题把排查链路完整讲一遍。4.1 文档问答答非所问检索环节失效了这是我第一个项目最大的翻车现场。我把一篇技术文章做成知识库问如何配置环境变量模型回答的内容跟文章完全不沾边。第一反应是模型不行但我换了更强的模型后问题依旧才意识到根本不是生成环节的锅。排查过程是这样的。我先手动把用户问题拿去向量库里检索看召回的前三条结果到底是什么。结果发现召回的文本块内容跟环境变量这个主题完全无关。再往下查发现文章的正文里虽然频繁出现环境变量但切分后的文本块把标题和正文拆散了每个块里只有零散的句子语义不完整检索自然匹配不准。这个坑的根源就在切分策略上。我当时是按500字符硬切把完整段落从中间一刀切断了。后来改成按Markdown的标题层级和段落结构切分先按##分割大章节再按段落分割成块召回效果立刻就好起来了。这件事给我的教训是在RAG系统里检索效果决定了系统效果的上限而切分策略是检索效果的基石。你问得再好模型再强检索出的资料是错的答案就不可能对。优化顺序一定是先优化数据侧再考虑模型侧。4.2 成本失控一个月的API账单翻了三倍第二个问题来得更隐蔽。系统上线两周后我查账单吓了一跳——API费用高得离谱而且还在加速增长。当时第一反应是是不是有用户疯狂调用结果一查日志调用频率没有明显异常。后来我把费用拆解到每次调用才发现真正的问题在对话历史里。我的问答系统会在每次请求时把完整的对话历史回传给模型看起来是为了多轮上下文连贯但对话一旦长了历史里的token数量指数级膨胀。用户问10轮之后光是回传历史就要消耗几万token而真正对回答有用的往往只有最近两三轮的内容。这不是个例几乎每个初做对话系统的人都会栽在这里。解决方式也很直接做滑动窗口只保留最近N轮对话同时定期做摘要压缩把久远的对话内容概括成几句话再塞进上下文。另外还有一个习惯要养成所有prompt模板里的固定内容也占token模板写得越啰嗦成本越高精简模板能省出一笔不小的钱。4.3 同样的输入答案忽好忽坏输出不确定性被低估了第三个问题是最容易让非技术背景的人崩溃的同一个问题早上问和晚上问答案风格不一样同一分钟问两次一次好一次差。这在LLM应用里是常态模型的采样参数决定了输出天然有随机性。工程上怎么处理首先把不该随机的地方固定下来调用API时设置temperature参数需要稳定输出的场景把它调到0甚至更低。其次如果你对回复格式有严格要求比如需要JSON输出、需要固定字段那必须在prompt里给出严格的格式说明并在代码侧做输出格式校验解析失败就重试一次。但还有一层更深的问题模型版本会变。你昨天调试好的prompt今天可能因为模型供应商升级了后端模型而效果突变。这个问题几乎无解唯一的应对措施是把prompt和模型版本都纳入版本管理每次模型升级后都跑一遍评估集用数据说话而不是凭感觉。这也是为什么我前面让你准备20个测试问题——它们就是你的回归测试集。5. 从最小可用迈向真正可用部署、评估与Agent实践如果你已经跑通了一个完整项目并且把前面那三个坑都踩了一遍、填平了那恭喜你你已经完成了从0到1的过程。接下来这个阶段是从1到100核心工作是让系统真正可交付。5.1 部署的克制别一上来就上K8s说句实在话现在很多教程特别喜欢让你上Kubernetes、容器化加微服务我觉得这是严重的本末倒置。作为一个从零起步的人你最大的敌人是复杂度——它会把你的精力从功能开发上全部抽走让你陷入YAML配置的泥潭里。我建议的部署路径是分层的。第一层单体应用加一个普通Linux服务器。用systemd管理Python服务进程加一个Nginx做反向代理再配一下HTTPS证书这就够了。第二层当你真的需要隔离环境、快速扩容时再引入Docker。第三层当你的服务需要自动伸缩、多实例管理时再去碰Kubernetes。我的经验是90%的AI应用垂直场景走到第二层就够了。这里有一个具体的建议部署之后一定要配一套最基础的可观测体系。至少包括三块——错误日志进程报了哪些异常、性能指标接口响应时间、模型调用耗时、业务数据每天有多少次调用、答了多少问题。这三样配齐你才有资格说这个系统是可运维的。5.2 用评估集倒逼效果提升让改prompt不再靠感觉很多人在优化AI应用效果时做法非常随缘觉得效果不好就换个措辞再试试了几次效果似乎好了就收工了。这种做法最大的问题在于你根本不知道变好是真的变好了还是只是这次碰运气。正确的姿势是建立一个可持续的评估机制。我做评估的方式很简单但也够用。先是准备一个评估集大概50到100条覆盖正常问题、边界问题、不该回答的问题这些类型。然后每次改动prompt、调整检索参数、更换模型版本时都跑一遍评估集记录每次的得分情况。评估打分不需要太复杂初期用三档制就够完全正确、基本可用、完全错误。你不需要给分数只需要一个相对标准。为了让打分者更客观我建议先把预期答案写好再跑模型输出逐个对比。凡是完全错误的案例一律拉出来归因是检索没召回到正确资料还是模型没理解资料还是prompt没说清楚输出要求。这样每轮迭代都有明确的方向不再是你跟模型之间的一场玄学博弈。5.3 从单次问答到Agent记住复杂度是渐进长出来的RAG做的问答机器人本质上是一次检索加一次生成它没有做事的能力。当你开始不满足于此想让AI帮你查天气、订机票、查数据库、自动执行多步骤任务时就进入了AI Agent的范畴。Agent的核心机制是什么拆开来看无非是三件事让模型理解当前任务、给模型提供可调用的工具列表、让模型在循环里决定下一步该调用哪个工具。中间涉及任务规划、工具调用、结果解析、循环终止判断等机制。但我要提醒你的是Agent的每一步都引入了新的不确定性。模型可能选错了工具、可能循环不终止、可能生成了格式正确的调用但参数是错的。我见过太多人看完Agent的概念之后热血沸腾一上来就要做一个全自动的智能体。我的建议非常保守从单步工具调用开始。先让模型学会根据用户意图调用一个查询函数稳定之后再加多步规划再稳定才考虑多个Agent分工协作。每一步都要用你的评估集卡一遍效果别让复杂度跑在你的掌控力前面。这个道理放在Agent上也成立复杂度是长出来的不是设计出来的。5.4 关于模型微调先别急等你真的撞到天花板再说随着项目深入你一定会动要不要微调一个自己的模型的念头。很多人在这个念头上一头扎进去花了几周时间准备数据、租GPU、训练最后发现效果提升极其有限。我要非常坦诚地说基于我见过的大量案例绝大多数人在做AI应用时真正需要的是更好的prompt、更好的检索、更好的上下文管理而不是微调模型。微调适合什么场景你的任务形态很稳定——比如你只要模型输出固定格式的JSON或者你的问答风格非常固定——同时提示工程无论如何都达不到你的要求那时候才轮得到微调上场。在那之前把精力花在数据侧和检索侧性价比高得多。6. 从零到一之后我的几点掏心窝建议文章写到最后不打算再给你灌输什么全景路线图就说说我自己走过来之后普遍会对后来者说的几句话。第一句话是AI工程从零开始最重要的不是学会某一个具体的工具而是建立用系统视角看AI的思维习惯。当你面对任何一项AI能力时脑子里自动浮现出输入处理、模型调用、输出校验、失败兜底、效果评估、成本监控这条链路就算入门了。这个思维的建立不靠刷教程靠的是亲手把一个项目跑起来再反复打磨它。第二句话是一定要善待你的评估集和日志。这两样东西是你最忠实的同事。你改prompt时它在、你换模型时它在、你调检索参数时它还在。有了它们你的每一次优化都是确定性动作而不是掷骰子。第三句话是保持好奇和动手的习惯。AI这个领域迭代速度快得惊人上个月还在用的工具下个月可能就过时了。但只要你已经建立起了拆解一条链路的能力任何新工具本质上都是往这条链路的某个环节填一个实现而已。我在实际使用中最大的体会就是有了从零搭建一次系统的经验兜底再学什么东西都快。最后再分享一个让这个项目可以继续扩展的小技巧把跑通的RAG项目改造成支持多知识库版本。同一个框架接不同的文档目录就能变成不同场景的问答助手。这一步做完之后你会发现AI工程的套路感一下子就出来了——原来不同的应用场景本质上是在复用同一套工程骨架。这也是我最想让你从这篇文章里带走的东西骨架在你手里剩下的事情就是往里填你想要的内容了。