企业官网建设流程全解析

做AI工程化这一年多，我最大的感受是：真正难的不是模型效果调不出来，而是从“能跑”到“能稳定跑、能交付、能维护”这中间隔着一整条工程链。网上讲Transformer、讲微调、讲RAG的教程一抓一大把，但你问一个刚入行的朋友“模型上线之后怎么监控”“bad case怎么回流”“成本怎么控”，绝大多数人答不上来。这篇文章就是想把这些没人系统讲、但每天都在踩的工程化问题摊开聊聊——从需求判断、技术选型，到数据工程、评估体系，再到部署上线和成本治理，我会按我自己做过的项目路径来写。适合正在从算法实验往系统落地转的人，也适合被业务方推着上AI、但心里没底的开发团队。

1. 项目启动前的关键判断：这个需求到底要不要用AI

我见过太多项目从立项第一天就歪了。业务方说“我们要上一个智能助手”，产品经理说“别人家都有AI了我们也要有”，然后技术团队闷头开始训练模型——结果做了三个月发现，用户其实只想要一个更好用的搜索框。

1.1 先把业务问题翻译成技术问题

做AI工程和做算法实验最本质的区别是：算法实验关心“准确率能不能再涨一个点”，AI工程关心“这个问题能不能被AI更好地解决”。所以拿到需求的第一件事不是看数据、不是选模型，而是先把业务问题拆开。

我给你一个我一直在用的拆解模板，分四层：

• 问题层：业务方到底想解决什么？是“客服回复太慢”还是“知识库找不到人”？
• 数据层：这个问题涉及的数据长什么样？结构化还是非结构化？存量多少、增速多少？
• 边界层：AI只做辅助还是全自动？错误容忍度是多少？有没有合规红线？
• 度量层：上线之后用什么指标证明它有效？是时效、转化、还是满意度？

这里最容易被忽略的是度量层。很多项目上线前根本没定义清楚“什么叫成功”，结果模型上线了，业务方凭感觉说“好像也没变好”，项目就黄了。我的建议是：甚至在写第一行代码之前，就拉着业务方把度量指标对齐，白纸黑字写下来。

1.2 便宜方案能解决的，别上来就上大模型

另一个常犯的错是技术选型过度。一个常见的场景：业务方要做一个“文档自动分类”功能，你下意识想到微调一个BERT或者微调大模型——但你有没有想过，如果文档类别不超过20个、每个类别有足量的历史样本，用简单的TF-IDF加逻辑回归可能就够用了？

这不是说大模型不行，而是要算一笔账。大模型的成本是显式的API费用加隐式的延迟、运维、监控成本，而传统NLP方案的边际成本几乎为零。我在实际项目里总结了一条经验法则：

• 第一步，先淘汰不需要AI的方案。规则、正则、查表、模糊匹配，这些永远是优先考虑的。
• 第二步，判断任务的“语义复杂度”。是关键词就能兜住，还是要理解上下文？
• 第三步，再决定上传统模型、微调模型，还是大模型。

很多项目做到一半陷入泥潭，不是算法不够强，是方案选得太重了。能用一个配置文件解决的问题，千万别请一个需要GPU集群的模型。

1.3 最容易被低估的时间成本：数据准备

无论选什么技术路线，数据永远是最花时间的环节。我做过一个知识库问答项目，前后花了三周，其中模型调试只占三天，剩下两周全在跟数据死磕：文档格式乱七八糟、表格识别错位、PDF扫描件缺页、不同部门术语不一致……这些才是AI项目的真实日常。

所以判断一个AI需求能不能接，我还会加一条：“数据现状是什么？”如果业务方连数据在哪、长什么样都不知道，那这个项目的首要任务不是建模，而是先做数据基建。这不是技术问题，是项目管理问题。

2. 技术栈选型：不是所有组件都要自己造

从零搭建一套AI工程体系，最忌讳的事情就是什么都想自己来。大模型要自己部署、向量库要自己写、框架要自己搭——这不是做工程，这是做科研。合理的做法是：核心链路自研以保持控制力，通用中间件用成熟方案，再保留替换空间。

2.1 先分清哪些是核心资产，哪些是通用件

我判断一个组件要不要自研，就问三个问题：它是不是我们的业务壁垒？它是不是我们的核心数据资产？它是不是高频定制需求？

以聊天机器人项目为例：对话流程编排是核心，因为这决定产品体验；知识库切分策略是核心，因为这影响回答质量；但向量检索、消息队列、缓存这些，都是成熟领域，直接选用被验证过的方案即可。每自研一个通用件，意味着未来你至少要花三倍精力去维护它。

用表格直观对比一下我常用的一些技术选型：

2.2 用“任务形态”去匹配“技术路线”

选技术路线不能看哪个新潮，要看任务形态。我习惯把AI任务分成三类，每一类对应的技术路线完全不同：

分类任务走判别式路线。比如意图识别、垃圾内容过滤这类，输入输出都相对固定，用微调模型或传统模型，效果、成本、延迟都好控。生成任务走自回归路线。比如文本续写、摘要、对话，这类目前大模型优势明显，但成本高，要考虑缓存策略和输出的不确定性。混合任务走“流程编排”路线。先检索、后生成、再校验，这种最复杂，也是最常见的实际项目形态。

大多数To B、To C的真实项目不是单一任务，而是混合任务。理解这一点之后，你会发现所谓“AI工程化”，本质上就是把多个异构能力按可靠的流程串起来。

2.3 说一个具体的选型案例

之前我给一家公司做内部工单自动分类系统，第一版时他们有同事建议直接上大模型API做少样本分类。我算了一下：工单日增量约5000条，如果每条调一次API，一天成本几百块，一年光分类就烧掉近10万。关键问题是，“工单类别”一共只有12类，而且每类都有上万条历史标注数据。这种量级的分类任务，不需要大模型级别的理解能力。

最后是先用规则把明显能匹配的工单滤掉，剩下约30%的模糊工单，再交给一个微调后的轻量分类模型处理。最终效果：准确率比纯大模型少两个点，但成本降到原来的二十分之一，P99延迟稳定在几十毫秒级别。

这个案例想说明的事情很简单：先看看手里有什么、业务到底要什么，再看用什么模型。技术选型的本质是约束条件下的最优解。

3. RAG系统的数据工程细节：真正的分水岭在文档处理

检索增强生成（RAG）是当前落地最快、应用最广泛的大模型技术路径之一。但很多人把RAG想得太简单了——丢一堆文档进向量库，接上大模型就完事。真做了会发现：“文档解析这一步就能坑到你怀疑人生。”

3.1 文档解析的格式暗坑

PDF是重灾区。很多PDF看起来是文本，但复制出来全是乱序——两栏排版、页眉页脚、表格、图片注释，分分钟打乱段落结构。我处理过一份几十页的行业报告，直接按页提取文本，结果段落被劈成好几截，检索召回质量惨不忍睹。

针对常见格式，我的处理策略是这样的：

• PDF优先按布局分析而不是按页提取。用版面分析工具识别文本块、表格、图片区域，再按阅读顺序拼接。
• Word和Markdown相对友好，但要注意列表、多级标题、脚注的处理，切分时别把列表项拆散。
• 扫描件或图片型PDF需要OCR，但OCR出来的文本经常丢段落关系，建议OCR后做一次结构规整。
• 表格是最难的。简单表格可以转成Markdown表格喂给模型，复杂表格建议先“语义化”，比如转成key-value描述，而不是保留原始格式。

这些坑没填好，后面做检索、做生成，都要连本带利还回来。数据工程做得好不好，会在评估阶段直接体现为召回的准确率差距，甚至是几个点的最终效果差距。

3.2 切分策略不是“按固定长度切”那么简单

很多RAG教程教你按512或1024个token切块，这个做法在真实场景里问题很大。固定长度切分会把一个完整的语义段落拦腰截断，导致句意破碎，检索时召回的内容经常是无头无尾的残句。

我现在的切分策略是“结构优先、长度兜底”：优先按文档结构和语义边界切分，例如按标题划块、按段落划块、按列表项划块；当单个块太长、超过模型上下文限制或超过检索预期粒度时，再在句子边界做二次拆分。

这里还要考虑“区块重叠”的问题。我在实践中的经验是：相邻区块之间可以保留50到100字的重叠，能显著减少由于切分造成的语义漏检。而区块粒度的大小也有直接影响，粒度越细，召回越精确；粒度越大，上下文越完整。两者之间的矛盾，需要根据文档类型和任务场景不断试。

3.3 检索召回之后的“重排”决定天花板

很多RAG项目只做了向量召回Top K，然后直接把内容丢给大模型生成，效果往往不如预期。一个重要的原因是：向量检索擅长找“语义相近”的块，但不擅长判断“哪个块最能回答问题”。相似不等于相关，相关也不等于能支撑答案。

我的做法是召回之后加一层重排序，用重排序模型对召回的候选块做精排。两层结构的好处是：第一层用向量检索扩大召回范围，保证不漏；第二层用更强的模型做精细化排序，把最相关的块顶上去。这个环节对回答质量的提升有时候非常明显——相比只做向量召回，命中率通常能提升不少。

重排模型的成本比向量检索高一个量级，但因为只对Top 50以内的候选做精排，整体延迟增长可控。具体阈值可以根据业务容忍度调整。

3.4 一条实用的数据工程流水线

综合上面的经验，我搭的标准RAG数据流水线大致是这样的：先做数据接入和格式归一化，把所有文档统一转成纯文本加结构标记；然后做版面还原和清洗，去掉页眉页脚、恢复段落顺序、合并被截断的句子；接着做段落切分和重叠处理；再做向量化入库，同时保留文本原块和结构元数据。每次切分规则调整，都会重新跑一遍流水线，保证线上检索用的和实验用的数据版本一致。

数据版本管理是我特别想强调的一点。没有版本管理，你会遇到“昨天效果还行、今天突然变差”的情况，却完全不知道是不是因为数据变了。用类似Git的方式管理数据集，能省掉非常多排查时间。

4. 评估体系搭建：没有度量就谈不上工程化

模型效果好不好，不能靠感觉，要靠指标。但AI工程里的评估，从来不是“算个准确率”那么简单。一个模型可能在离线测试集上表现完美，上到线上面对真实数据就各种翻车。所以我习惯把评估拆成离线评估、在线评估、持续监控三个层次。

4.1 离线评估：回答质量怎么量化

离线评估有两个层面：检索层面的评估和生成层面的评估。

检索层面的指标相对好定义：Precision@K、Recall@K、MRR等。这个层面我重点关注“召回率”，因为漏检往往比误检更难补。生成层面的评估就比较棘手——生成结果不像分类结果有明确对错。我的做法是分维度打分，而不是给一个笼统的分值：准确性，回答是否基于给定资料、有没有幻觉；完整性，是否覆盖问题的所有关键方面；相关性，是否答非所问；可读性，表达是否自然、有条理。

对于准确性这个维度，我强烈推荐引入“引用溯源”：要求模型在回答时标注依据来自哪个原文块，然后人工或规则去核对回答是否真的由这些块支撑。这一招是降低幻觉最有效的手段，也给了用户一个去验证答案真伪的渠道。

4.2 构建评估集的三条原则

很多团队不做评估，是因为觉得“没法评估语言模型的质量”。我觉得关键在于构建一套高质量的评估集。这里有三个原则：

覆盖高频场景和关键边界。评估集必须包含典型的正常请求，更必须包含业务上不能错的边界case。人工标注为主，规则辅助为辅。自动化和人工的结合可以提升规模，但核心数据需要人工精标。持续更新，常态化维护。线上出现的新bad case，补充进评估集。

这一点我想多说两句。有些团队会把“补bad case”当成故障处理，只在出问题时才动一次，这是不够的。要把它固化成一个例行流程：每周收集线上的bad case，标注后加入回归集，每次改模型或改prompt之后都统一跑一遍回归评估集，防止修了A问题、坏了B问题。

4.3 线上监控：离线指标在线的失效问题

离线指标永远不能完全代表线上效果，因为线上分布会漂移。用户输入的表达方式变了、知识库新增了内容、甚至语言习惯随时间演进，都会让离线测试集失真。

所以在线监控是必须的。我常用的线上指标有两类：

业务指标：用户采纳率、任务完成率、回答点赞率、转人工率等。这些是业务方真正关心的，也是最终衡量项目价值的依据。质量指标：无回答率、低分率、bad case上报数、平均响应时长、成本消耗等。这些直接反映系统健康度。

在落地上，我建议先把关键指标做成实时看板，然后设定告警规则。比如“无回答率突增”“P99延迟超时”“单日成本超标”，都需要第一时间告警。我见过太多AI项目，线上出问题都是用户先发现、业务方先投诉，技术团队才后知后觉——这个局面一旦形成，整个项目在组织里的信任度就崩了。

有一个经验是：线上质量监控，宁可指标粗糙、覆盖全面，也不要精确但缺失。先有覆盖，再谈精细。

5. 上线前后：部署架构、延迟控制与成本治理

实验环境里跑通的模型和代码，距离真正上线还有很长的路。我在这一部分集中的经验，都和“生产环境”四个字有关。

5.1 大模型推理是延迟黑洞，得有策略

大模型生成是逐个token往出蹦的，输出越长、延迟越高，而且是累加的。这跟传统接口完全不同——传统接口的延迟主要取决于网络和计算，通常在几百毫秒以内；但大模型接口，输出几百个token可能就需要数秒。这种延迟对用户体验的影响是致命的。如果用户等一个回答要等5秒以上，流失率会非常明显。

控制延迟有几个关键的思路：

控制输出长度。prompt中明确约束输出结构，能显著降低无效的生成长度。流式输出。对于聊天场景，流式输出是必选项，它让用户感觉回答在实时生成，感知延迟大幅降低。语义缓存。对高频相似问题进行缓存，能直接命中一模一样的重复问答，省掉整个模型调用。模型分级。简单问题用轻量级模型，复杂问题才升级到大模型。这个策略能省下大量成本、提升整体响应速度。

5.2 语义缓存的体验比大家想的更好

很多人对语义缓存有顾虑，担心“相似问题的回答会不会张冠李戴”。实际上，语义缓存不是简单按文本完全匹配，它通过向量相似度来判定问题是否等价。两个问题的写法不同但核心语义一致，可以直接复用之前的答案。需要注意的是相似度阈值要设得保守一些，保守意味着命中率变低，但误命中概率也变低。篡改一个案例：客服系统里“你们的退货政策是什么”和“怎么退货”，在向量空间里距离很近，命中缓存后直接秒回，用户根本感知不到这是缓存。

语义缓存的收益非常可观。如果业务中重复性问题占比高，比如客服、售后场景，命中率很容易做到30%以上——相当于整体成本直降三成，延迟也大幅下降。这是我在成本治理中优先级最高的方案。

5.3 可观测性：没有日志和链路追踪，故障排查就是大海捞针

AI应用的排障比传统应用复杂的地方在于：一个回答不好，可能源于检索问题、prompt构造问题、模型行为问题，还可能是数据更新没生效。没有可观测性，你根本定位不到是哪一环出了问题。

我的做法是给每个请求生成一个统一trace ID，贯穿整个调用链路——从用户输入、query改写、检索召回、重排、prompt拼接、模型输出，到最终返回。每个环节都记录关键耗时代理和中间结果。一旦用户反馈效果不对，直接通过trace ID拉出整条链路，就能快速定位问题环节。这个体系建完之后，排查故障的时间能缩短一个量级。

成本可观测性同样重要。记录每个请求的token消耗、每类功能消耗的占比、每个业务线的总消耗，这些数据能直接告诉你钱都花哪去了。没有这一步，你怎么调优成本都没有依据。

5.4 持续交付与回流机制

上线不是终点，而是另一个循环的起点。我自己非常重视“生产数据回流”的闭环：线上用户反馈、bad case、人工修正的结果，定期回流为训练数据或评估数据。另一点是模型和数据的版本管理，没有版本控制，线上模型不可解释、不可回滚。

如果是自部署模型，我建议把模型的灰度发布机制建好。先切5%流量到新模型，观察关键指标，稳定后再逐步放大。如果效果变差，能立刻回滚到旧版本。对用户来说，一次失败的回答可能不算灾难；但对团队来说，不可回滚的系统是一个随时会爆的雷。

6. 关于“从零开始”的一些补充

写到这里，我最想说的一句话是：AI工程化不是一个技术问题，是一套平衡艺术。所谓平衡，是效果和成本的平衡，是把一个问题拆到足够细、用最合适的工具去解决，而不是所有问题都上大模型；是速度和质量的平衡，是先跑通端到端的最小闭环，再逐步打磨效果；是稳定与创新的平衡，是核心资产自研、通用件现成，是保留替换能力但不盲目自建。

我还想分享两个实操习惯，对工程链路比较有用。

第一个习惯：任何改动，先想好“怎么验证、怎么回滚”，再动手。这个习惯在AI项目里比传统后端项目更重要，因为模型行为的不确定性，决定了你永远不能假设它会按预期工作。第二条，每做一个阶段，都把当时的代码、数据、配置、评估结果打一个快照。这能让你在几个月后还能回答出“当时为什么效果是最好的”。

如果你也在做AI相关的工程化项目，希望这篇文章能让你少走一些弯路。技术细节可以查文档，但工程经验没法查——它藏在每一个踩过的坑和填过的洞里。