1. 认识AI工程这到底是个什么方向“ai-engineering-from-scratch”——我当初看到这个项目标题的时候第一反应是好家伙又一个准备从零开始硬啃AI的人。但真正把这个项目从命名做到落地之后我反而觉得这个名字起得相当准确它点明了这条路上最核心的一个矛盾大家想学的其实是“人工智能”这门学科但真正解决的问题却是“工程化”这件事。先聊清楚一个很多人容易混淆的点AI工程AI Engineering不等于机器学习研究更不等于“会调几个深度学习框架的API”。机器学习研究关心的是模型结构怎么设计、损失函数怎么收敛、新算法怎么在 benchmark 上刷分AI工程关心的是另外一堆问题——数据从哪来、模型怎么接入业务、推理延迟压不压得住、线上效果怎么评估、模型挂了怎么兜底、效果变差了怎么回滚。说白了机器学习研究的目标是“做出一个模型”AI工程的目标是“把一个模型变成系统的一部分稳定地跑在生产环境里”。所以这个项目真正适合的人群非常清晰有基本的编程功底可能写过Web后端或处理过数据管道但对AI的了解停留在“用过ChatGPT”这个层级想系统地往前走一步搞清楚那些AI应用背后是怎么被搭出来的。同时也适合那些已经在调模型、写训练脚本但对“部署”和“上线”这两个词毫无概念的算法同学。这个标题本身没有限定技术栈没有限定框架说明作者想讲的是一整套方法论而不是某个工具的教程。从影响范围来说这个方向这两年其实已经变成了AI行业里最稀缺的能力。一个公司里能调出好模型的人不少但能把模型稳定地变成产品的人一直不够用。原因倒也好理解工程化能力是综合性技能要懂服务端、懂容器、懂数据、懂监控还得懂一点模型本身这种“什么都要懂一点但不要求精通到学术级”的定位恰恰就是AI工程师的本质。2. 从零开始的技术栈我踩过的选型弯路2.1 不要一上来就追框架市面上跟AI工程沾边的工具多到让人眼花缭乱LangChain刚火完LlamaIndex又出来了今天大家都在聊AutoGen明天冒出一个CrewAI。我见过太多人把这些工具全部学了一遍结果真正要做一个项目的时候发现脑子里全是一堆API的名字但完全不知道系统是怎么串起来的。我的建议是从零开始做AI工程先给自己定三个阶段的清晰目标第一阶段用最笨的方式把一条链路完整跑通第二阶段理解每个环节的瓶颈在哪第三阶段再引入框架和工具来提升效率。如果你一上来就抱着LangChain写业务代码你学到的是“怎么调用LangChain”而不是“怎么解决AI工程问题”这两个是完全不同的能力。以我个人的项目为例我的核心链路是资料入库 → 文本切片 → 向量化 → 检索召回 → 大模型生成 → 结果评估。第一版我只用了最小的依赖——一个FastAPI做服务一个OpenAI的嵌入接口一个开源向量库一个直接调用大模型接口的代码块。整个项目只有几百行代码但链路是完整的。等到这一版跑通了我才回头去研究哪些环节可以抽象成框架能力哪些环节工具链更适合生产环境。2.2 AI工程的基本骨架六大环节缺一不可梳理一下我最终定的技术栈以及每个环节我为什么做这样的选择环节我的选型备选项选择理由服务框架FastAPIFlask、Django原生支持异步文档自动生成AI服务场景最顺手向量存储Milvus Lite开发/ Qdrant生产Chroma、FAISS、pgvector兼顾开发效率和垂直检索性能支持过滤和混合检索嵌入模型text-embedding-3-small初期/ BGE-M3私有化通义、文心、Cohere先走通链路、再考虑成本和数据合规大模型调用OpenAI SDK / 国内云厂商SDK直接Requests调用SDK封装了重试和流式省掉大量底层细节任务编排自研PipelineLangChain、LlamaIndex初期代码透明可控后面再决定是否抽象评估框架RAGAS 自建评测集纯人工评估自动指标先跑一遍再人工抽样看案例这套选型的核心逻辑其实只有一条每个环节选当时能用最少代码跑通的方案。等到项目跑起来你自然会知道哪里慢、哪里贵、哪里不稳定那时候的升级决策才是真正服务于业务的。举个例子向量库这个东西网上一搜全是“Milvus还是Pinecone”“Qdrant还是Weaviate”的对比文章。但对于从零开始的开发者来说前期只有几万条文本随便哪个向量库都能扛住。真正影响体验的反而是那些很小的细节比如索引构建是否需要额外服务、是否需要开Java还是Go的依赖环境、文档里的快速开始代码能不能直接跑通。很多东西要等量级上来之后才有讨论的意义在早期过度优化架构是AI工程新手最容易犯的毛病。2.3 需要学的基础理论到底有多少很多人一听AI工程要学一堆东西就头大机器学习、深度学习、NLP、向量检索、分布式系统、MLOps……好像是一个无底洞。但我的实际体会是从“零基础”到“能搭建一个像样的AI应用”需要掌握的理论知识远比想象中少关键是要掐准层面。真正绕不开的基础有三块一是Python编程二是数据结构和基础算法三是理解大模型是怎么工作的。第三块里你不需要懂Transformer的每个数学细节但你需要清楚几个关键概念Token是什么、上下文窗口意味着什么、Embedding到底是什么东西、温度采样怎么影响输出、RAG检索增强生成为什么能缓解幻觉。这些概念每个花半天到一天就能搞明白但它们构成了你在工程上做判断的底层依据。至于机器学习理论如果你是做AI应用工程不是做模型训练那很多内容可以暂时跳过。以我个人经验来说逻辑回归、决策树这些经典算法我到现在都没在生产环境里用过一次。倒是一些工程侧的概念——评估指标精确率、召回率、F1、过拟合和欠拟合、训练集和测试集划分的逻辑——反而每天都在用。这一点可能跟很多课程宣传的不太一样但事实就是AI工程的核心矛盾通常不在算法精度而在于数据质量、系统稳定性和用户体验。3. 核心实操从空仓库到可用的RAG系统3.1 定义清楚你要做的系统AI工程里几乎没有“通用系统”只有“在特定场景下能用的系统”。所以动手写代码之前先花一点时间把需求边界画出来。我当时的项目定义是搭建一个基于本地知识库的问答助手输入是几份PDF格式的技术文档输出是对应问题的带有出处引用的回答要求回答尽量基于文档内容而不是模型自己的臆测。这个定义看着简单但它直接决定了后面所有技术选型。因为要处理的是本地文档所以需要一个入库管道的环节因为要引用出处所以检索结果必须保留文档的段落信息和页码信息因为要求尽量基于文档回答所以RAG方案是必然选择而不是靠模型微调或者纯靠提示词约束。做个对比你就明白了如果项目需求是“给客服提供一个内部知识检索工具”那系统的核心评价指标是召回率和响应速度如果需求是“写一个营销文案生成助手”那核心评价指标变成了生成内容的相关性和多样性。需求定义不同后面的整个技术方案都不同。所以“需求分析”这个看似跟技术无关的步骤反而是AI工程里最需要花心思的地方。3.2 搭建数据入库管道文档处理的细节坑数据处理是AI工程里最繁琐但最决定上限的环节。我的输入是PDF文档但PDF解析本身就是一坑接一坑。我用过PyPDF2简单文档还行一旦遇到多栏排版或者表格抽出来的文本顺序就是乱的后来换了pdfplumber对表格结构友好一些但速度慢。最后我采用的是组合方案标题结构用PyMuPDF抽取正文和表格用pdfplumber补充两个结果合并清洗。入库的Pipeline分为四步原始文件解析输出带元信息的文本块文本清洗去掉页眉页脚、无关水印、多余空行切片按目录层级和字符数量双重规则切块向量化把每个切片转换成Embedding向量并入库其中切片这一环踩坑最多。最开始我简单按固定长度切比如每段500个字符结果就是一句话从中间被截断语义变得残缺导致检索效果差。后来改成“优先按段落边界切、段落太长再按句子边界切”效果立刻好了很多。更进阶的做法是让切片之间有重叠区比如重叠50个字符避免检索时因为边界截断而漏掉关键内容。对每个切片我都会额外存一份元数据metadata包括来源文件名、一级标题、二级标题、页码、切片序号。这些元数据在后期做过滤检索和结果溯源时非常关键。比如用户提问“这个方案的成本是多少”如果问题里含“成本”关键词就可以先用元数据做一次粗筛只检索跟成本相关的章节准确性会高很多。3.3 向量化与检索Embedding不只是调接口在整个RAG链路里Embedding这个环节是最容易被低估的。很多人觉得调用一下嵌入接口把文本传进去拿回一个向量数组任务就完了。但实际使用中Embedding的选择会直接决定你的检索质量上限——后端的向量检索只是“在向量空间里找最近的邻居”如果向量空间本身就没拉开距离怎么搜都搜不好。这里分享几个我实测出来非常影响效果的小决策第一个是查询Query端和文档Document端要不要用同一个模型。很多模型厂家推荐在检索场景下用对称模型或非对称模型简单说就是“提问的句子”和“被检索的长文档”本身在语义空间里的分布差异很大。如果在效果上遇到“搜不到相关段落”的问题优先检查一下是不是Embedding模型选错了类型。第二个是向量维度不是越大越好。维度越高存储开销越大检索延迟也会上升但语义精度的提升并不是线性的。我一开始图省事直接用大批量接口拿高维向量结果检索耗时从几十毫秒涨到几百毫秒对于交互式应用来说这个延迟级别的差异用户是能感知到的。后来换了更合适的模型维度降了速度上来了效果反而没有明显变差。检索环节本身我先做了最简单的向量相似度检索余弦距离跑通之后加了两个增强一是上面说的元数据过滤二是重排序Rerank。简单说向量召回阶段先拿回Top 20的候选段落然后用一个专门的排序模型在这20条里重新打分选出Top 5作为最终上下文。这一步的收益非常直接——很多向量相似度高但实际不相关的段落重排序阶段会被正确压下去。为什么需要重排序因为向量检索的“相似”和真正业务意义上的“相关”之间存在鸿沟。向量相似度高可能只是因为两个文本在措辞和风格上相近而重排序模型经过了专门的配对训练更理解“这段内容是否真正回答了那个问题”。这两者的配合逻辑有点像“初试海选、复试精挑”成本不高但确定性提升明显。3.4 大模型生成工程上要处理的四个细节当检索把相关上下文都拿到手之后生成环节看起来就是“把上下文和问题一起丢给大模型”但实际上有很多工程细节决定了一个系统是否“可用”。先看代码这是我当时构造提示词的核心逻辑def build_prompt(query: str, contexts: list[dict]) - str: system_prompt 你是一个严谨的文档问答助手。请严格基于给定的参考资料回答问题如果参考资料中没有相关信息请直接回答资料中未找到相关内容不要编造。 context_parts [] for idx, ctx in enumerate(contexts): context_parts.append( f[片段{idx 1}] 来源: {ctx[source]}, 页码: {ctx[page]}\n{ctx[content]} ) user_prompt f 以下是参考资料 {.join(context_parts)} 请基于以上资料回答下面的问题 问题{query} 要求 1. 回答时先给结论再补充细节。 2. 如果参考了多个片段的内容请标注来源如 (片段1)(片段3)。 3. 控制回答长度在500字以内。 return system_prompt \n user_prompt这段代码里面有四个我反复调过的地方第一系统级约束必须明确写清楚“允许拒绝回答”。这是抑制幻觉最简单也最有效的手段。大模型天生的行为模式是“有问必答”如果不加约束文档里没有的信息它也会凭训练记忆硬编一个答案而且在引用格式包装之下看起来非常权威。加了这条约束之后系统宁可回答“没找到”也不胡编在真实业务场景里这种“诚实”远比“能说”重要。第二上下文注入要有明确编号和元信息。我给每个检索片段编了序号并附带了来源和页码。这样模型在生成时如果有能力遵循引用要求就可以直接输出类似“根据第3段……”这样的内容让答案的可追溯性变成系统的基础能力而不是后期人工补录。第三温度参数不要用默认值。我实际测试下来温度设为0.2左右最合适。这个数值的含义是“在保留一定词汇多样性的前提下尽量让输出确定”。有人会问为什么不直接设为0因为设为0时虽然输出最确定但一旦检索结果有轻微偏差模型纠错能力也会明显下降生成的语句偶尔会显得机械重复。0.2是我在多个场景下试出来的甜点值。第四上下文长度与答案长度要分离。上下文窗口不够大时你要做的是压缩或筛选检索片段而不是简单截断。截断会导致模型只看到问题的前半部分相关内容答案自然不完整。我当时把每段上下文控制在800字以内最多带6段这样即使在上下文窗口较小的模型上也能跑通。3.5 服务化部署把系统变成接口到这里为止系统的核心链路已经通了文档进来、切片入库、检索召回、模型生成。但这个链路目前是跑在代码里的要让真实用户用起来必须把它封装成一个标准服务。我用FastAPI做了整个接口层的封装核心结构是app.post(/v1/qa) async def qa_endpoint(request: QARequest): query request.query top_k request.top_k if request.top_k else 5 candidates retriever.search(query, top_k20) reranked reranker.rerank(query, candidates, top_ktop_k) prompt build_prompt(query, reranked) answer llm.generate(prompt, temperature0.2) return QAResponse(answeranswer, sources[c.to_dict() for c in reranked])这个接口的设计遵循了一个很实用的原则把“检索参数如top_k”暴露给调用方但把“检索内部逻辑”完全封装起来。这样外部调用方可以根据问题类型灵活调整检索数量而不会被内部复杂的策略细节干扰。部署层面我是用Docker打包的里面运行了三个服务一个API容器、一个向量库容器开发期用的是嵌入式实例生产期换成了独立部署再加上一个可选的文档解析任务容器。整套东西用docker-compose管理一条命令能起所有依赖。这些容器化的工作今天看起来是基本功但如果你是从零开始这一步能帮你省下大量环境不一致带来的无谓消耗。4. 评估与调优AI工程和算法研究的真正分水岭4.1 没有评估体系你就在盲人摸象做AI工程有个非常容易被忽视的阶段——模型选完之后、系统上线之前怎么知道它好不好用对于传统软件你写一堆单元测试就可以了但AI系统不一样它的输出是开放式的同一个问题可能每次回答都不完全一样所以你需要一套专门面向大模型应用的评估方法。我实际执行下来评估体系分为三层第一层是基于规则的自动检查第二层是利用大模型做裁判打分第三层是人工抽样审查。这三层各管一段缺一不可。自动检查解决的是硬性指标比如回答里有没有引用来源、引用格式是否合法、有没有包含“抱歉我无法回答”这类兜底语句。这些规则纯用代码实现跑得快、成本低适合每天全量跑。大模型裁判解决的是语义质量比如对“回答是否准确”“是否忠实于原文”“有无遗漏关键信息”三个维度打分。具体做法是拿着问题和回答让另一个大模型按Rubric打1到5分。这种方式虽然也被质疑过“让大模型评判大模型是否公平”但从工程角度看它具备规模化、可复现、持续一致三个优点做日常回归足够用了。人工抽样解决的是体验层面的问题。每周抽20到50个case自己看一遍重点看有没有出现模型自己脑补的细节以及引用是否真的跟答案内容匹配。事实性错误是自动评估很难抓到的只有靠人看。4.2 我的一套可复现的评估指标设计专门讲讲我实际用来评估这个问答系统可不可用的指标集。这不是什么论文级指标就是工程上每天能跑、每周能看趋势的实用清单指标含义计算方式达标线检索命中率标准答案的关键词是否出现在检索片段中人工标注后自动核对≥90%引用覆盖率回答中的引用是否都有对应的检索片段正则提取比对≥95%忠实度回答内容是否与参考段落一致无编造大模型打分1-5均分≥4完整度问题中所有子问题是否都被回答大模型打分1-5均分≥4端到端延迟从请求到返回的耗时日志统计P95≤3秒其中“检索命中率”和“忠实度”这两个指标最值得盯。前者告诉你问题出在“检没检出来”后者告诉你问题出在“模型生成的时候有没有乱说”。这两步是RAG系统的两大核心故障点基本涵盖了绝大多数质量问题。这些指标的具体数值不用死记不同业务场景阈值不同。核心价值在于当系统效果变差的时候你有一个可定位的仪表盘来识别故障在哪一层。这个能力在后面对抗数据漂移时尤其重要——业务场景变了用户提问方式和初期评测集差异越来越大系统指标会肉眼可见地下降这时候你能通过指标分层轻松定位是检索层退化还是生成层退化。4.3 调优实战检索效果差先别急着换模型我调优时总结了一个原则调优顺序要严格遵循“数据→检索→生成”的漏斗顺序不要跳层。实际情况中很多人一上来就换大模型但80%以上效果不佳的问题根源在检索侧换模型根本解决不了。具体操作上我会先做一个简单的诊断实验。拿一套固定的评测问题集把检索结果导出来人工过一遍看Top5结果里到底有几条是真正相关的。如果相关性不够先检查切片粒度、再检查Embedding模型、再检查是否要加重排序——这是我们第3节里讲的三个方向按这个顺序排查基本能覆盖绝大多数检索问题。另一个经常被忽略的点是问题改写。用户在实际使用时的问法五花八门可能口语化严重比如“这个方案的实施步骤都有啥呀感觉好复杂”原文文档里大概率没有这样的表达方式。这时即使语义模型表现优秀检索效果仍然可能很差。我的解决方案是加一个Query改写层先用大模型把口语问题重构为标准表述再拿重构后的问题去做向量检索。这个方法效果显著成本则完全可以接受毕竟改写问题的Token开销远低于重复检索的代价。生成侧的核心调优方向有两个一个是上下文选择——如果检索回来的片段数量太多塞进提示词后模型容易被无关信息干扰另一个是提示词约束——如果答案总喜欢绕弯子、不直接回答大概率是提示词里缺乏“直接回答”类指令。这些微调不太需要高深理论但需要你有系统性试错的耐心。4.4 上线之后监控和回归才是日常我做过的最幼稚的假设是“模型上线之后效果就固定了”。事实并不是这样文档会更新用户提问方式会漂移大模型供应商的版本也会静默迭代。所以监控系统很重要而且要尽量自动化。我的监控面板上放了四个核心视图请求量和成功率、平均延迟P95、各类错误码分布、评估指标趋势。评估指标趋势这个视图最有用它每周自动跑一轮之前沉淀的评测集把分数画成折线。一旦折线掉得超过阈值系统就会发通知给到值班人。还有一个在工程上容易忽略的点用户反馈的回收。我的系统接口里加了一个“回答是否有帮助”的点赞/点踩按钮后端会记录具体的问答对。每周我会人工过一遍点踩率最高的50条从中挖出系统里潜藏的问题。比如有段时间点踩率升高一查发现是用户开始用了一类新的长尾问法我的Query改写层对这类表达覆盖不佳调整之后情况立刻改善。这些反馈信号比任何评估指标都真实。5. 常见问题与排查技巧实录5.1 结构化速查表把我在“ai-engineering-from-scratch”过程中真实遇到的高频问题整理成一张速查表方便你遇到同类状况时能快速定位现象可能原因排查方法解决方案检索结果明显不相关切片粒度过大或跨主题导出检索片段人工检查切片边界按段落优先切对超长段落二次分割回答总是复述原文没有总结提示词缺总结性要求或温度过低检查生成日志中的完整提示词提示词显式要求“先结论后细节”回答引用了不存在的来源Rerank返回了含相似关键词的错误段落核对引用标注与实际检索片段增加引用合法性校验模型侧强制未找到即声明系统在高峰期延迟暴涨向量检索并发能力不足看监控中的检索耗时和APICall量热点查询加缓存大流量时上连接池用户问法变一变就搜不到Query改写层未覆盖该种表达抓取真实用户query做聚类分析扩充改写示例必要时兼职人工标注生成更多样本文档更新后答案还是旧内容入库管道没处理增量更新检查文档解析任务日志和时间戳按文档ID实现增量入库与替换删除模型偶尔输出乱码或走题切片中混入脏文本或表格损坏内容抽取对应文本片段人工检查清洗管道增加规则过滤表格内容单独处理大模型供应商服务不稳定依赖单一供应商无降级方案看错误日志里的超时/429错误多供应商切换失败自动重试另一家每一个现象背后都对应着一个具体的工程环节排查顺序从数据层开始往下走通常能一路揪出根因。记住一点不要一上来就怀疑“模型不行”这个问题在最终结论里的出现率远比你想象的要低。5.2 三个最值得说的实战坑第一个坑是**“元数据过滤过度”**。我早期为了让检索更精确给每一层都加了元数据过滤条件结果就是过滤条件本身把正确答案排除在外了。比如用户问一个跨章节的问题我只在某一个章节范围内做检索即使另一个章节也有相关内容也会被丢弃。后来我改成了“检索时不强制过滤只在重排序阶段根据元数据加权”灵活性高了很多。第二个坑是**“测试集过拟合”**。前几轮调优时我不断针对评测集里的几十个问题调整提示词和过滤策略效果一路见涨但拿到新问题上一测立刻打回原形。这说明我把评测集当成了目标本身而不是把评测集当作抽检手段。解决方式其实很土但有效评测集每两周轮换一次往里面添加一批新的、从未见过的问题确保调优过程真正在改善通用能力。第三个坑是**“引入SDK封装过早”**。一开始我图省事接入LangChain的LCEL语法代码看起来非常简洁漂亮的。但后来要调试一个具体的召回逻辑问题时发现框架把内部的Prompt结构、重排序调用顺序都抽象掉了排查问题时无端多了一层复杂度。最后我回归到用原生代码自行组装链路虽然代码量多了约两百行但整个系统的可观测性和可控性都上来了。框架适合在链路稳定后用来加速二次开发不适合在链路尚未走通时提前引入。5.3 向更复杂场景推进的建议如果你照着第3节的流程把RAG系统搭起来了下一步想继续扩展我建议按这三个方向挑一个深入一是把单路检索改成多路检索融合比如同时做关键词检索和向量检索再做结果融合这个方向对检索质量提升最直接二是加入对话历史管理让系统支持多轮对话核心在于每轮对话如何压缩历史、如何判断当前问题是否依赖上文三是做完整的MLOps闭环把评测集自动生成、回归测试、模型版本管理、灰度发布全部串起来这套东西做完你基本可以胜任绝大多数AI应用团队的工程岗位。这三个方向不需要一次性全做挑一个跟手头业务最匹配的做深做透。AI工程这条路没有天花板但第一步永远是先把一条端到端的链路跑通再谈别的。我在实际摸索中的体会是这个领域最大的门槛不是技术本身而是信息噪音太大会让人迷失方向。今天收藏了LangChain教程明天看到一篇Agent实战后天又刷到一个LoRA微调的帖子一周过去代码进度为零。所以给自己划定一条最小可行路径把每个环节的深度限定在“能跑通”这个级别然后持续迭代反而是这个领域里最稀缺的执行力。