企业官网建设流程全解析

先说实话：我最近面试了不少挂着“AI工程师”头衔的候选人，简历上写满了各种模型名和框架，但当我问“你怎么证明这套系统这周比上周更好用”的时候，一半以上的人会沉默。这个问题暴露的，是很多人根本没理解 ai-engineering 到底在干什么。跑通一个模型不是工程，把模型变成稳定、可控、低成本、可迭代的产品，才算工程。

这篇文章算是我从零搭建 AI 工程体系的一份完整复盘。我会把算法工程师和 AI 工程师的边界讲清楚，把从 Python 基础到 RAG 实战的成长路线拆开，把上线后那些没人提前告诉你的坑一个个摆出来，再给你能直接抄作业的方法。适合想转 AI 方向的后端开发，也适合刚入行的算法新人，以及被老板扔了一个 AI 项目但脑子里还没地图的团队负责人。放心，我不贴大段论文公式，尽量用能落地的大白话讲清楚每一步的“为什么”。

1. AI工程到底是什么，和跑通一个模型完全不是一回事

1.1 算法岗和工程岗，隔着一整条产品线

我见过太多团队把算法工程师和 AI 工程师混为一谈，结果项目做到一半就卡死。算法工程师的核心任务是“证明可行”：在一个数据集上把某个指标刷上去，验证某个模型结构是否有效。他们的产出是一份实验记录、一组权重文件、一篇研究报告。而 AI 工程师的核心任务是“交付可用”：把已经证明可行的技术变成用户能稳定使用的东西，要管数据、管服务、管成本、管监控、管回归测试。

这两个岗位的思维模式差异很大。我常用一个比喻：算法工程师是发明新菜谱的厨师，AI 工程师是把菜谱变成中央厨房标准化流程的人。你当然可以既懂研发又懂生产，但你的精力分配和做事方式会截然不同。后台算法同学把离线召回准确率做到 98%，上线以后用户依然骂“这机器人答非所问”，这种案例我见过不止一次。原因是用户的问题分布和精挑细选的测试集永远不一样，离线 98% 的分数在线上可能连 60% 都不到。这就是典型的不理解 AI 工程：模型能力只是系统能力的一部分，数据质量、检索逻辑、提示词结构、兜底策略，每一环都在决定最终用户体验。

再具体一点，我给你画一下两种角色的日常。算法工程师一天下来主要在研究 loss 曲线、调整超参数、洗特征。AI 工程师一天下来可能在写文档解析脚本、调向量检索参数、设计 prompt 模板的版本管理、和运维一起排查 GPU 显存泄漏。你看着都很“AI”，但关注点完全不同。如果你是转行进来的，你要明白，行业里大量岗位说的“AI工程师”，其实更接近后者。

1.2 AI工程师的真实能力栈：数据、模型、服务、评测

很多新人学 AI 工程，第一反应是“我要把 Transformer 底层写出花”。但真实项目里，AI 工程师最值钱的往往不是手写模型，而是另外几项不太炫酷的能力。我按重要程度排序：

• 数据工程能力：数据采集、格式解析、清洗、去重、标注、质检。一个 AI 项目里，人力成本最大、迭代最频繁的环节，十有八九在数据侧，不在模型侧。
• 模型与算法基础：不需要从零手写 Transformer，但要能读懂模型卡说明、知道不同模型的适用长度、了解 temperature 和 top_p 对输出的影响、能判断什么时候该微调、什么时候该用 RAG。
• 服务化与部署：API 设计、并发控制、推理加速、镜像打包、灰度发布、监控告警。这部分能力决定了系统能不能扛住真实流量。
• 评测与迭代：建评测集、跑回归、比较不同 prompt 或不同模型版本的效果。很多团队做不好 AI 项目，不是因为模型不够强，而是因为“变好了还是变差了”全靠感觉。

上面这个能力栈，四分之三的人都低估了“评测”这一环。我后面会专门展开，这里先点一句：没有评测体系的 AI 系统，就是一辆没有仪表盘的跑车，你能开，但你不知道什么时候会爆缸。

为了让你更直观地对照，我把常见误区也列一下：

2. 从零起步的技术选型和一条成长路线

2.1 为什么语言和框架要先选Python

很多后端同事一听说 AI，第一反应就是“我要用 Java 或 Go 写一个高性能推理服务”。我的建议正好相反：从零开始学 AI 工程，语言先死磕 Python 就好。理由非常简单：目前 AI 生态几乎全部长在 Python 上。PyTorch、Transformers、LangChain、LlamaIndex、FastAPI，甚至 vLLM 的 Python 接口，你都能在一小时之内把模型串起来。如果你非要一开始就用 Go 或 Java 去对接推理引擎，光是 tokenizer 兼容、模型格式解析、prompt 模板管理这些事就能把你劝退。

速度是不是瓶颈？在这个架构下基本不是。AI 工程的性能瓶颈绝大多数在 GPU 显存带宽、推理引擎的调度效率、向量检索的召回精度这些地方，不在业务语言的循环速度上。Python 负责调度和管理，真正跑重活的交给 vLLM、TensorRT-LLM 这些专用引擎，或者用 C++ 写一个独立的推理微服务。这套分工已经是行业默认范式，没必要逆着来。

2.2 工具链选型：框架、向量数据库、推理引擎

从零搭一套 AI 系统，最核心的选型点有四块：模型框架、向量存储、推理服务和业务服务框架。以我自己的实践经验，每个位置都有相对稳妥的选择，核心逻辑不是“哪个新用哪个”，而是“稳定、生态好、团队学得会”。

选型有一个极易踩的坑：过早引入重量级组件。我见过一个几万条文档的知识库项目，团队第一周就上了分布式向量数据库集群，三个人维护了两周还没把数据灌进去。其实这个量级一个 FAISS 本地索引加一份 JSON 快照就够了，效果一样，运维成本低一个数量级。你要记住，选型帮你解决的是当前瓶颈，不是提前透支未来的麻烦。

2.3 三步爬坡路线：从本地脚本到线上服务

我给零基础读者和半路转行的朋友画过一条路线，叫“三步爬坡法”。按这个顺序走，成长曲线最平滑，每个阶段都能看到成果。

第一步，本地跑通一个开源模型。到 HuggingFace 上下一个 Qwen 或 Llama 的小尺寸版本，用 Transformers 库加载起来，让它复述一句你写的话。整个过程里你会自然理解 tokenizer 怎么把文本变成 token，模型怎么加载权重，输出怎么采样解码。这一步不要贪大，一个 1B 到 7B 之间的模型足够建立体感。

第二步，把它用 FastAPI 包成一个 HTTP 接口。给服务加一个全局并发控制，防止多个请求同时撞到同一个推理进程里。这一步的核心是理解“模型是有状态的，接口必须是无状态的”这个工程事实。你还需要学会如何在进程启动时加载模型，而不是每次请求都重新加载一次。

第三步，给它加记忆和工具。试试给服务接一个向量检索数据库，让它能基于你自己的文档回答问题。做到这一步，你就摸到了 RAG 的门口，这也是我认为目前 AI 工程落地率最高、性价比最好的架构。后面我会专门用一个章节，把 RAG 的完整搭建过程拆给你看。

3. 手把手拆解一个RAG知识库问答系统

3.1 需求分解与架构设计：先想清楚再写代码

我挑一个最常见的场景来讲：企业内部售后知识库问答。比如一家卖设备的企业，库里躺着几百份产品说明书、故障手册和维修记录，售后客服每天要重复回答大量“设备故障代码怎么解决”之类的问题。我们要做的，就是让售前人员或最终用户直接提问，系统自动从文档库中检索相关内容，生成准确回答，并且附上原文编号方便追溯。

这个需求第一眼感觉“接一个对话模型就行”，但一拆就发现问题不少。你至少需要处理五件事：文档格式五花八门，有扫描 PDF，有 Word，有带复杂表格的 Excel；文档会定期更新，旧的知识不能一直占着；回答必须可追溯，否则客服不敢采纳；不同的用户问题风格差异很大，有人问“机器报 E001 错怎么处理”，有人问“怎么解决设备启动后又立刻停机”。每一件事对应系统里的一个模块：文档解析、切分、向量化、存储、检索、生成、引用溯源。

在架构上，我建议把系统拆成两条链路，坚决不要把所有的逻辑堆在一个脚本里。

• 离线数据链路：原始文档 → 格式解析 → 清洗 → 切分 → 向量化 → 索引构建 → 索引版本管理。
• 在线推理链路：用户提问 → 问题向量化 → 混合检索 → 候选片段排序 → prompt 组装 → 大模型生成 → 引用校验 → 输出返回。

两条链路分开的最大好处是互不干扰：你更新文档索引的时候，在线服务不用重启；在线链路出了性能问题，你也不会被数据解析的逻辑干扰排查思路。

3.2 文档解析和清洗：最容易被忽视的起跑线

很多 RAG 项目翻车，不是模型选错了，而是“文档没洗干净”。企业文档是重灾区：扫描 PDF 里文字是图片，Word 里嵌着表格，Excel 明明是结构化数据却被绕来绕去的注释搞得很难解析。这些问题若不处理，检索时就会出现片段错位、信息残缺、表格内容完全走样。

我现在的处理流程固定为四步：

1. 格式摸底：先统计你手上有多少种文档格式，各自占比。这一步看似多余，但决定了你后面人力怎么分配。
2. 文本提取：扫描件用 OCR，我主要用 PaddleOCR，中文识别效果比很多老牌开源工具好；数字化 PDF 用 pdfplumber 或 PyMuPDF，各有用武之地，优先保表格和段落结构。
3. 清洗：去掉页眉页脚、页号、重复标题、无关声明。表格在清洗过程中统一转成 Markdown 表格，避免后续模型和切分算法丢掉结构。
4. 语义切分：按标题层级和段落边界切，不是简单按字符数硬切。

切分这一步特别值得说。固定长度切分（比如每 512 个字符一刀切过去）看着省事，但频繁地把话题从“设备安装步骤”切到“故障代码表”，检索的时候会莫名其妙召回一些语义断裂的片段。我现在的做法是：先用 Markdown 标题把文档切成大块，再把大块内按段落、列表项切成长度 200 到 400 字的小片段，相邻片段之间保留 30 到 50 个字的重叠，这样既能保证语义完整，又能照顾到跨段落的上下文衔接。

3.3 向量化与索引构建：选对Embedding模型，检索就赢了一半

文档切好之后，要做 embedding 向量化。中文场景下，我很推荐开源的 BAAI/bge-m3，效果不错且能本地部署，维度是 1024，不依赖云端接口也能跑。如果你的团队不想维护 embedding 模型，直接用云厂商的向量化接口也行，1536 维或 1024 维都常见。这里提醒一句，维度不是越高越好。高维度带来更高的存储成本和检索耗时，如果 bge-m3 的 1024 维已经够用，没必要追着更大的模型跑。

向量化之后就是构建索引。我的做法是先用 FAISS 搭一个本地索引做验证，等数据量过了百万条再考虑迁移到 Milvus 或 Qdrant。核心检索参数里，top-k 我一般取 4 到 8。k 太小，上下文不足；k 太大，噪声片段会冲淡真正的答案。另外强烈建议用混合检索：纯向量检索对专业术语和型号不敏感，而 BM25 关键词检索能弥补这一点，把那几个召回结果加权融合后的分数作为排序依据。下面是构建索引的一个极简示例，帮助你理解链路：

from sentence_transformers import SentenceTransformer import faiss import numpy as np model = SentenceTransformer("BAAI/bge-m3") chunks = load_chunks("clean_docs.jsonl") # 把每个片段编码为向量 vectors = np.array([model.encode(chunk) for chunk in chunks]) # FAISS内积索引，配合归一化后等价于余弦相似度 index = faiss.IndexFlatIP(vectors.shape[1]) index.add(vectors) faiss.write_index(index, "kb_index.bin")

别以为生产环境就这两行代码。至少还要补三件事：索引版本管理、增量更新机制、向量备份。否则文档一更新，旧索引还在线上跑，用户问出来的就是已经被删除的旧知识。

3.4 生成链路与提示词设计：把上下文窗口当成稀缺资源

检索到候选片段后，真正的战斗才刚开始。把片段组装成 prompt 时，有一件事必须刻在脑子里：上下文窗口是稀缺资源。假设你用的模型上下文上限是 8K token，你一股脑把 6K 的检索片段塞进去，留给模型“思考”和生成的空间就只剩 2K，最后输出的内容自然会显得僵硬、细节缺失。

我的分配策略是：给检索片段设置一个总体积预算，比如总上下文 8K 的话，检索片段不超过 4K，剩下的留给指令、历史对话和模型输出区。同时，把用户问题放在 prompt 靠近末尾的位置，避免被长段历史对话干扰。

提示词模板可以长这样：

SYSTEM_PROMPT = """ 你是设备售后助手。只能根据提供的文档片段回答用户问题。 如果片段中没有答案，明确说"根据现有资料无法回答"。 引用资料时，请在句末标注对应片段ID。 """ build_prompt = f""" 完整文档片段如下： {formatted_chunks} 请回答用户问题：{user_question} """

看见上面“请标注片段ID”这个要求了吗？它不是为了好看，而是帮你做两件事：用户能看到答案的溯源出处，增强信任感；你可以在后台校验模型引用的 ID 是否存在，从而判断这次回答是否可能“编造来源”。这个细节我在生产项目里用过太多次，它能直接抓出一批胡编乱造的回复，非常管用。

3.5 评测与迭代：让系统持续变好的发动机

RAG 上线之后，你不能当甩手掌柜。它的灵魂在评估，没有评估的 RAG 就是一个黑箱。我的习惯是建一个 50 到 100 条真实问题的评测集，每条问题都标注标准答案和与之对应的文档片段。之后每一次改 prompt、换 embedding 模型、调切分参数，都在评测集上跑一遍，记录三个指标：

• 检索命中率：top-k 片段里是否包含答案所在片段。
• 生成准确率：模型回答是否和标准答案一致，可以用一个大模型做裁判来打分，也可以用相似度工具辅助判断。
• 引用正确率：答案标注的片段 ID 是否真实存在，并与答案内容吻合。

迭代的收益非常可观。我之前带过一个售后问答项目，光是把评测集建起来，连续跑了两周回归，回答正确率从 58% 提到 82%，这期间没有换任何模型，只做了检索参数和提示词的微调。你说评测值不值钱？所以说，AI 工程里最贵的东西不是 GPU，而是你愿不愿意把“感觉变好了”变成“数据证明变好了”。

4. 生产环境踩坑实录：四个最痛的点

4.1 GPU成本就像水龙头，不管它就会漏水

RAG 系统如果完全本地部署，最大的成本项就是 GPU。可很多团队一上来就把一个大模型实例全天候运行，哪怕深夜只有两个人访问，卡照样烧着。满负荷 vs 空转，花的钱一模一样，但回报截然不同。

我的策略是加一层弹性推理路由：高峰时段把流量导向 GPU 上的完整版模型，低谷时段转向 CPU 上的轻量小模型，或者直接走云上按量计费。迁移初期不要搞复杂，在 FastAPI 网关层加一个按时间窗口切换的开关，把请求分流到不同推理后端就行。另外，压缩 prompt token 是实打实的省钱手段。检索回来的片段如果堆了太多冗余文字，可以先做一个摘要压缩再灌给生成模型，成本往往能省两到三成，回答质量还更高。

4.2 模型输出幻觉：压不住，但可以圈住

幻觉问题绕不开，说几个我亲测有效的手段。第一个是降 temperature。很多对话场景设成 0.2 左右就足够，别默认用 0.8。温度越高，模型越“敢编”，而知识库问答场景要的是纪律。第二个是强制引用，刚才已经说过。第三个是加自校验步，让模型在回答之前先判断“检索片段里是否有足够信息”。代价是多一次模型调用，但能显著减少一本正经胡说八道的回复。第四个是兜底策略，如果检索到的最高分段相关度分低于某个阈值，直接返回“资料不足，建议转人工”，而不是硬着头皮生成。

我的体感是，幻觉不可能完全归零，但产品层面一定能兜住。最简单的做法就是答案后面永远带原文链接，让用户有能力去核对。AI 系统不应该替用户做最终判断，而应该把判断依据交给用户。

4.3 并发和延迟：瓶颈往往不在大模型

一个 RAG 服务并发上不去，很多人第一时间会怀疑生成模型推理太慢。但真实项目里，瓶颈常常出现在更隐蔽的地方：每次请求都现算用户问题的 embedding，然后在向量库里再查一遍。用户问题的 embedding 计算本身就要调一次小模型，它和生成大模型抢显存，互相拖慢。

我的优化清单：

• 对问题 embedding 结果做缓存，相同或相近的问题直接命中。
• 对检索结果做 30 到 60 秒的短时缓存，热点问题不用反复查库。
• 生成接口用流式输出，首字延时会显著改善，用户体感会好很多。
• 数据库连接池、HTTP 客户端连接复用，这些后端基本功在 AI 工程里一个都不能丢。

我做过一个对比，加上问题缓存和检索缓存之后，单实例 QPS 提升了两倍多，首字延迟缩短了一半。这类优化见效极快，不需要动模型。

4.4 监控和告警：AI服务最怕死得不明不白

AI 服务出故障，最让人崩溃的不是故障本身，而是你分不清到底“模型抽风”还是“系统报错”。所以日志和监控必须从第一天就设计好。每次请求至少要记录三组信息：用户问题与最终的 prompt 全文、检索到的片段 ID 列表与相关度分数、模型返回内容与耗时。有了它们，排查任何问题都能回答三个核心问题：用户问了什么、系统检索到了什么、模型答了什么。这三个问题几乎每次线上事故复盘都要用到。

告警阈值建议按滑动平均值来设定，比如近 5 分钟错误率、超时率、token 消耗趋势。不要用固定阈值，线上流量波动大，固定阈值要么天天误报，要么等真出事的时候已经晚了一小时。

5. 流程管理：让AI系统不靠个人英雄主义

5.1 Prompt也是代码，要版本化、可测试、能回滚

一个 AI 工程体系成熟与否，最直接的标志就是 prompt 是否被当作代码来管理。我见过最乱的项目，prompt 模板被人存在微信聊天记录里，改了一版没有人记录，效果变好了说不清原因，变坏了也没法回退。

我的建议很朴素：

• 把 prompt 模板抽成独立的文件，和代码一起纳入 Git 管理。
• 每个 prompt 文件头部写清设计目的、输入格式、重要禁忌。
• 任何 prompt 改动，都必须先在评测集上跑一遍回归，通过之后才允许合并上线。

这样改进以后，线上出了任何问题，你都能倒查是哪一次改动引入的，而不是全组人凭记忆互相拷问。

5.2 从Demo到可维护系统的清单化改造

很多团队的 RAG 项目能跑 demo，但称不上可维护的系统。我整理了一个自查清单，每一条都来自真实项目里的教训：

• 有没有专职负责数据更新，文档变更后多久自动同步索引？
• 有没有日志聚合，出事能否在一分钟内找到当时的请求记录？
• 有没有成本统计，每个模块的 token 消耗和 GPU 占用是否能按天追溯？
• 有没有回滚预案，prompt 更新后效果变差，能否一键切换旧版本？

这些事单独拎出来都不难，难的是把它们变成制度化流程。我见过太多团队把 RAG 当 demo 运维，白天人少还能应付，晚上用户一多就开始批量超时和乱答，然后全组人连夜救火。那不叫 AI 工程，叫 AI 放飞自我。

6. 回归工程本质：我的一点个人体会

写到最后，我觉得真正重要的不是某一个模型、某一个框架，而是“工程心态”。从零开始学 AI 工程，难的不是背模型架构，而是你面对一个天生带随机性的输出时，仍然愿意用确定性的流程去约束它。数据清洗、评测集、版本管理、监控告警，这些事都不性感，但它们是 AI 系统能长期运转的真正地基。

再分享一个小技巧：每次迭代完一个版本，录一个一分钟的演示视频，把改动前后的效果放在一起对比。视频在汇报和复盘时比任何文档都有说服力，也会倒逼你从“感觉变好了”过渡到“证据显示变好了”。我现在还留着三年前第一版 demo 的视频，每次翻出来看都觉得当年能跑起来是奇迹。但也就是一个又一个这种不起眼的、枯燥的工程细节叠在一起，才最终变成今天异常稳定的线上产品。