1. 从零搭建AI工程能力为什么我劝你别一上来就调包这两年“AI工程”这个词被说得太多了多到有点变味。打开任何一个技术社区满屏都是“三行代码调用大模型”“十分钟搭建RAG”“零基础转行AI工程师”。我不否认这些内容有它的价值但如果你真的想在这个方向上站稳脚跟光会调API是远远不够的。ai-engineering-from-scratch这个标题之所以值得认真聊恰恰是因为它戳中了一个被大多数人刻意回避的问题当框架封装越来越厚、抽象层级越来越高的时候你到底还剩下多少真正属于自己的工程能力我自己是从传统后端转过来的最早接触AI相关的东西也是从调接口开始的。那时候觉得挺爽一个HTTP请求就能拿到结果好像什么都能做。但很快问题就来了模型输出不稳定怎么办上下文窗口不够用怎么拆检索回来的内容质量差怎么调推理成本压不下来怎么优化这些问题没有一个能靠“换个更好的模型”解决它们全部指向同一个东西——你对AI系统底层运作机制的理解深度。所以这篇内容我想聊的不是某个具体框架怎么用而是一套从零开始构建AI工程能力的完整思路。它适合那些已经会写代码、但对AI系统还停留在“调包”阶段的开发者也适合那些做了几个demo但总觉得心里没底、想系统补课的人。我会把整个学习路径拆成可操作的模块每个模块都告诉你为什么要学、学到什么程度够用、以及最容易踩的坑在哪里。1.1 先搞清楚“AI工程”到底在工程什么很多人把AI工程等同于“用AI做应用”这个理解太窄了。我更喜欢一个更具体的定义AI工程是围绕模型能力构建可靠、可维护、可扩展的软件系统的过程。注意这里的几个关键词——可靠、可维护、可扩展。它们才是工程和demo之间的分水岭。一个demo只需要跑通一次就算成功但一个工程系统需要在各种边界条件下稳定运行。模型返回了意料之外的格式怎么办用户输入了超长文本怎么办并发请求把推理服务打挂了怎么办这些问题的解决方式和传统后端工程有相似之处但也有大量AI特有的挑战。从能力维度拆解AI工程至少包含这几个层面模型交互层怎么和模型有效沟通、数据处理层怎么准备和清洗训练/推理数据、系统架构层怎么组织各个组件、评估与监控层怎么知道系统好不好、优化与迭代层怎么持续改进。这五层缺一不可但大多数教程只讲了第一层。我见过太多人模型交互玩得很溜提示词写得花里胡哨但一到数据清洗就抓瞎一到系统设计就只会堆API。这就是典型的“偏科”。从零构建AI工程能力核心就是把这五层都补齐哪怕每层只到及格线也比只精通一层要强得多。1.2 学习路径的整体设计逻辑我设计的这条路径遵循一个原则先通后专先手动后自动。什么意思就是先让你用最原始的方式把整个流程跑一遍理解每个环节在干什么然后再引入框架和工具去提效。这个顺序不能反。如果你一上来就用LangChain、LlamaIndex这些框架确实能快速出效果但你会失去对底层细节的感知。等到出了问题你连从哪里开始排查都不知道。而如果你先手动实现一遍最基础的版本——比如自己写一个简单的检索系统、自己实现一个对话循环——你对整个系统的掌控力会完全不一样。具体来说我把路径分成四个阶段阶段一基础能力建设。重点是理解模型的基本工作原理、掌握提示工程的核心技巧、学会用代码直接调用模型API。这个阶段不碰任何高级框架。阶段二核心组件手写。包括文本分割、向量化、相似度检索、上下文组装、对话管理等。每个组件都先手写一个最简版本。阶段三系统集成与优化。把前面手写的组件组装成一个完整系统然后引入评估机制根据评估结果做针对性优化。阶段四工程化与规模化。引入框架提效、设计可扩展架构、建立监控体系、优化成本和延迟。每个阶段大概需要两到四周的业余时间投入整个周期下来差不多三到四个月。这个节奏不算快但每一步都走得扎实。2. 基础能力建设别急着写业务代码基础能力这个说法听起来很虚但我可以很负责任地告诉你后面所有的工程问题追根溯源都能追到基础不牢上。我见过有人花了两周调提示词最后发现是文本预处理没做好导致输入质量太差。也见过有人抱怨模型效果不行结果一看他的调用方式连基本的温度参数都没设对。2.1 模型交互的最小必要知识你不需要成为算法专家但有几件事必须搞清楚。第一是token的概念。模型不是按字或词处理的而是按token。一个中文汉字通常是1到2个token英文单词平均1.3个token左右。这个数字直接关系到你的成本计算和上下文窗口管理。我建议你在项目初期就养成习惯每次调用模型前先估算一下输入输出的token量。第二是温度、top_p这些采样参数的实际影响。温度控制的是输出的随机性温度越高输出越多样但也越容易跑偏。top_p控制的是候选词的累积概率阈值。这两个参数不需要同时调通常固定一个调另一个就行。我的经验是需要确定性输出的场景比如信息抽取、分类温度设0到0.3需要创意性输出的场景比如文案生成温度设0.7到1.0。第三是上下文窗口的管理策略。每个模型都有最大token限制超出就会报错或截断。你需要知道几种常见的处理方式直接截断简单但粗暴、滑动窗口保留最近N轮对话、摘要压缩把历史对话压缩成摘要、检索增强只把相关的内容放进上下文。这几种策略各有适用场景后面我会详细展开。注意不同模型对token的计算方式不一样中文和英文的token比例也不同。做成本估算时一定要用目标模型的实际tokenizer来算不要凭感觉。2.2 提示工程的核心不是“咒语”网上流传着大量所谓的“提示词模板”“万能咒语”说实话大部分都是噱头。提示工程的核心逻辑其实很朴素把模型当成一个能力很强但完全不了解你具体情况的实习生。你需要做的是把任务说清楚、把背景给足、把要求列明白。我总结了一个实用的提示结构叫四段式角色设定、任务描述、约束条件、输出格式。角色设定是告诉模型“你是谁”比如“你是一个资深的后端工程师”。任务描述是“你要做什么”要具体到可执行的程度。约束条件是“有什么限制”比如字数限制、不能包含的内容、必须遵循的规则。输出格式是“结果长什么样”最好给一个示例。这个结构看起来简单但实际用起来效果差异很大。关键在于任务描述和约束条件的颗粒度。举个例子“帮我写一段介绍”和“帮我写一段面向有三年经验的后端开发者的、介绍消息队列核心概念的文字不超过200字不要用比喻”就是完全不同的效果。还有一个容易被忽略的点负面指令往往不如正面指令有效。你说“不要用专业术语”模型可能还是会用但你说“用日常生活中的例子来解释”效果就好很多。因为模型在生成时是逐token预测的负面指令需要它先想到那个东西再抑制它而正面指令直接引导了生成方向。2.3 手写第一个模型调用程序这个环节我建议不要用任何框架就用最基础的HTTP请求或者官方SDK。目的是让你完整地看到一次模型调用的全貌请求怎么构造、参数怎么传、响应怎么解析、错误怎么处理。以Python为例一个最简的调用大概长这样import requests import json def call_model(prompt, temperature0.7, max_tokens1000): headers { Content-Type: application/json, Authorization: fBearer {API_KEY} } payload { model: your-model-name, messages: [{role: user, content: prompt}], temperature: temperature, max_tokens: max_tokens } response requests.post(API_ENDPOINT, headersheaders, jsonpayload) if response.status_code ! 200: raise Exception(fAPI error: {response.status_code} - {response.text}) return response.json()[choices][0][message][content]这段代码没什么技术含量但你要在这个基础上做几件事加超时处理、加重试逻辑、加token计数、加日志记录。这些才是工程化的开始。我见过太多人直接response.json()[choices][0]就完事了结果线上环境稍微有点波动就崩。实操心得重试逻辑一定要加指数退避不要固定间隔重试。我一般用2^n * base_delay的方式base_delay设1秒最多重试3次。另外要区分可重试错误和不可重试错误比如429限流可以重试401认证失败重试也没用。3. 核心组件手写把黑盒拆开看这个阶段是整个学习路径里最累但也最有价值的。你要手写文本分割、向量化、检索、上下文组装这几个核心组件。手写的目的不是让你以后都用自己写的而是让你知道每个环节的输入输出是什么、有哪些参数可以调、不同选择会导致什么差异。3.1 文本分割比你想的要讲究文本分割是RAG系统的第一步也是最容易被轻视的一步。很多人直接按固定字数切比如每500字一段。这样做的问题是一个完整的语义单元可能被切断了检索出来的内容前言不搭后语。我试过几种分割策略各有适用场景策略适用场景优点缺点固定长度结构规整的文本实现简单容易切断语义按段落文章、报告保留语义完整段落长度不均递归分割混合结构文档平衡语义和长度实现稍复杂语义分割高质量要求场景语义最完整计算成本高我一般推荐递归分割作为默认策略。它的逻辑是先尝试按段落分如果某段太长就按句子分如果句子还太长就按固定长度分。这样能在语义完整和长度可控之间取得平衡。手写一个递归分割器大概需要50行代码核心是一个递归函数不断用更细粒度的分隔符去切分超长的块。这里有个细节块之间要保留一定的重叠通常10%到20%。重叠的目的是防止关键信息刚好落在切割边界上被丢掉。def recursive_split(text, max_length500, overlap50): separators [\n\n, \n, 。, , , ., , ] chunks [] def _split(t, sep_idx): if len(t) max_length or sep_idx len(separators): return [t] sep separators[sep_idx] parts t.split(sep) result [] current for part in parts: if len(current) len(part) len(sep) max_length: current part sep else: if current: result.append(current) current part sep if current: result.append(current) # 对超长的部分继续递归 final [] for r in result: if len(r) max_length: final.extend(_split(r, sep_idx 1)) else: final.append(r) return final chunks _split(text, 0) # 添加重叠 overlapped [] for i, chunk in enumerate(chunks): if i 0: prev chunks[i-1] overlap_text prev[-overlap:] if len(prev) overlap else prev overlapped.append(overlap_text chunk) else: overlapped.append(chunk) return overlapped这段代码不完美但足够让你理解分割的核心逻辑。实际生产中你可能会用现成的库但手写过一遍之后你就知道那些库的参数该怎么调了。3.2 向量化与相似度检索理解原理才能调好参数向量化就是把文本变成一串数字向量使得语义相近的文本在向量空间里的距离也相近。这个“距离”通常用余弦相似度来衡量。你不需要自己训练向量模型但需要知道几个关键点。第一不同的向量模型适合不同的场景。有的模型擅长中文有的擅长英文有的在多语言场景下表现好。选择的时候要看你的实际数据是什么语言、什么领域。通用模型在专业领域比如医疗、法律上的表现可能不如领域微调过的模型。第二向量维度影响存储和检索效率。常见的维度有768、1024、1536等。维度越高表达能力越强但存储成本和计算成本也越高。对于大多数应用场景1024维已经足够。第三相似度检索不一定是精确的。当你的文档库很大时比如几十万个块精确计算每个块的相似度会非常慢。这时候需要用近似最近邻ANN算法比如HNSW、IVF。这些算法用一定的精度损失换取速度提升。手写一个最简的向量检索系统其实不难import numpy as np class SimpleVectorStore: def __init__(self): self.vectors [] self.texts [] def add(self, text, vector): self.vectors.append(vector) self.texts.append(text) def search(self, query_vector, top_k5): if not self.vectors: return [] vectors np.array(self.vectors) query np.array(query_vector) # 余弦相似度 similarities np.dot(vectors, query) / ( np.linalg.norm(vectors, axis1) * np.linalg.norm(query) ) top_indices np.argsort(similarities)[-top_k:][::-1] return [(self.texts[i], similarities[i]) for i in top_indices]这个实现是O(n)的复杂度文档量大了会慢但用来理解原理足够了。你可以在这个基础上加索引、加缓存、加过滤条件逐步优化。踩过的坑余弦相似度对向量的模长不敏感但有些向量模型输出的向量模长差异很大。如果你发现检索结果不稳定可以先对向量做归一化再计算相似度。另外查询向量和文档向量最好用同一个模型生成混用不同模型的向量是没有意义的。3.3 上下文组装把正确的信息放在正确的位置检索到了相关文档怎么把它们和用户问题一起塞进模型的上下文窗口这里面也有讲究。我总结了几条经验位置很重要。模型对上下文开头和结尾的信息关注度更高中间部分容易被忽略。所以最重要的信息应该放在开头或结尾。我通常把最相关的检索结果放在用户问题之前次相关的放在之后。数量要控制。不是检索结果越多越好。太多无关信息会稀释关键信息还会增加token消耗。我一般检索top 5到top 10然后根据实际效果调整。格式要清晰。检索结果和用户问题之间要有明确的分隔让模型知道哪些是参考资料、哪些是问题。我习惯用这样的格式参考资料 [1] {文档1内容} [2] {文档2内容} ... 用户问题{问题}要处理冲突。如果检索到的多个文档之间有矛盾模型可能会困惑。这时候要么在提示词里说明“如果资料有冲突以最新的为准”要么在检索阶段就做去重和排序。3.4 对话管理多轮对话的状态维护单轮问答相对简单多轮对话就复杂了。核心问题是历史对话怎么处理全部保留会超出上下文窗口只保留最近几轮又可能丢失重要信息。我实践下来比较有效的策略是分层管理最近N轮完整保留保证对话连贯性。更早的对话压缩成摘要只保留关键信息比如用户提到的偏好、已经确认的事实。系统级信息单独维护比如用户的身份、当前任务的目标这些不随对话轮次变化。摘要的生成可以用模型来做提示词大概是“把以下对话压缩成不超过100字的摘要保留用户的关键需求和已确认的信息”。这个摘要会在每轮对话后更新。还有一个细节用户的问题可能依赖上一轮的回答。比如用户先问“什么是向量数据库”然后问“它和传统数据库有什么区别”。第二个问题里的“它”指代的是向量数据库。如果你只把第二个问题发给模型它可能不知道“它”是什么。所以组装上下文时要把指代消解掉或者把上一轮的问题也带上。4. 系统集成与评估从能跑到好用前面手写的那些组件单独看都不复杂但组装成一个完整系统之后问题就会成倍出现。这个阶段的核心任务是把系统跑通、建立评估机制、根据评估结果做优化。4.1 组装一个完整的RAG系统RAG检索增强生成是目前最常见的AI工程模式它的流程可以概括为用户提问 → 检索相关文档 → 组装上下文 → 模型生成回答。听起来简单但每个环节都有优化空间。我建议你先用一个最简版本跑通全流程不要一开始就追求完美。最简版本大概是固定长度分割文档、用现成的向量模型生成向量、用余弦相似度检索top 3、直接拼接到提示词里、调用模型生成回答。这个版本可能效果一般但能让你看到整个系统的运作方式。跑通之后再逐个环节优化。比如分割策略换成递归分割、检索数量从3调到5、加入重排序模型、优化提示词模板。每次只改一个变量观察效果变化。这样才能知道哪个环节是瓶颈。4.2 建立评估机制没有评估就没有优化这是我最想强调的一点。很多人做AI应用是“感觉驱动”的——觉得效果不好就调调提示词觉得好了就上线。但“感觉”是不可靠的你需要一套可量化的评估机制。评估分两个层面检索质量和生成质量。检索质量的评估相对客观。你可以准备一批问题每个问题标注好应该检索到哪些文档。然后计算检索结果的召回率该检索到的有没有检索到和准确率检索到的有多少是相关的。这两个指标能帮你判断检索环节的问题。生成质量的评估更复杂因为回答的好坏很难用单一指标衡量。我常用的方法有几种人工评分准备一批测试问题人工给每个回答打分比如1到5分。这是最可靠但最费时的方法。模型评分用另一个模型来给回答打分。成本低但可靠性取决于评分模型的水平。关键点覆盖对于有标准答案的问题检查回答是否覆盖了关键点。一致性检查同一个问题问多次看回答是否一致。一致性差的系统通常不可靠。我一般会建一个测试集包含20到50个典型问题覆盖不同的难度和类型。每次修改系统后都跑一遍测试集对比各项指标的变化。这个习惯看起来麻烦但能帮你避免很多“改了一个地方坏了另一个地方”的问题。实操心得测试集的问题要来自真实用户场景不要自己拍脑袋想。我通常会从线上日志里抽样或者找几个真实用户做访谈。另外测试集要定期更新因为用户的问题分布会随时间变化。4.3 常见问题的排查思路RAG系统的问题排查有一套相对固定的思路。我整理了一个速查表现象可能原因排查方法回答不相关检索结果差检查检索top_k的相似度分数回答不完整上下文被截断检查token计数和窗口设置回答有幻觉模型过度发挥加强提示词约束降低温度回答格式错提示词不明确给出明确的输出格式示例响应太慢检索或生成瓶颈分别计时定位慢的环节成本太高token消耗大统计每次调用的token量排查的基本原则是分段定位。把整个流程拆成检索、组装、生成三段分别计时和检查输出。哪一段的输出不符合预期问题就在哪一段。举个例子如果用户反馈“回答不相关”你先看检索结果。如果检索结果本身就不相关那是检索环节的问题可能是向量模型不适合、分割策略不好、或者相似度阈值设得不对。如果检索结果相关但回答不相关那是生成环节的问题可能是提示词没写好、或者模型能力不够。4.4 优化迭代的优先级当你定位到问题后优化也是有优先级的。我的经验是先优化数据再优化提示词最后优化模型。数据层面的优化包括改进分割策略、清洗低质量文档、补充缺失的知识、调整检索数量。这些优化的投入产出比通常最高因为数据质量是基础。提示词层面的优化包括调整提示结构、增加示例、明确约束条件。这些优化成本低、见效快但天花板也低。模型层面的优化包括换更大的模型、换更适合的模型、微调模型。这些优化成本高、周期长通常放在最后考虑。我见过很多人一上来就想换模型觉得模型不够强。但实际上大部分问题出在数据和提示词上。把这两个层面优化到位小模型也能有不错的效果。5. 工程化与规模化从个人项目到生产系统前面几个阶段做下来你已经有了一个能跑、能评估、能优化的AI系统。但如果要把它变成生产系统还需要解决工程化的问题怎么部署、怎么监控、怎么扩展、怎么控制成本。5.1 架构设计的关键决策生产级的AI系统和demo最大的区别在于可靠性和可扩展性。你需要考虑几个关键决策同步还是异步。模型调用通常比较慢几秒到几十秒如果同步处理用户会等很久。异步处理可以先把请求放进队列后台处理完再通知用户。但异步会增加系统复杂度需要消息队列、任务状态管理等组件。单体还是微服务。检索、生成、评估这些模块可以放在一个服务里也可以拆成独立的微服务。拆开的好处是各模块可以独立扩展和部署坏处是增加了网络开销和运维复杂度。我的建议是初期用单体等某个模块成为瓶颈时再拆。缓存策略。很多请求是重复的比如相同的文档可能被多次检索、相似的问题可能被多次提问。加缓存可以显著降低成本和延迟。缓存可以加在多个层面向量检索结果缓存、模型生成结果缓存、甚至整个请求的缓存。降级方案。模型服务可能不可用检索可能超时。你需要有降级方案比如模型不可用时返回缓存的回答、检索超时时只用最近文档。降级方案不追求完美但能保证系统不完全挂掉。5.2 监控体系的搭建没有监控的生产系统就是裸奔。AI系统的监控除了常规的CPU、内存、响应时间之外还需要关注一些特有指标token消耗每次请求的输入输出token量用于成本核算和异常检测。检索命中率检索结果中被实际使用的比例反映检索质量。回答拒绝率模型拒绝回答的比例过高说明提示词或检索有问题。用户反馈点赞、点踩、重新生成等行为是最直接的 quality signal。我一般会把这些指标打到监控面板上设置告警阈值。比如token消耗突然翻倍、检索命中率突然下降都需要及时排查。日志也很重要。每次请求的完整链路——用户问题、检索结果、组装后的上下文、模型输出——都要记录下来。出问题时可以回溯也方便后续做分析和优化。5.3 成本控制的实操技巧AI应用的成本主要来自模型调用。控制成本有几个立竿见影的方法压缩上下文。检索结果不要全塞进去只放最相关的。历史对话不要全保留做摘要压缩。提示词不要写太长去掉冗余的说明。分级处理。简单问题用便宜的小模型复杂问题才用大模型。可以先让小模型试答如果置信度低再升级到大模型。缓存复用。相同或相似的问题直接返回缓存结果。语义缓存可以用向量相似度来判断相似度超过阈值就认为可以复用。批量处理。如果场景允许把多个请求合并成一次调用。比如一次生成多个候选答案而不是多次调用。我实测下来做好上下文压缩和缓存复用成本能降一半以上。这两个是最值得优先做的。5.4 从项目到产品的最后一公里技术跑通和产品可用之间还有一段距离。这段距离里的事情往往不性感但决定了用户会不会真正用你的东西。错误处理要友好。模型超时了不要给用户看堆栈信息给一个“正在努力思考请稍候”的提示。检索失败了不要直接说“没找到”给一个兜底的回答。响应速度要感知优化。如果生成需要10秒可以先流式输出前几个字让用户知道系统在工作。或者先展示检索到的参考资料再逐步生成回答。交互设计要符合预期。用户问了一个模糊的问题不要直接拒绝可以引导用户补充信息。用户对回答不满意要提供反馈渠道和重新生成的选项。这些东西没有技术难度但需要你站在用户角度去思考。我见过很多技术很强的项目因为交互体验差而没人用。也见过技术一般但体验流畅的产品用户量很大。6. 我踩过的坑和给你的建议写了这么多最后分享几个我在这个过程中踩过的坑希望能帮你少走弯路。第一个坑过早引入框架。我一开始就用了某个流行的RAG框架结果遇到问题完全不知道从哪里排查。后来把框架拆掉自己手写了一遍才真正理解了每个环节。框架是好东西但要在你理解原理之后再用。第二个坑忽视数据质量。我曾经花了很多时间调提示词和换模型效果一直不理想。后来发现是原始文档里有大量重复和过时的内容检索出来的东西本身就是错的。清理数据之后同样的提示词和模型效果提升了一大截。第三个坑没有评估就上线。我做过一个问答系统自己测试觉得还行就上线了。结果用户问了几类我没想到的问题回答质量很差。后来补了测试集和评估机制才发现问题所在。评估机制不是锦上添花是必需品。第四个坑追求单一指标。有一段时间我特别关注回答的准确率为了提升准确率把温度调得很低。结果回答变得非常死板用户觉得像在跟机器人说话。后来才明白好的AI系统要在准确性和自然度之间找平衡不能只看一个指标。如果让我给刚入门的开发者一个建议那就是慢就是快。不要急着出效果先把基础打牢。手写一遍核心组件、建一套评估机制、跑通一个完整流程这些看起来慢但会让你后面的每一步都走得更稳。那些跳过基础直接调包的人可能在第一个demo上比你快但在第一个生产问题上就会卡住。这个方向还在快速变化新的模型、新的框架、新的方法层出不穷。但底层的东西——对数据的理解、对系统的设计、对评估的重视——是不太会变的。把这些抓住你就有能力应对上面的变化。
1. 从零搭建AI工程能力为什么我劝你别一上来就调包这两年“AI工程”这个词被说得太多了多到有点变味。打开任何一个技术社区满屏都是“三行代码调用大模型”“十分钟搭建RAG”“零基础转行AI工程师”。我不否认这些内容有它的价值但如果你真的想在这个方向上站稳脚跟光会调API是远远不够的。ai-engineering-from-scratch这个标题之所以值得认真聊恰恰是因为它戳中了一个被大多数人刻意回避的问题当框架封装越来越厚、抽象层级越来越高的时候你到底还剩下多少真正属于自己的工程能力我自己是从传统后端转过来的最早接触AI相关的东西也是从调接口开始的。那时候觉得挺爽一个HTTP请求就能拿到结果好像什么都能做。但很快问题就来了模型输出不稳定怎么办上下文窗口不够用怎么拆检索回来的内容质量差怎么调推理成本压不下来怎么优化这些问题没有一个能靠“换个更好的模型”解决它们全部指向同一个东西——你对AI系统底层运作机制的理解深度。所以这篇内容我想聊的不是某个具体框架怎么用而是一套从零开始构建AI工程能力的完整思路。它适合那些已经会写代码、但对AI系统还停留在“调包”阶段的开发者也适合那些做了几个demo但总觉得心里没底、想系统补课的人。我会把整个学习路径拆成可操作的模块每个模块都告诉你为什么要学、学到什么程度够用、以及最容易踩的坑在哪里。1.1 先搞清楚“AI工程”到底在工程什么很多人把AI工程等同于“用AI做应用”这个理解太窄了。我更喜欢一个更具体的定义AI工程是围绕模型能力构建可靠、可维护、可扩展的软件系统的过程。注意这里的几个关键词——可靠、可维护、可扩展。它们才是工程和demo之间的分水岭。一个demo只需要跑通一次就算成功但一个工程系统需要在各种边界条件下稳定运行。模型返回了意料之外的格式怎么办用户输入了超长文本怎么办并发请求把推理服务打挂了怎么办这些问题的解决方式和传统后端工程有相似之处但也有大量AI特有的挑战。从能力维度拆解AI工程至少包含这几个层面模型交互层怎么和模型有效沟通、数据处理层怎么准备和清洗训练/推理数据、系统架构层怎么组织各个组件、评估与监控层怎么知道系统好不好、优化与迭代层怎么持续改进。这五层缺一不可但大多数教程只讲了第一层。我见过太多人模型交互玩得很溜提示词写得花里胡哨但一到数据清洗就抓瞎一到系统设计就只会堆API。这就是典型的“偏科”。从零构建AI工程能力核心就是把这五层都补齐哪怕每层只到及格线也比只精通一层要强得多。1.2 学习路径的整体设计逻辑我设计的这条路径遵循一个原则先通后专先手动后自动。什么意思就是先让你用最原始的方式把整个流程跑一遍理解每个环节在干什么然后再引入框架和工具去提效。这个顺序不能反。如果你一上来就用LangChain、LlamaIndex这些框架确实能快速出效果但你会失去对底层细节的感知。等到出了问题你连从哪里开始排查都不知道。而如果你先手动实现一遍最基础的版本——比如自己写一个简单的检索系统、自己实现一个对话循环——你对整个系统的掌控力会完全不一样。具体来说我把路径分成四个阶段阶段一基础能力建设。重点是理解模型的基本工作原理、掌握提示工程的核心技巧、学会用代码直接调用模型API。这个阶段不碰任何高级框架。阶段二核心组件手写。包括文本分割、向量化、相似度检索、上下文组装、对话管理等。每个组件都先手写一个最简版本。阶段三系统集成与优化。把前面手写的组件组装成一个完整系统然后引入评估机制根据评估结果做针对性优化。阶段四工程化与规模化。引入框架提效、设计可扩展架构、建立监控体系、优化成本和延迟。每个阶段大概需要两到四周的业余时间投入整个周期下来差不多三到四个月。这个节奏不算快但每一步都走得扎实。2. 基础能力建设别急着写业务代码基础能力这个说法听起来很虚但我可以很负责任地告诉你后面所有的工程问题追根溯源都能追到基础不牢上。我见过有人花了两周调提示词最后发现是文本预处理没做好导致输入质量太差。也见过有人抱怨模型效果不行结果一看他的调用方式连基本的温度参数都没设对。2.1 模型交互的最小必要知识你不需要成为算法专家但有几件事必须搞清楚。第一是token的概念。模型不是按字或词处理的而是按token。一个中文汉字通常是1到2个token英文单词平均1.3个token左右。这个数字直接关系到你的成本计算和上下文窗口管理。我建议你在项目初期就养成习惯每次调用模型前先估算一下输入输出的token量。第二是温度、top_p这些采样参数的实际影响。温度控制的是输出的随机性温度越高输出越多样但也越容易跑偏。top_p控制的是候选词的累积概率阈值。这两个参数不需要同时调通常固定一个调另一个就行。我的经验是需要确定性输出的场景比如信息抽取、分类温度设0到0.3需要创意性输出的场景比如文案生成温度设0.7到1.0。第三是上下文窗口的管理策略。每个模型都有最大token限制超出就会报错或截断。你需要知道几种常见的处理方式直接截断简单但粗暴、滑动窗口保留最近N轮对话、摘要压缩把历史对话压缩成摘要、检索增强只把相关的内容放进上下文。这几种策略各有适用场景后面我会详细展开。注意不同模型对token的计算方式不一样中文和英文的token比例也不同。做成本估算时一定要用目标模型的实际tokenizer来算不要凭感觉。2.2 提示工程的核心不是“咒语”网上流传着大量所谓的“提示词模板”“万能咒语”说实话大部分都是噱头。提示工程的核心逻辑其实很朴素把模型当成一个能力很强但完全不了解你具体情况的实习生。你需要做的是把任务说清楚、把背景给足、把要求列明白。我总结了一个实用的提示结构叫四段式角色设定、任务描述、约束条件、输出格式。角色设定是告诉模型“你是谁”比如“你是一个资深的后端工程师”。任务描述是“你要做什么”要具体到可执行的程度。约束条件是“有什么限制”比如字数限制、不能包含的内容、必须遵循的规则。输出格式是“结果长什么样”最好给一个示例。这个结构看起来简单但实际用起来效果差异很大。关键在于任务描述和约束条件的颗粒度。举个例子“帮我写一段介绍”和“帮我写一段面向有三年经验的后端开发者的、介绍消息队列核心概念的文字不超过200字不要用比喻”就是完全不同的效果。还有一个容易被忽略的点负面指令往往不如正面指令有效。你说“不要用专业术语”模型可能还是会用但你说“用日常生活中的例子来解释”效果就好很多。因为模型在生成时是逐token预测的负面指令需要它先想到那个东西再抑制它而正面指令直接引导了生成方向。2.3 手写第一个模型调用程序这个环节我建议不要用任何框架就用最基础的HTTP请求或者官方SDK。目的是让你完整地看到一次模型调用的全貌请求怎么构造、参数怎么传、响应怎么解析、错误怎么处理。以Python为例一个最简的调用大概长这样import requests import json def call_model(prompt, temperature0.7, max_tokens1000): headers { Content-Type: application/json, Authorization: fBearer {API_KEY} } payload { model: your-model-name, messages: [{role: user, content: prompt}], temperature: temperature, max_tokens: max_tokens } response requests.post(API_ENDPOINT, headersheaders, jsonpayload) if response.status_code ! 200: raise Exception(fAPI error: {response.status_code} - {response.text}) return response.json()[choices][0][message][content]这段代码没什么技术含量但你要在这个基础上做几件事加超时处理、加重试逻辑、加token计数、加日志记录。这些才是工程化的开始。我见过太多人直接response.json()[choices][0]就完事了结果线上环境稍微有点波动就崩。实操心得重试逻辑一定要加指数退避不要固定间隔重试。我一般用2^n * base_delay的方式base_delay设1秒最多重试3次。另外要区分可重试错误和不可重试错误比如429限流可以重试401认证失败重试也没用。3. 核心组件手写把黑盒拆开看这个阶段是整个学习路径里最累但也最有价值的。你要手写文本分割、向量化、检索、上下文组装这几个核心组件。手写的目的不是让你以后都用自己写的而是让你知道每个环节的输入输出是什么、有哪些参数可以调、不同选择会导致什么差异。3.1 文本分割比你想的要讲究文本分割是RAG系统的第一步也是最容易被轻视的一步。很多人直接按固定字数切比如每500字一段。这样做的问题是一个完整的语义单元可能被切断了检索出来的内容前言不搭后语。我试过几种分割策略各有适用场景策略适用场景优点缺点固定长度结构规整的文本实现简单容易切断语义按段落文章、报告保留语义完整段落长度不均递归分割混合结构文档平衡语义和长度实现稍复杂语义分割高质量要求场景语义最完整计算成本高我一般推荐递归分割作为默认策略。它的逻辑是先尝试按段落分如果某段太长就按句子分如果句子还太长就按固定长度分。这样能在语义完整和长度可控之间取得平衡。手写一个递归分割器大概需要50行代码核心是一个递归函数不断用更细粒度的分隔符去切分超长的块。这里有个细节块之间要保留一定的重叠通常10%到20%。重叠的目的是防止关键信息刚好落在切割边界上被丢掉。def recursive_split(text, max_length500, overlap50): separators [\n\n, \n, 。, , , ., , ] chunks [] def _split(t, sep_idx): if len(t) max_length or sep_idx len(separators): return [t] sep separators[sep_idx] parts t.split(sep) result [] current for part in parts: if len(current) len(part) len(sep) max_length: current part sep else: if current: result.append(current) current part sep if current: result.append(current) # 对超长的部分继续递归 final [] for r in result: if len(r) max_length: final.extend(_split(r, sep_idx 1)) else: final.append(r) return final chunks _split(text, 0) # 添加重叠 overlapped [] for i, chunk in enumerate(chunks): if i 0: prev chunks[i-1] overlap_text prev[-overlap:] if len(prev) overlap else prev overlapped.append(overlap_text chunk) else: overlapped.append(chunk) return overlapped这段代码不完美但足够让你理解分割的核心逻辑。实际生产中你可能会用现成的库但手写过一遍之后你就知道那些库的参数该怎么调了。3.2 向量化与相似度检索理解原理才能调好参数向量化就是把文本变成一串数字向量使得语义相近的文本在向量空间里的距离也相近。这个“距离”通常用余弦相似度来衡量。你不需要自己训练向量模型但需要知道几个关键点。第一不同的向量模型适合不同的场景。有的模型擅长中文有的擅长英文有的在多语言场景下表现好。选择的时候要看你的实际数据是什么语言、什么领域。通用模型在专业领域比如医疗、法律上的表现可能不如领域微调过的模型。第二向量维度影响存储和检索效率。常见的维度有768、1024、1536等。维度越高表达能力越强但存储成本和计算成本也越高。对于大多数应用场景1024维已经足够。第三相似度检索不一定是精确的。当你的文档库很大时比如几十万个块精确计算每个块的相似度会非常慢。这时候需要用近似最近邻ANN算法比如HNSW、IVF。这些算法用一定的精度损失换取速度提升。手写一个最简的向量检索系统其实不难import numpy as np class SimpleVectorStore: def __init__(self): self.vectors [] self.texts [] def add(self, text, vector): self.vectors.append(vector) self.texts.append(text) def search(self, query_vector, top_k5): if not self.vectors: return [] vectors np.array(self.vectors) query np.array(query_vector) # 余弦相似度 similarities np.dot(vectors, query) / ( np.linalg.norm(vectors, axis1) * np.linalg.norm(query) ) top_indices np.argsort(similarities)[-top_k:][::-1] return [(self.texts[i], similarities[i]) for i in top_indices]这个实现是O(n)的复杂度文档量大了会慢但用来理解原理足够了。你可以在这个基础上加索引、加缓存、加过滤条件逐步优化。踩过的坑余弦相似度对向量的模长不敏感但有些向量模型输出的向量模长差异很大。如果你发现检索结果不稳定可以先对向量做归一化再计算相似度。另外查询向量和文档向量最好用同一个模型生成混用不同模型的向量是没有意义的。3.3 上下文组装把正确的信息放在正确的位置检索到了相关文档怎么把它们和用户问题一起塞进模型的上下文窗口这里面也有讲究。我总结了几条经验位置很重要。模型对上下文开头和结尾的信息关注度更高中间部分容易被忽略。所以最重要的信息应该放在开头或结尾。我通常把最相关的检索结果放在用户问题之前次相关的放在之后。数量要控制。不是检索结果越多越好。太多无关信息会稀释关键信息还会增加token消耗。我一般检索top 5到top 10然后根据实际效果调整。格式要清晰。检索结果和用户问题之间要有明确的分隔让模型知道哪些是参考资料、哪些是问题。我习惯用这样的格式参考资料 [1] {文档1内容} [2] {文档2内容} ... 用户问题{问题}要处理冲突。如果检索到的多个文档之间有矛盾模型可能会困惑。这时候要么在提示词里说明“如果资料有冲突以最新的为准”要么在检索阶段就做去重和排序。3.4 对话管理多轮对话的状态维护单轮问答相对简单多轮对话就复杂了。核心问题是历史对话怎么处理全部保留会超出上下文窗口只保留最近几轮又可能丢失重要信息。我实践下来比较有效的策略是分层管理最近N轮完整保留保证对话连贯性。更早的对话压缩成摘要只保留关键信息比如用户提到的偏好、已经确认的事实。系统级信息单独维护比如用户的身份、当前任务的目标这些不随对话轮次变化。摘要的生成可以用模型来做提示词大概是“把以下对话压缩成不超过100字的摘要保留用户的关键需求和已确认的信息”。这个摘要会在每轮对话后更新。还有一个细节用户的问题可能依赖上一轮的回答。比如用户先问“什么是向量数据库”然后问“它和传统数据库有什么区别”。第二个问题里的“它”指代的是向量数据库。如果你只把第二个问题发给模型它可能不知道“它”是什么。所以组装上下文时要把指代消解掉或者把上一轮的问题也带上。4. 系统集成与评估从能跑到好用前面手写的那些组件单独看都不复杂但组装成一个完整系统之后问题就会成倍出现。这个阶段的核心任务是把系统跑通、建立评估机制、根据评估结果做优化。4.1 组装一个完整的RAG系统RAG检索增强生成是目前最常见的AI工程模式它的流程可以概括为用户提问 → 检索相关文档 → 组装上下文 → 模型生成回答。听起来简单但每个环节都有优化空间。我建议你先用一个最简版本跑通全流程不要一开始就追求完美。最简版本大概是固定长度分割文档、用现成的向量模型生成向量、用余弦相似度检索top 3、直接拼接到提示词里、调用模型生成回答。这个版本可能效果一般但能让你看到整个系统的运作方式。跑通之后再逐个环节优化。比如分割策略换成递归分割、检索数量从3调到5、加入重排序模型、优化提示词模板。每次只改一个变量观察效果变化。这样才能知道哪个环节是瓶颈。4.2 建立评估机制没有评估就没有优化这是我最想强调的一点。很多人做AI应用是“感觉驱动”的——觉得效果不好就调调提示词觉得好了就上线。但“感觉”是不可靠的你需要一套可量化的评估机制。评估分两个层面检索质量和生成质量。检索质量的评估相对客观。你可以准备一批问题每个问题标注好应该检索到哪些文档。然后计算检索结果的召回率该检索到的有没有检索到和准确率检索到的有多少是相关的。这两个指标能帮你判断检索环节的问题。生成质量的评估更复杂因为回答的好坏很难用单一指标衡量。我常用的方法有几种人工评分准备一批测试问题人工给每个回答打分比如1到5分。这是最可靠但最费时的方法。模型评分用另一个模型来给回答打分。成本低但可靠性取决于评分模型的水平。关键点覆盖对于有标准答案的问题检查回答是否覆盖了关键点。一致性检查同一个问题问多次看回答是否一致。一致性差的系统通常不可靠。我一般会建一个测试集包含20到50个典型问题覆盖不同的难度和类型。每次修改系统后都跑一遍测试集对比各项指标的变化。这个习惯看起来麻烦但能帮你避免很多“改了一个地方坏了另一个地方”的问题。实操心得测试集的问题要来自真实用户场景不要自己拍脑袋想。我通常会从线上日志里抽样或者找几个真实用户做访谈。另外测试集要定期更新因为用户的问题分布会随时间变化。4.3 常见问题的排查思路RAG系统的问题排查有一套相对固定的思路。我整理了一个速查表现象可能原因排查方法回答不相关检索结果差检查检索top_k的相似度分数回答不完整上下文被截断检查token计数和窗口设置回答有幻觉模型过度发挥加强提示词约束降低温度回答格式错提示词不明确给出明确的输出格式示例响应太慢检索或生成瓶颈分别计时定位慢的环节成本太高token消耗大统计每次调用的token量排查的基本原则是分段定位。把整个流程拆成检索、组装、生成三段分别计时和检查输出。哪一段的输出不符合预期问题就在哪一段。举个例子如果用户反馈“回答不相关”你先看检索结果。如果检索结果本身就不相关那是检索环节的问题可能是向量模型不适合、分割策略不好、或者相似度阈值设得不对。如果检索结果相关但回答不相关那是生成环节的问题可能是提示词没写好、或者模型能力不够。4.4 优化迭代的优先级当你定位到问题后优化也是有优先级的。我的经验是先优化数据再优化提示词最后优化模型。数据层面的优化包括改进分割策略、清洗低质量文档、补充缺失的知识、调整检索数量。这些优化的投入产出比通常最高因为数据质量是基础。提示词层面的优化包括调整提示结构、增加示例、明确约束条件。这些优化成本低、见效快但天花板也低。模型层面的优化包括换更大的模型、换更适合的模型、微调模型。这些优化成本高、周期长通常放在最后考虑。我见过很多人一上来就想换模型觉得模型不够强。但实际上大部分问题出在数据和提示词上。把这两个层面优化到位小模型也能有不错的效果。5. 工程化与规模化从个人项目到生产系统前面几个阶段做下来你已经有了一个能跑、能评估、能优化的AI系统。但如果要把它变成生产系统还需要解决工程化的问题怎么部署、怎么监控、怎么扩展、怎么控制成本。5.1 架构设计的关键决策生产级的AI系统和demo最大的区别在于可靠性和可扩展性。你需要考虑几个关键决策同步还是异步。模型调用通常比较慢几秒到几十秒如果同步处理用户会等很久。异步处理可以先把请求放进队列后台处理完再通知用户。但异步会增加系统复杂度需要消息队列、任务状态管理等组件。单体还是微服务。检索、生成、评估这些模块可以放在一个服务里也可以拆成独立的微服务。拆开的好处是各模块可以独立扩展和部署坏处是增加了网络开销和运维复杂度。我的建议是初期用单体等某个模块成为瓶颈时再拆。缓存策略。很多请求是重复的比如相同的文档可能被多次检索、相似的问题可能被多次提问。加缓存可以显著降低成本和延迟。缓存可以加在多个层面向量检索结果缓存、模型生成结果缓存、甚至整个请求的缓存。降级方案。模型服务可能不可用检索可能超时。你需要有降级方案比如模型不可用时返回缓存的回答、检索超时时只用最近文档。降级方案不追求完美但能保证系统不完全挂掉。5.2 监控体系的搭建没有监控的生产系统就是裸奔。AI系统的监控除了常规的CPU、内存、响应时间之外还需要关注一些特有指标token消耗每次请求的输入输出token量用于成本核算和异常检测。检索命中率检索结果中被实际使用的比例反映检索质量。回答拒绝率模型拒绝回答的比例过高说明提示词或检索有问题。用户反馈点赞、点踩、重新生成等行为是最直接的 quality signal。我一般会把这些指标打到监控面板上设置告警阈值。比如token消耗突然翻倍、检索命中率突然下降都需要及时排查。日志也很重要。每次请求的完整链路——用户问题、检索结果、组装后的上下文、模型输出——都要记录下来。出问题时可以回溯也方便后续做分析和优化。5.3 成本控制的实操技巧AI应用的成本主要来自模型调用。控制成本有几个立竿见影的方法压缩上下文。检索结果不要全塞进去只放最相关的。历史对话不要全保留做摘要压缩。提示词不要写太长去掉冗余的说明。分级处理。简单问题用便宜的小模型复杂问题才用大模型。可以先让小模型试答如果置信度低再升级到大模型。缓存复用。相同或相似的问题直接返回缓存结果。语义缓存可以用向量相似度来判断相似度超过阈值就认为可以复用。批量处理。如果场景允许把多个请求合并成一次调用。比如一次生成多个候选答案而不是多次调用。我实测下来做好上下文压缩和缓存复用成本能降一半以上。这两个是最值得优先做的。5.4 从项目到产品的最后一公里技术跑通和产品可用之间还有一段距离。这段距离里的事情往往不性感但决定了用户会不会真正用你的东西。错误处理要友好。模型超时了不要给用户看堆栈信息给一个“正在努力思考请稍候”的提示。检索失败了不要直接说“没找到”给一个兜底的回答。响应速度要感知优化。如果生成需要10秒可以先流式输出前几个字让用户知道系统在工作。或者先展示检索到的参考资料再逐步生成回答。交互设计要符合预期。用户问了一个模糊的问题不要直接拒绝可以引导用户补充信息。用户对回答不满意要提供反馈渠道和重新生成的选项。这些东西没有技术难度但需要你站在用户角度去思考。我见过很多技术很强的项目因为交互体验差而没人用。也见过技术一般但体验流畅的产品用户量很大。6. 我踩过的坑和给你的建议写了这么多最后分享几个我在这个过程中踩过的坑希望能帮你少走弯路。第一个坑过早引入框架。我一开始就用了某个流行的RAG框架结果遇到问题完全不知道从哪里排查。后来把框架拆掉自己手写了一遍才真正理解了每个环节。框架是好东西但要在你理解原理之后再用。第二个坑忽视数据质量。我曾经花了很多时间调提示词和换模型效果一直不理想。后来发现是原始文档里有大量重复和过时的内容检索出来的东西本身就是错的。清理数据之后同样的提示词和模型效果提升了一大截。第三个坑没有评估就上线。我做过一个问答系统自己测试觉得还行就上线了。结果用户问了几类我没想到的问题回答质量很差。后来补了测试集和评估机制才发现问题所在。评估机制不是锦上添花是必需品。第四个坑追求单一指标。有一段时间我特别关注回答的准确率为了提升准确率把温度调得很低。结果回答变得非常死板用户觉得像在跟机器人说话。后来才明白好的AI系统要在准确性和自然度之间找平衡不能只看一个指标。如果让我给刚入门的开发者一个建议那就是慢就是快。不要急着出效果先把基础打牢。手写一遍核心组件、建一套评估机制、跑通一个完整流程这些看起来慢但会让你后面的每一步都走得更稳。那些跳过基础直接调包的人可能在第一个demo上比你快但在第一个生产问题上就会卡住。这个方向还在快速变化新的模型、新的框架、新的方法层出不穷。但底层的东西——对数据的理解、对系统的设计、对评估的重视——是不太会变的。把这些抓住你就有能力应对上面的变化。
