1. 从零开始先想清楚“AI工程”到底解决什么问题市面上聊 AI 工程的内容很多但真正顺着“ai-engineering-from-scratch”这个思路走下去的人往往会先踩一个坑把“从零开始”理解成从线性代数补起从反向传播推导做起从训练 GPT 那样的模型做起。这个方向不是不对但绝大多数人的真实处境是——模型能力已经够用缺的是把模型接进业务流、让它稳定产出价值的那一层工程体系。我自己带过不少团队也见过很多做算法的同学转做应用最明显的一个认知差是AI 工程的核心不是“发明模型”而是在已经存在的模型能力之上做一套可靠的输入输出闭环。你要处理的是数据怎么进、知识怎么存、上下文怎么组装、结果怎么校验、错了怎么兜底、请求怎么压住成本。这一整套东西才是“from scratch”真正要搭的骨架。那这篇内容就围绕这个骨架来展开。适合三类人看一是传统后端或前端工程师想进入 AI 应用开发二是算法工程师想从“跑通 notebook”走向“上线服务”三是技术负责人需要评估一条从零搭建 AI 能力的可行路径。内容里会给出选型思路、可执行的落地步骤、参数设置的逻辑以及我实际踩过的坑。我不写那些花哨的“十分钟搭建智能客服”的爽文只写那些真正决定项目生死的关键判断。1.1 先纠偏AI 工程不是“模型调包工程”先泼一盆冷水。很多人以为 AI 工程就是从 HuggingFace 上拉一个模型或者调用一下大模型 API然后把 prompt 写得好看一点就完事了。这个理解放到 demo 场景没问题放到生产环境会死得很惨。我做一个不太严谨但很直观的类比模型本身像一个刚毕业、基础素质很强的员工他什么都懂一点但你不告诉他公司流程、不给他资料库、不设定质量标准、不安排复核机制他交出来的活就一定不稳定。AI 工程做的就是把他入职之后的管理体系搭起来岗位说明书系统提示词、资料库检索增强、作业流程工作流编排、质检标准评测与校验、应急预案降级与兜底。换句话说技术再强没有工程约束就是不可控。而不可控在技术项目里是原罪。另外一个常见的误解是把“从零开始”等同于不用开源框架。其实真正的从零是从问题出发从业务需要出发去选择你需要的组件。如果 LangChain、LlamaIndex 这类现成的编排工具能用那就用如果它们太重、太黑盒那你就自己写一个几十行的检索脚本。关键是理解每一层的原理而不是被工具绑架。这是我反复强调的一句话框架只是手段链路才是核心。1.2 以终为始先定评估标准再选技术路线很多项目做砸了不是模型不行是从头到尾没有定义过“什么叫行”。你在做一个 AI 问答系统你先搞清楚用户问什么类型的问题哪些问题必须答对答案允许有多大的偏差一次回答的耗时上限是多少单次成本预算是多少这些问题没答案之前一切技术选型都是瞎选。我记得有一个做法律咨询机器人的项目初期团队把精力全放在调 prompt 上结果每次演示都翻车。后来拉齐需求才发现用户最关心的根本不是回答多“聪明”而是引用法条必须真实。这是一个完全不同的技术问题——它要求系统优先保证检索质量而不是生成质量。于是我们直接把方案改成了“强检索 弱生成”甚至在某些高优场景下只返回法条原文不做任何加工。所以整篇内容如果你只能记住一句话我希望是这句话先定义评价指标再去做模型和链路选型。后面所有实操环节我都会反复用这个原则来审视。2. 技术栈怎么选模型、存储、向量检索与编排框架技术选型这件事看起来是选择一个模型、选一个框架实际上是在选择你未来三到六个月的维护成本。我见过太多团队把 demo 跑通之后发现换不了组件只能硬着头皮在错误的技术栈上继续堆功能。所以这部分我把选型逻辑拆成四个层面每个层面给出一套可执行的选择标准。2.1 模型层别只看榜单要看你的场景选模型的第一个原则是“场景决定口径”。如果做的是开放域闲聊或者创意写作那么大模型本身的能力就是第一位你需要 GPT、Claude、国产的 DeepSeek、Kimi、通义这类闭源或开源大模型的通用能力如果做的是垂直领域的抽取、分类、结构化信息处理那不妨尝试中小型模型比如各类 7B、14B 的微调模型因为任务单一、输出可控、成本也低。第二个原则是“所有模型都要过一遍你的私有测试集”。我不会因为某个模型在公开榜单上排得高就直接拿进业务榜单上都是通用任务你的业务是特定任务。最靠谱的做法是准备 50 到 100 条真实业务问题跑一遍模型人工标注满意度不达标就换。注意这 50 到 100 条问题之后还要留着每换一次模型、每改一次 prompt 都用同一套题来测这样才有对比价值。第三个原则是“大模型 小模型混用”。我目前做过的项目里几乎没有只用一个模型的情况。典型架构是用一个大模型做核心生成或复杂推理用一个或多个小模型做路由判断用户问题属于什么类型、做分类打标签、做实体抽取、做安全过滤。这种混用有两个好处一是高成本的大模型调用量被压缩到最低二是小模型返回速度快、结果稳定用户基础体验更好。2.2 数据层别小看“一点点数据”的治理成本数据决定效果这句话在 AI 应用里尤其突出。你需要考虑的数据至少有三类第一类是结构化业务数据比如用户信息、订单信息、商品信息通常存在关系型数据库里这一类通过接口或数据库查询直接获取一般不需要走 AI 链路。第二类是非结构化知识数据比如 PDF 文档、网页内容、制度文件、产品手册这些才是 RAG 系统要处理的原材料。第三类是对话历史与行为日志它们不直接参与生成但对个性化、记忆能力、后续评测优化都非常关键。这里我特别想强调一下非结构化数据的治理难度。大多数团队以为 RAG 就是把 PDF 切一切、灌进向量库但实际上你首先得做“清洗”PDF 里很多是扫描件要 OCRPPT 里的信息大量在图里要图文识别网页里有大量导航、广告、杂讯要先提取正文。清洗质量直接决定后续切分和检索效果这一步偷懒后面全在填坑。我在项目里通常按“清洗 → 结构化 → 切分 → 向量化 → 入库”这五步来处理知识数据每一步都有可量化的质量检查点。比如清洗完成后抽查 10 个文件的人工可读性切分完成后检查是否有断句或者语义割裂的情况。2.3 检索层向量检索不是银弹混合检索才稳很多新手做 RAG 的第一个误区是以为把文档切碎变成向量然后用余弦相似度一搜就完事了。但实际生产里纯向量检索有很明显的两个问题一是精确关键词匹配能力弱你搜“手机”可能搜出一堆“移动设备”看起来相关但用户不买账二是对短文本和专有名词很不友好比如产品型号“A/B/C-2000”这种词向量化之后往往被语义拆得稀碎。目前比较稳健的做法是混合检索同时跑关键词检索BM25 或者干脆用数据库自带的全文索引和向量检索然后做结果融合。融合的方式有很多简单一点的可以加权排序复杂一点可以用 RRF倒数排名融合基本公式是score w1 * 向量相似度评分 w2 * BM25评分或者用 RRF 的方式把两个列表的排名倒数和相加取 top K。我实际用下来RRF 对参数不敏感、实现简单而且效果通常不差适合作为第一版方案。后续如果想要更高精度可以再引入重排序模型reranker把前 50 名的结果重新精排一遍准确率会有明显提升当然也会带来额外的延迟和推理成本。另外一个容易忽略的点是切分策略。切得太碎上下文语义不完整切得太大检索噪音太多、还可能超出模型上下文窗口。我常用的策略是“按结构切分 滑动窗口 上下文补全”优先按 markdown 标题、PDF 章节切块块内内容如果超过阈值再按段落拆并且每一块额外保留标题路径和前后文摘要这样检索到某一块时模型有足够的上下文理解它到底在说什么。2.4 服务层编排、API 网关、可观测性与成本控制服务层解决的是“模型和检索能力如何变成产品功能”的问题。这里我给一个最小可用的模块清单API 网关统一转发模型请求统一做限流、鉴权、计量。很多团队直接把各家云厂商的 SDK 嵌到业务代码里后续想换模型恨不得把所有代码翻一遍。缓存层对同样的用户问题先查缓存命中就直接返回。这听起来很简单但实际很多团队上线第一天就把这个环节忘了回头一看账单大半请求都在重复问答同样的问题。可观测性把每一次请求的“输入内容、检索命中文档、模型输出、耗时、花费、人工反馈”都记录下来。没有这个日志体系你后面根本没法做评测和迭代只能凭感觉调参数。降级策略模型服务超时了怎么办解析结果异常怎么办检索结果为空怎么办每一层都要有兜底动作。我通常会在模型出现连续失败时降级为“只返回检索摘要”不做生成式扩写至少用户拿到的是有出处的内容。关于编排框架LangChain、LlamaIndex、Semantic Kernel 这些我都有不同程度的使用。我的建议是能用原生代码搞定的就别上框架框架只在你需要复杂 Agent 循环或大量预置组件时才有价值。因为框架的抽象层很厚出了问题你排查链路极慢。很多项目用着 LangChain最后 debug 起来每个 callback 都是一层迷雾生产环境我很谨慎。3. 零基础搭建一个 RAG 问答服务从数据到上线的完整路径看再多的“技术选型”不如完整跑通一遍最小系统。这一节我会用一个最常见的场景——公司内部知识库问答系统——把整个搭建过程走一遍。这个场景覆盖了 AI 工程中最典型的基础能力数据治理、向量检索、生成链路、上线监控。你把它跑通了其他场景都是换汤不换药。3.1 准备阶段划定数据边界明确问答范围先别急着写代码你要先回答三个问题第一系统回答什么范围的问题超出范围的问题怎么处理第二知识数据从哪里来格式有哪些谁负责定期更新第三回答做不到 100% 准确时可接受的下限是什么就拿内部知识库问答来说你可以把范围定义为“行政制度、IT 支持、人事流程”三类问题。超出范围时系统应该回答“这个问题不在我能处理的范围内建议联系行政/IT/人事部门”而不是强行编造一个答案。这个简单设定看起来不起眼却能避免 90% 的“AI 胡说八道”带来的信任危机。数据层面你需要找到这些问题的制度文档源把它统一放到一个目录里转成纯文本或 markdown。如果源文件是 PDF你可能需要脚本批量转换并人工抽查转换质量。如果是网页你需要写个爬虫抓取正文并去掉导航和页脚。3.2 切分与向量化决定检索质量的前两步切分的核心目标是“让每一块内容尽量自包含”。我直接用 markdown 文档来举例先按一级标题、二级标题把文档切成大块然后对每个大块做长度检查。假设你的 embedding 模型是 512 token 上限比如同一个模型内部处理的语义粒度切分阈值设为 400 token超过就继续切切出来的块如果语义不完整就把上一段结尾的几句补进来。这一步的代码很简单用 Python 的 markdown 解析库就能实现。核心逻辑如下def split_markdown_by_heading(text, max_len400): blocks [] current_section current_heading for line in text.splitlines(): if line.startswith(#): # 标题出现保存上一段 if current_section: blocks.append({heading: current_heading, content: current_section.strip()}) current_heading line.lstrip(#).strip() current_section else: current_section line \n # 超长时按段落继续切分 if len(current_section) max_len: # 按句号或换行切分并保证最小长度 ... return blocks实际项目里不用写这么底层你可以用现成的 MarkdownHeaderTextSplitter 或 RecursiveCharacterTextSplitter但你要理解它背后就是“按标题分组再按长度切分”。切分完之后把每一块做 embedding 向量化然后存入向量数据库。向量库的选择方面如果数据量很小几千条直接用 SQLite 加上一个向量检索库就能跑数据量到了百万级再上专门的向量数据库比如 Qdrant、Milvus、Weaviate。起步阶段不建议上重型的分布式向量库运维成本高、收益不明显。3.3 检索链路从用户问题到召回上下文这一步是整个 RAG 的胜负手。我直接给出一个典型的检索代码逻辑从“用户提问”到“获得上下文”一共四步生成问题向量、混合检索、重排序、组装上下文。def retrieve_context(question, top_k8): # 1. 生成问题向量 question_vector embedding_model.encode(question) # 2. 混合检索向量 关键词 vector_hits vector_db.search(question_vector, top_ktop_k) keyword_hits keyword_index.search(question, top_ktop_k) # 3. 使用 RRF 融合两个结果集 fused reciprocal_rank_fusion(vector_hits, keyword_hits, k60) # 4. 过滤低相关结果阈值卡控 filtered [hit for hit in fused if hit.score 0.35] # 5. 按上下文窗口长度截断 context_text assemble_context(filtered, max_tokens3000) return context_text这一步有几个参数很重要top_k 决定了检索多少块一般 4 到 10 之间不要贪多多了会引入噪音过滤阈值决定了多不相关的块进上下文这个值需要你在真实数据上调我常用的技巧是先跑一批问题看召回分数的分布再选一个能挡住明显不相关内容的值。强调一点检索结果的可解释性必须做。也就是每次回答都要能回看是哪些文档块支撑了答案。这个能力上线后极其重要用户或运营对回答有疑问时你得能拿出“证据”来。没有这个东西你就无法定位是检索错还是生成错。3.4 生成链路设计好系统提示词把“证据”交给模型检索得到上下文之后生成环节其实是一个受限的写作任务。系统提示词的核心目的不是展现模型能力而是限制模型行为。我的模板通常长这样你是一个企业内部知识库的问答助手。请严格基于以下参考资料回答用户问题。 规则 1. 如果参考资料中没有明确依据请直接回答“资料库中没有找到相关信息”。 2. 回答时在句末标注参考来源编号格式为【来源1】。 3. 不要编造事实不要补充资料之外的推断。 4. 使用简洁、正式的书面语回答控制在200字以内。 参考资料 【来源1】行政管理制度-休假申请流程 【来源2】IT支持常见问题-账号开通这里“不要编造事实”在 prompt 里看起来是句废话但它是在给模型一个明确的行动边界。真正起作用的其实是两件事一是你把相关性不高的内容过滤掉了模型没有发挥空间二是你明确要求了“没有依据就说没有”。至于模型自身的温度参数问答类场景我建议设置在 0.1 到 0.3 之间温度太高会增加随机性问答类场景不需要创造性。同理top_p 也建议控制在 0.9 以下。还有一个经常被忽略的问题上下文窗口溢出。你检索了 8 个文档块每块 400 token加起来 3200 token再加上系统提示词和问题总共约 4000 token。如果你用的是 8K 窗口的模型还扛得住如果是 4K 窗口就得重新审视切分和 top_k 设置。不要以为上下文越大越好过长的上下文反而会稀释模型的注意力导致它抓不住重点。3.5 评测闭环用一套测试题持续盯住两个数字很多项目在“跑通”之后就宣告胜利然后上线两周开始被用户吐槽。原因就是没有做评测闭环。我强烈建议上线之前就建一套评测集哪怕只有 50 条问答对每个问答对标注好标准答案和可接受回答范围。每周跑一次回归看两个指标检索召回准确率正确答案有没有被召回。生成答案接受率模型基于召回的上下文能否产出满意答案。这两个指标分开看非常重要。如果前者高、后者低问题出在 prompt 或模型选型如果前者低你再怎么调 prompt 都没用根子在切分策略或检索参数上。很多团队只盯最终回答好不好出了问题就盲目调 prompt结果一直绕圈。评测的方式可以人工抽样也可以用大模型当裁判LLM-as-judge。我建议前期以人工为主模型评测为辅。你需要在项目里提前沉淀一套标注平台或简单的标注脚本这个团队内部写一个小工具就行别等数据多了再临时搭。3.6 上线部署服务化、缓存、监控一个都不能少本地跑通之后把服务封装成 API 是相对标准化的动作。这里我给出一个生产可用的服务拆分建议业务 API 服务接收用户请求做身份认证、频控、调用检索与生成链路。检索服务独立部署也可以放在同一个进程里但数据量大时一定要拆开因为向量检索是资源消耗大户。模型代理服务统一封装各家模型 API。好处是换模型厂商时只改一处配置也能做服务超时、重试、降级。任务队列对耗时的分析类或批量处理类任务先用队列接住不要让用户请求长时间阻塞。还要做缓存。最简单的做法是用 Redis 对用户问题做哈希计算一个向量和回答结果命中就直接返回。这里有个技巧相似问题也能命中。你可以把用户问题的向量也缓存起来查询时先算向量相似度如果命中高相似历史问题直接复用回答。这个优化能把回答延迟从 2 秒降到几十毫秒成本也能降下来。监控方面至少要看四个指标调用量、平均延迟、token 消耗、错误率。进一步的话要对每次回答做人工反馈打点。只有把监控埋好你才能知道系统当前是否健康才知道每一次变更到底是变好还是变坏。4. 实战中高频踩坑检索差、乱编、延迟和成本失控这一节把我自己和身边同行在 AI 工程落地里遇到最多的四类问题拿出来做一个快速排查速查。每个问题我都会给排查思路和解决优先度你可以直接对着抄。4.1 检索质量差召回了一大堆噪音答案自然像“缝合怪”现象最典型用户问“年假怎么申请”系统回答里却出现了“春节放假通知”“考勤补卡流程”看起来沾边但不解决核心问题。排查步骤按顺序来第一步看切分粒度。如果切分太粗一个块里混了多个主题检索时就会被整体召回噪声极大第二步看过滤阈值。如果你没有设阈值低相关块也会进入上下文模型就容易被带偏第三步看混合检索配比。如果纯向量检索效果不好加上关键词检索通常能明显改善。我在实践中发现真正让检索质量发生质变的不是模型换大而是搜索策略变细。我建议优先做“标题路径补充”如果你在切分时把每个文档块挂上它的层级标题路径比如“人事制度 休假管理 请假流程”检索生成的时候连同路径一起给模型模型对内容的定位会准确很多。这个小改动在很多项目上都带来了 10% 以上的准确率提升。4.2 模型一本正经地胡说八道路径问答系统最伤害信任的就是编造答案。哪怕你已经在 prompt 里写了“不要编造”模型还是会在资料缺失时按照训练时的记忆补一个“看起来合理”的答案。我的排查优先级是第一检查召回内容是否覆盖了答案所需的信息。可以把每次回答的检索片段打印出来看如果片段里根本没有答案那模型一定在编。第二检查 system prompt 里是否有强制约束。光说“不要编造”还不够更好的说法是“你只能从参考资料中提取信息参考资料没有提到就回答不知道”。第三在后处理层加入一个简单的校验对模型输出做关键词匹配看回答中是否有与参考资料无关的明显实体出现如果有就拒绝输出并提示“资料不足”。说到底模型生成的能力上限摆在那里你不可能在 prompt 层面完全消灭幻觉。工程上的解法就是把生成权限收窄甚至在某些高优场景只做摘要式输出不做自由式生成。这和我们前面提到的“先定义评估标准”是一脉相承的——如果准确率是第一指标那宁可答得少也不能答错。4.3 延迟居高不下用户等不了两秒以上怎么办AI 服务的延迟主要来自四个环节模型推理、检索、网络传输、后处理。排查时逐个打点计时看卡在哪里。模型推理延迟是最主要的部分。在大模型不可换的情况下常用的优化手段是输出长度限制max_tokens、批量请求合并、流式输出可以让用户感知上更快。如果你的链路里加了重排序模型注意这一步也可能增加几十到几百毫秒非必要时可以先去掉。检索侧的延迟通常是向量查询引起的可以通过控制 top_k、建立索引分区来缓解。延迟优化的优先级应该和业务场景挂钩。智能客服这类交互式场景1.5 秒以内是及格线内容审核、数据分析等异步场景几秒甚至几十秒都可以接受。不要为了优化而优化先问问业务能不能接受。4.4 成本失控一次回答几毛钱月账单吓死人成本问题在 RAG 项目里通常有三个大坑第一输入太长。你每次调用模型把一堆检索片段全塞进去token 费用是输出的好几倍第二没有缓存。相同或相似问题反复调用模型第三没有做模型分级。所有请求都走最强模型其实很多简单问题用一个便宜的小模型就能解决。节省成本的实操建议一是入口处做意图路由简单分类问题直接走模板回答或小模型二是对检索片段做摘要压缩大模型不需要的上下文就不要进三是缓存相似问题能复用就复用四是选择合适的按量或包周期套餐而不是固定用一个价格档。5. 项目复盘后的几个关键认知走到这里你已经有了一个从零搭建 AI 应用的基本框架定义评估标准、选型、数据治理、检索、生成、评测、上线、监控。但最后我还想说几个项目复盘时才会有的体会。第一AI 工程里最贵的是迭代时间不是模型费用。如果你上线前没有评测集、没有可观测性那你每次改动都在盲试一版一版堆下来消耗的团队时间远超几万块的 API 费用。所以不管项目多小第一件事就是把评测集和日志建起来。第二越到后期工程问题越比算法问题多。模型能力不够你可以换但数据脏、接口不稳定、缓存命中率低、标注口径不一这些问题是持续的。团队里如果没有一个真正懂工程化的人在盯这些事项目大概率会烂在一半。第三从零开始不代表一切从最底层开始。借用开源模型、云服务、成熟的向量库都是正当选择。真正的“从零”是指你理解每一层在做什么、为什么这么做而不是单纯把所有组件堆在一起。你理解链路才谈得上优化。第四做完第一个 RAG 应用只是起点。当你熟悉了这套“检索 生成 评测”的打法之后Agent、工具调用、多轮记忆、意图路由都是在它基础上的延伸。把地基打稳后面加什么功能都不会飘。如果你现在正准备动手做一个 AI 项目我建议按这个顺序行动先拿 30 分钟定义评价指标再花一天梳理数据和选型然后用一周做出第一个最小闭环最后花额外一周补上评测和监控。走完这一轮你对 AI 工程的理解会比看十篇教程都要深。