企业官网建设流程全解析

“ai-engineering-from-scratch”这个标题我第一次看到时，脑子里冒出来的画面不是某个算法公式，而是一张很长的待办清单：模型接入、提示词调优、知识库切片、召回评估、接口并发、成本监控、数据回流。如果你也正处于“模型能跑通，但一上生产就翻车”的阶段，这个项目名指的就是那条从原型到系统的路。它不是教你重新推导 Transformer，也不是让你背一遍机器学习教材，而是把 AI 工程化拆解成一系列可以动手、可以验证、可以迭代的实操环节。

这篇文章我会从工程落地的角度，把这套从零开始的方法论拆开讲清楚：先说 AI 工程和传统后端的本质差异，再给一套具体的工具链和系统骨架，然后完整走一遍“七天做出一个可用 AI 应用”的实操路径，最后把我在这个过程中反复踩过的坑和排查思路整理出来。适合正在做 AI 应用开发、想从普通后端转 AI 应用方向、或者已经在做 RAG 但觉得效果不稳定的朋友，读完你至少能少走两个月的弯路。

1. AI 工程化到底在解决什么问题

1.1 从“模型能跑”到“系统可靠”：差的不是算法

很多人的 AI 应用起步于一段调用模型的脚本：把用户问题拼进 prompt，拿到返回结果，然后展示在页面上。单看效果没问题，但一旦进入工程化阶段，问题会成串地冒出来：同样的用户问题，模型今天答的和昨天答的不一样；知识库明明有正确答案，检索环节却捞不回来；上线半小时，日志里全是超时重试，账单数字也在肉眼可见地涨。这些问题的根源不在模型本身，而在于你把它当成一个普通函数在用。

传统后端开发的确定性来自输入和输出之间的强契约：参数校验、状态码、数据库事务，每一步都有明确约束。AI 应用恰好相反，模型输出是概率性的，上下文是动态的，检索结果是近似匹配的。这意味着你不能把“模型调通”当作终点，而要围绕不确定性建立一套新的工程机制：比如用评测集约束行为边界，用缓存和路由控制成本，用引用溯源降低幻觉风险。

所以 ai-engineering-from-scratch 这个项目真正的主角，不是某个大模型，而是模型外围的那一层“工程脚手架”。它包含上下文管理、检索增强、提示词版本化、评估数据集、监控告警、数据回流这六件事。做完这些，你的应用才算从“一次性的 demo”变成“可持续演进的系统”。

1.2 AI 工程师的能力地图：不只会写提示词

经常有人问，AI 工程师和普通后端工程师到底差在哪。我的理解是：普通后端面对的是稳定接口，AI 工程师面对的是一个需要持续驯服的“黑盒”。合格的 AI 工程师至少要具备五块能力。

第一是需求拆解能力。用户说“帮我做个客服助手”，你得能分辨出他真正想要的是知识库问答、工单分类，还是话术推荐，不同需求对应的系统设计完全不同。第二是上下文工程能力，知道怎么设计 system prompt、怎么切分文档、怎么决定哪些内容该塞进上下文，哪些不该塞。第三是评测设计能力，能在一周内手工标注一两百条评测数据，能设计出“这个回答算不算好”的判断标准——这是绝大多数团队最缺的一环。第四是传统工程能力，异步任务、缓存、限流、可观测性，这部分其实还是后端的活儿，只不过对象从数据库变成了模型接口。第五是数据迭代能力，能把线上坏案例持续回收，变成新的评测样例和知识库修正依据。

这五块能力并不要求你同时精通，但至少得知道每一步要解决什么问题、用什么工具切入。下面我从工具链和系统设计角度，把这条路的具体走法展开讲。

2. 从零开始的工具链选型与系统骨架

2.1 基座模型选择：别一上来就陷入“选择困难”

做 AI 工程化，第一步不是急着写代码，而是先定基座模型。我见过最典型的错误是一开始就同时接五六家模型服务，理由是“哪个好用用哪个”。结果每个模型都要单独适配一套参数格式和限流策略，调试成本翻倍，线上问题还不好定位。

基座模型的选型思路可以按三条线走。一是数据合规与部署方式：如果业务数据不能出内网，优先选择可以本地私有化部署的开源模型；如果数据敏感度可控，直接用厂商官方 API 服务可以省去一大笔运维成本。二是效果与成本的平衡：通用对话、摘要、分类这些任务，中小尺寸模型基本够用；但涉及复杂推理、长文档理解，还是要上更强的大尺寸模型。三是生态和工具链成熟度：优先选有完整官方 SDK、有流式输出、有结构化输出能力的模型服务，这些能力在工程化阶段都是刚需。

我的建议是从一个主流模型起步，把全链路跑通后再根据瓶颈做替换。替换时只需要把模型调用层单独封装，业务代码不感知具体后端，这样后续评测对比才有意义。顺便说一句，很多人忽略的细节是：同一个模型的不同版本，输出风格可能差很多。所以上线前一定要记录好“模型名 + 版本 + 日期”，否则下次重新部署，行为变化了你都不知道是代码改的还是模型版本更新造成的。

2.2 向量库与检索组件：选轻的起步，留好扩展位

RAG 是大多数 AI 应用的核心链路，向量库因此成了标配。但这里的选型有一个很容易犯的错：一开始就上一套分布式向量数据库，配置了分片、副本、监控，结果业务只有几千条文档，大炮打蚊子。

我的经验是分阶段选型。第一个阶段，文档量在十万级以内，用轻量级向量库或者直接在传统数据库里加一个向量字段就够了，比如用 FAISS 配合对象存储，或者用 PostgreSQL 的向量扩展。这个阶段最重要的是把“召回逻辑”打磨清楚，而不是追求高并发和分布式能力。第二个阶段，当数据量涨到百万级、需要动态更新和复杂过滤时，再迁到独立的向量数据库服务。迁移本身不难，因为你的数据 pipeline 和检索接口是独立封装的，换底层只改一个实现类。

文本切分策略比向量库本身更影响效果。我试过很多种切分方式，最终稳定下来的是“结构优先切割法”：先按文档的章节和段落层级切分，再对超长段落按固定窗口二次切分，同时保留相邻段落的少量重叠。比如 Markdown 文档，先按二级标题切开，再把超过 800 字的片段按 400 字窗口、80 字重叠往下切。这样既保留语义完整性，又不会让单段内容过长导致召回噪声变大。

2.3 编排框架：用代码做编排，慎用重型 Agent 框架

关于 AI 应用的编排方式，现在市面上有很多框架，有些甚至直接内置了 Agent 和工具调用能力。但我不建议冷启动阶段直接上重型框架，原因有三。

第一，Debug 困难。框架帮你封装了思考过程、工具调度和上下文管理，中间任何一环出问题，排查链条会变得很长。第二，Token 消耗不可控。Agent 化设计会让模型反复思考、多次调用工具，一个简单问题消耗的 token 可能是普通 RAG 的好几倍，成本在开发阶段很难直观感知。第三，行为难预期。多步决策本身就有随机性，再加上外部工具的影响，你很难判断一次回答到底是哪个环节出了问题。

我的做法是先用纯代码把流程编排清楚：函数接收用户问题，依次做意图判断、检索、重排、构造 prompt、调用模型、格式化输出。每个环节都是独立函数，都有日志埋点。跑通之后再根据实际需求引入更高级的框架能力——比如需要自动选择查询改写策略时，再封装一个工具路由层。你会发现，代码编排带来的控制感和可观测性，远比框架的“开箱即用”更值钱。

2.4 最小可用 AI 系统的骨架设计

把上面几个选型落地，一个最小可用系统大概是四层结构。

接入层负责统一接收请求，做身份认证、频率限制和参数校验。服务层编排核心流程：先根据用户问题做判断，决定走快速回复、知识库检索还是需要多轮澄清。检索层连接向量库和文档存储，负责把召回结果经过重排后变成上下文片段。模型层封装基座模型调用，统一处理超时、重试、流式输出和 token 统计。

这个骨架可以用一个很简单的后端框架在一天内搭出来，但它承载了后续所有迭代的起点。每层之间都用接口隔开，后续换向量库、换模型、加缓存，都不会影响其他模块。我把它称为“AI 系统的最小稳定态”——再复杂的产品，也建议从这四层结构上长出来，而不是凭空设计一个大中台。

3. 七天从零到一：一个可落地的 AI 工程实操闭环

3.1 第一天：定义问题域，准备评估集

很多项目的失败不是代码写得差，而是根本没说清楚“什么叫做好”。开始动手前，先花一天时间把问题域圈定下来。比如要做企业知识库问答助手，你需要明确它回答哪类问题：制度查询、报销流程、产品规格、排障指引，还是全部都要？范围越模糊，后续评测越难做。

同一天，手工准备一套小规模评估集。我的做法是拿 30 到 50 个真实业务问题，逐个写好标准答案或至少写好答案要点。不需要长，三句话以内就可以，关键是每条都要对应到知识库里的确切出处。这套评估集是“锚”，没有它，后面的优化就是凭感觉。

我见过有人想等系统上线后再从日志里收集问题做评估集。但那样存在一个循环依赖：没有评估集，你连系统够不够好都不知道，也不可能放心上线。手工标注虽然笨，但它是整个 AI 工程闭环里最值得投入的一步。

3.2 第二到三天：搭建 RAG 主流程

RAG 主流程可以拆成离线和在线两条线。离线部分先把知识库文档统一清洗、切分、向量化，写入向量库；在线部分接收用户问题，经过向量检索、重排、拼装 prompt，最后调模型输出回答。

离线清洗这一步常被忽略。我碰到过不少团队，文档直接从 Word 或 PDF 抽出来就丢进切片器，结果切出来的片段全是页眉页脚和乱码。正确的做法是先做内容清洗：去掉页眉页脚、目录和空行，识别表格和代码块并保留原有格式。清洗完再统计每个文档的章节结构，决定切片策略。

在线检索部分，第一版可以直接用向量相似度召回，取 top-k 比如 5 到 10 条。但你会发现向量召回对“同义词改写”敏感，比如用户问“工资几号发”，文档里写的是“薪酬发放日”，两个文本向量距离未必很近。所以后续至少要加一层查询改写，或者做关键词与向量混合检索。第一版不用做复杂，但要在代码里预留重排接口，后面优化直接往里填逻辑就行。

3.3 第四天：设计上下文注入和提示词模板

RAG 的最终效果很大程度上取决于“检索到的内容怎么被放进去”。同样的检索结果，prompt 写得好不好，回答质量能差一个档次。

我的提示词模板包含四个固定部分。第一段给模型定义角色和边界，明确它只能依据提供的资料回答，资料里没有的信息要直接说不知道。第二段放检索到的参考内容，每条内容前标注清晰的编号和来源。第三段是用户问题本身。第四段是输出格式要求，比如“需要分点时用编号，涉及数据时必须标注来源编号”。

这里面藏着一个关键细节：参考内容里往往有噪声，甚至不同片段之间存在信息冲突。在 prompt 里明确告诉模型，“当参考资料之间存在矛盾时，优先采信更具体的表述，并且要说明哪条资料提供了这个结论”——可以显著减少模型自作主张拼接信息的情况。输出格式要求建议用结构化描述甚至 JSON Schema，方便下游程序直接解析，也减少格式不稳定带来的解析报错。

3.4 第五天：跑评测，建立迭代基线

主流程跑通之后，立刻进入评测环节。把第一天准备的那套评估集逐条跑一遍，记录三类指标：完整命中率、部分命中率（回答了但不够准确）和拒答率（正确地说“不知道”）。

评测方式可以分两层。第一层用规则判断，比如标准答案中的关键词是否出现在模型回答里、来源编号是否指向正确文档；第二层用模型打分，把“问题 + 标准答案 + 模型回答 + 参考来源”打包喂给一个更强的模型，让它按 1 到 5 分做评分。模型打分要注意写清楚评分细则，否则容易偏向字数多的回答。

第一次评测结果大概率惨不忍睹，这很正常。你要记录的是每一个坏案例属于哪类问题：是检索没召回正确答案，还是上下文把正确答案埋没了，还是模型就是没按资料说。这一步产出的不是分数，而是“接下来改哪里”的决策依据。我通常会把评测结果导成表格，按问题类型归类，之后每次改动都能看到具体改善了哪一类。

3.5 第六到七天：部署上线与可观测性

评测迭代进行到关键指标稳定之后，就该往生产环境部署了。部署方案可以直接复用传统后端那套：服务用容器打包，前面挂负载均衡，再加上日志和监控。但 AI 应用有几个指标需要额外关注。

第一是性能和成本：记录每一次请求的模型名、token 输入数、token 输出数、延迟和缓存命中情况，按天聚合出单请求平均成本。不统计这个，成本失控会发生在你最不想看到它的时刻。第二是回答质量漂移：同样问题在不同时间拿到的回答，质量是否明显波动，这需要定期重跑评估集来发现。第三是引用可验证性：线上回答里标注的来源编号，是否能正确追溯到知识库文档，这直接关系到用户信任度。

部署时我还建议开一份“模型行为日志”，把每一条线上问答的输入上下文、命中片段、原始输出都存下来。很多团队觉得这样存储成本高，但这份日志正是后续数据回流和评测集扩充的来源。没有它，整个系统就缺少自我进化的燃料。

4. 常见问题与排查实录

4.1 输出不稳定：格式、内容、语气反复横跳

AI 应用上线后最先暴露的问题就是模型输出不稳定。同一套知识库和 prompt，上午回答还有条理，下午就变得啰嗦甚至格式混乱。影响这个的因素很多：模型版本更新、服务端负载变化、上下文里检索结果的细微差异都可能放大成输出风格的变化。

我的排查顺序是：先确认模型版本和参数没变，再对比输入上下文的差异，最后才是改 prompt。改了 prompt 一定要同步更新评测集并重新跑分，否则无法判断改动是变好还是变坏。此外，能用结构化输出就别让模型自由发挥。比如输出字段固定时，用 JSON Schema 约束结构；枚举类回答，直接限定可选值；需要分点的内容，在 prompt 里给一个标准模板示例，效果通常立竿见影。

4.2 检索不到正确答案或召回过少

检索召回不到正确答案，是 RAG 应用最让人头疼的问题。此时如果先去调 prompt，方向就错了，因为问题多半出在文档处理或查询理解上。

第一步检查是不是切分导致答案被截断。比如某个关键条款被切到了两个片段里，单个片段都不完整。这时调整切分参数，增大重叠部分，或者改用结构感知的切分方式。第二步检查查询和文档的表述是否对应，如果用户问“请假”，文档写“休假申请”，向量检索很可能匹配不上。加入同义词表或者做查询改写可以缓解。第三步看是否需要混合检索，向量召回对短文本有效，但对数字、型号、人名这类精确匹配并不友好，加入关键词检索做结果融合往往能大幅提升召回率。

还有一个很常见但容易被忽略的原因：知识库里根本没有答案。这种情况检索系统再聪明也没用，解决办法是建设“文不对题拒绝”机制，让模型在检索结果与问题相关度不足时明确拒答，而不是硬编一段看似合理的回应。

4.3 幻觉：回答看起来很流畅，实际是编的

幻觉是 AI 应用绕不开的话题，工程上能做的事就是层层设防。第一层防线是降低模型自由发挥的空间，prompt 里反复强调“只允许基于资料内容作答”，并且要求每个结论后面都标注资料编号，模型被要求给出来源时，编造概率会明显下降。第二层防线是做引用校验，让程序检查回答里的来源编号是否真实存在于本轮检索召回的片段里，如果回答引用了不存在的编号，就直接拦截或要求模型重新回答。

第三层防线是把把关交给另一个模型，用外部模型对回答做事实一致性打分，发现与资料不符时提出更正。这个方法成本高，适合用于高风险场景。纯靠提示词永远不能根除幻觉，所以系统设计上要允许“不知道”成为正确答案。一个能正确拒答的助手，比一个看似知识渊博但经常胡说的助手可信得多。

4.4 延迟和成本：可用性和账单的双重考验

线上用户的耐心不会超过几秒，AI 接口动辄几秒的响应已经让人血压升高。降低延迟的思路通常有几个：一是结果缓存，高频相似问题直接命中缓存，不重新走模型；二是上下文压缩，检索到的片段做重排后只保留最相关的两三条，减少输入长度；三是小模型路由，简单问题交给响应更快的小尺寸模型，复杂问题才走大模型。

成本控制方面，我建议把“每次请求的 token 消耗”当成核心指标来盯。很多时候成本高不是因为调用多，而是上下文里塞了大量无关内容。重排的价值就在这里体现：把 8 个召回片段压缩到 3 个，token 成本下降一半以上，回答质量反而因为噪声减少而提升。每次上线前，除了功能验证，也应该对平均 token 数做一个前后对比，这是很容易被忽视的回归风险。

4.5 知识库更新：改了文档，线上却还在用旧内容

RAG 系统天然面临知识库滞后的问题。文档更新后，如果旧向量没有被同步删除或覆盖，用户检索时可能同时拿到新旧两个版本，模型就会很困惑，回答五五开。为了解决这个问题，我建议离线索引建立一个“文档版本表”，每次文档更新都重新生成新的向量集，并用一个开关热切到新版本，同时保留旧版本以备回滚。

增量更新更是日常高频场景。文档每天都有变化，全量重刷成本太高。我的做法是把文档更新做成事件驱动：内容变更时只重算变更部分的切片和向量，并在向量库中按文档 ID 删除旧向量。这一套机制要在一开始就设计好，不然后期数据量大了，你会陷入“不重灌跑不动，重灌又贵又慢”的两难。

5. 从个人实践再聊几句

把 ai-engineering-from-scratch 这条路线完整跑下来之后，我最大的体会是：真正难的不是模型，而是围绕模型建立的那套“信任机制”。你需要让系统在大部分时候靠谱，在不确定的时候敢于说不知道，在出错的时候能被发现和追溯。这要求你同时懂一点算法、懂一点后端、懂一点产品评测，但更重要的，是愿意花时间去定义“什么算好”，并持续用数据来验证和打磨。

最后分享一个我一直在用的做法：每个 AI 项目都从第一天建一个“坏案例本”，只要是线上或评测中发现的错误回答，通通记录下来，隔段时间翻出来做一轮回归。这个动作比读十篇最佳实践都管用。AI 工程没有银弹，它是一条不断看数据、改系统、再验证的循环。把这套循环跑顺，你的“从零开始”就真正变成了能力，而不再只是一个项目名。