企业官网建设流程全解析

这两年“ai-engineering”这个词的热度一直很高，各种大会、技术博客、招聘岗位都在聊，但说实话，很多人对AI工程的理解还停留在“调用大模型API做个小应用”的层面。我自己是从传统后端开发转过来的，完整落地过几个生产级AI项目，踩过不少坑，也积累了一套从零开始把AI工程做扎实的方法论。这篇内容就是把我实际跑通的路径、选型思路、实操细节和排查经验全部整理出来，给想系统性入门AI工程的人一条可以直接照着走的路。

这篇文章不是什么入门科普，而是一份“从零到一落地AI工程”的实战复盘。它涵盖了学习路线、技术栈选型、RAG系统搭建、评估体系构建、性能优化和踩坑记录。适合有三到五年开发经验、想切入AI应用层的工程师，也适合已经在用LangChain或者Prompt API但总觉得体系不完整的人——看完你会对“AI工程到底在干什么”有一个清晰的全貌认知。

1. 先搞清楚：AI工程究竟在解决什么问题

1.1 为什么“调一个API”不等于“AI工程”

我见过太多的项目演示，用OpenAI的API写个Prompt，串上几个工具函数，然后跑出一个看起来不错的demo，就觉得自己在做AI工程了。但实际上，从“能跑通demo”到“能上线扛住真实流量”，中间横着一条巨大的专业鸿沟。

先说几个真实场景你就明白了。你的Prompt在demo环境里输出稳定，但到了生产环境，用户输入稍微绕一点，模型就开始“自由发挥”了；你的RAG检索在测试集上命中率还不错，但切换到真实文档时，因为chunk颗粒度不合适，召回质量直接腰斩；你的系统上线没问题，但用户反馈你今天答得好、明天答得稀烂，因为模型版本或上下文策略变了，你却完全没有可观测的手段去定位问题。

这些才是AI工程真正要解决的问题。它远不只是“调用模型接口”，而是围绕大模型构建一套完整的、可维护的、可评估的、可迭代的生产级系统。AI工程的核心工作，是把大模型的“不确定性”约束在“业务可控”的范围内，并且能持续稳定地交付价值。任何跳过评估、跳过监控、跳过数据治理的做法，最终都会在线上以更痛苦的方式找回来。

1.2 AI工程与传统软件工程的本质差异

传统软件工程里，代码逻辑是确定的：输入X，执行函数A，输出Y。出了问题，你可以直接看stack trace，找到对应的代码行，修复，回归测试，发布。整个过程是“可解释、可复现”的。

AI工程则完全不同。系统里多了一个关键变量：大模型本身是概率性的。同一个Prompt，今天调用和明天调用，结果可能不同；同一个问题，换一种措辞，模型理解就变了。这导致了两点本质差异。

一是评价体系变了。传统软件的功能是“对或错”，而AI系统只能谈“好或差”。因此你需要一套额外的机制来度量“好差”，比如准确率、召回率、忠实度、相关性这些指标，并且要持续跟踪它们的变化。没有度量体系，迭代就是瞎搞。

二是问题定位的复杂度急剧上升。传统系统出问题，要么是代码逻辑问题，要么是数据问题，边界清晰。AI系统出问题，可能是Prompt设计问题，可能是检索内容不匹配，可能是模型本身能力边界，也可能是调用链路中某个环节超时或异常。你没法靠看日志就定位，必须构建trace机制和分析框架。

一个标准的AI工程化链路，应该包含：需求定义 → 数据准备 → 模型选型/微调 → 效果评测 → 部署上线 → 线上监控 → 反馈闭环。每一环都不是可选项，而是必需项。这也是我写这篇内容的底层逻辑：让你看到AI工程的全貌，而不是只盯着某一块炫技。

2. 从零开始的完整学习路线与技能矩阵

2.1 基础层：编程、数据与机器学习原理

很多想转AI工程的人，上来就学LangChain、学Prompt技巧，这其实是本末倒置的做法。工具每天都在更新，但底层的思维框架才是长期复利的资产。如果让我给一个“from scratch”的学习顺序，我会这么排。

首先是编程语言，Python仍然是AI领域事实上的标准语言，建议至少熟练使用它处理数据、调用库、写脚本。你不需要成为Python专家，但pandas、numpy这些基础库的操作要顺手，因为数据处理在AI工程里几乎是每天都绕不开的活。

其次是机器学习的基础概念。你不需要像算法工程师那样推导数学公式，但几个核心概念必须建立起直觉：什么是embedding（把文本变成向量）、什么是注意力机制（模型如何关联上下文）、什么是过拟合（模型死记硬背而不是泛化）、什么是温度参数（控制生成随机性）。这些概念直接决定了你后面理解模型行为、调优参数时的基本功。

然后是深度学习框架的基本使用，重点建议学PyTorch。因为当前主流开源模型的推理、微调、部署工具链基本都围绕PyTorch生态，你不需要精通训练，但至少能看懂加载模型、跑推理、保存权重的代码逻辑。我见过太多人跳过了这层，结果后来想微调模型时，面对transformers库的代码一脸懵，又得回头补课。基础打牢，后面的学习速度会快至少两倍。

2.2 工具层：LLM应用开发的技术栈选型

基础打完之后，就进入工具选型阶段。现在LLM应用开发的工具链已经很成熟了，但很多初学者最大的困惑是：工具太多了，到底该学哪个、不该学哪个？

我的选型原则很简单：工具是解决问题的，不是为了追新。下面按使用场景说一下我实际用过、并且在生产环境验证过的技术栈。

第一层是开发框架。LangChain和LlamaIndex是目前使用率最高的两个选择。LangChain的优势是生态丰富，Agent、Tool、Memory这些抽象齐全，适合做复杂交互流程；LlamaIndex则更聚焦在“数据接入和检索”这一块，对RAG场景的抽象做得更顺手。我的建议是：两个都上手跑一遍，理解彼此的优劣，然后选定一个主攻。不必追求“全会”，但要理解背后抽象出来的设计模式，因为它们解决的是共性的工程问题。

第二层是向量数据库。这是RAG系统的核心依赖。常见选项有Milvus、Qdrant、Chroma、Pinecone，还有国内常用的ES（Elasticsearch加向量插件）。选择依据不是看哪个热门，而是看你的部署环境：如果数据量小、本地开发，Chroma和Qdrant最轻量；如果数据量在千万级、需要分布式和复杂过滤，Milvus或ES更靠谱。我自己做中大型项目时倾向用ES，因为很多业务系统原本就有ES，可以一套基础设施同时支持全文检索和向量检索，减少组件运维成本。

第三层是模型推理和部署工具。国外项目用OpenAI API比较省事，但国内生产环境往往需要私有化部署或者通过合规渠道接入。开源方案里，vLLM和Ollama是两种风格：Ollama主打本地快速体验，安装简单、适合个人开发；vLLM主打高吞吐、生产级推理优化，支持PagedAttention等技术，适合服务化部署。如果你的并发量上来了，一定得学vLLM，吞吐量差距不是一点半点。

2.3 工程层：RAG、Agent、评测和可观测性

工具层解决的是“能做出来”的问题，工程层解决的是“做得好”的问题。这一层是AI工程和普通“API调用”真正的分水岭。

第一个关键词是RAG（检索增强生成）。它解决的是大模型“知识陈旧”和“幻觉”两大痛点：不重新训练模型，而是先从你自有知识库中检索出相关内容，再把这些内容拼进Prompt让模型基于它们回答。看起来很简单，但实际操作中检索质量、Prompt组织、引用溯源、上下文管理等每个环节都有无数细节。这部分我在第三章会详细展开。

第二个关键词是Agent（智能体）。如果说RAG是“让模型看到资料”，Agent就是“让模型动起来干活”。它让大模型能够规划任务、调用外部工具、观察结果、决定下一步动作。从单轮问答到多步任务执行，这是很多AI应用从“玩具”变成“工具”的关键跃迁。但Agent带来的不确定性也更大，生产落地时需要更严格的任务边界控制和失败兜底策略。

第三个关键词是评测和可观测性。这是业界最容易被忽略的一环。你需要一套系统化的评测集和指标，来回答“这版Prompt到底比上一版好在哪”“这个模型换得好不好”“线上回答的忠实度有没有下降”这类问题。同时，你要有trace能力，能看到每次请求走了哪些步骤、调用了什么工具、检索了什么内容、模型输出了什么、耗时多少、成本多少。没有这两样，AI工程就永远停留在“感觉好用”的玄学阶段。关于评测体系，我会在第四章重点讲。

3. 实操落地：从0到1搭建一个RAG问答系统

3.1 需求定义与场景拆解

讲再多理论都不如动手做一遍。这一章我带你完整走一遍RAG问答系统的搭建流程。我们选一个最常见的场景：企业内部知识库问答——比如让AI基于公司产品手册、技术文档、运维工单回答员工问题。

很多人一上来就急着写代码，但第一个应该做的是把需求拆清楚。我通常会先定义下面几个问题：用户会以什么方式提问？预期需要多长的回答？对准确率的最低容忍线是多少？可接受的响应延迟是几秒？文档总量有多大？更新频率如何？

这些约束直接决定技术选型。比如延迟要求小于3秒，那就要控制检索链路和上下文长度；文档量只有几千个chunk，那单机向量库就够了；文档每周更新，就得设计定时索引重建的机制。我强烈建议你在动手前先输出一页纸的技术方案，把上面的问题都写清楚。这一步能帮你避免后期90%的返工。

3.2 数据准备与切分：决定了效果上限

在AI工程里有一个被反复验证的规则：数据决定了系统效果的上限，模型和Prompt只是在逼近这个上限。RAG系统里，数据环节的核心是文档解析和文本切分（chunking）。

先说文档解析。企业文档格式五花八门，Word、PDF、PPT、Markdown、扫描图片都有。很多人在这里偷懒，用最简单的按页提取文本，结果表格信息错乱、代码块断裂、页眉页脚混入正文，检索效果自然好不了。我的经验是，针对不同格式要准备不同的解析策略：PDF用PyMuPDF或最新文档解析方案，表格用专门的表格抽取模型，扫描件需要先过OCR。这个环节最费时，但对后续检索质量和回答质量影响极大，值得花精力做扎实。

再讲文本切分。切分策略决定了一个核心问题：检索出来的片段是否是“语义自洽”的。如果把文档切得太碎，每个片段只有一两句话，模型拿到上下文却看不懂来龙去脉；切得太粗，一个片段里混了好几个主题，向量检索时就容易跑偏。

下面是我实际用过的几种切分策略对比：

我个人的偏好是：先用结构感知切分保住文档层级，再在内部用递归字符切分的逻辑控制块大小，最后叠加一些重叠（overlap）避免信息在边界处断裂。chunk大小我没有固定值，而是根据不同文档类型去实验。一般来说，中英文混合场景下300到500个token的chunk是常见的起点，但要结合测试效果调整。

3.3 检索与生成的串联实现

数据准备好之后，就进入RAG的核心串联阶段：召回（Retrieve）→ 增强（Augment）→ 生成（Generate）。

先说召回。最基本的方式是把用户的query也做embedding，然后在向量库里做相似度检索，取出TopK个候选chunk。但只用向量召回的话，有两个问题：一是纯向量检索对关键词匹配不敏感（比如型号、编号这种不该用语义去匹配的内容），二是相似度最高的chunk不一定是语义上最匹配的。我的做法是“多路召回+重排序”：不光做向量检索，同时还做关键词全文检索，然后把两路结果合并，丢给一个重排序模型（reranker）做精排。这样的召回质量会比单一向量检索稳定很多。实际上，很多生产级RAG系统的关键提升，不是来自换更贵的模型，而是来自这个“混合检索+精排”组合。

再说增强。召回得到的chunk不能直接全塞进Prompt，你需要做信息压缩和去重。常见的做法是：先合并来自同一文档的chunk，再过滤掉与query相关性过低的片段，然后按用户问题重新组织上下文顺序，确保最相关的信息靠前。这一步很多教程不会教你，但直接影响回答质量。另外不要忘了保留引用来源——在Prompt中要求模型回答时标注内容出自哪个chunk，这是企业知识问答里非常重要的一点。

然后是生成。生成部分的Prompt要清晰定义角色的任务边界、输出格式要求、引用规范，以及最重要的兜底策略：“如果上下文中没有相关信息，必须直接说明不知道，不得编造。”这个“承认不知道”的指令，是所有防幻觉手段中最简单有效的一道关。生成参数方面，我通常把温度设低一些（0.1到0.3之间），减少不必要的随机性。但注意，RAG系统的回答质量，很大程度上还是由前两步决定的：召回没有好内容，Prompt写得再漂亮也生不成正确答案。

3.4 部署与性能优化

系统在本地跑通之后，部署和性能优化就是上生产前最后一道工序。

首先是模型部署。如果你用的是API模式（比如通过国内合规的模型API服务），部署相对简单，重点要考虑的是接口稳定的调用封装、超时重试、备选模型切换。如果你做的是私有化部署，用vLLM起一个兼容OpenAI格式的服务，并配置好显存分配和并发上限。需要特别关注的是首Token延迟和吞吐两个指标：前者决定用户体感，后者决定单位成本。

然后是性能与成本优化。生产环境与本地开发最大的区别是并发和成本压力。我常用的几个优化手段：

• 缓存：对高频相似问题做语义缓存（基于query向量相似度命中复用答案），能减少大量重复调用。
• 模型路由：不是所有问题都需要最贵的模型。简单问题走原来的轻量模型，复杂问题走最强大的模型，可以用一个小分类器做自动路由，成本能降很多。
• 流式输出：打开流式输出，让用户先看到文字逐字出现，体感延迟会大幅降低，不需要硬扛首字节延迟。
• 异步处理：离线任务用异步队列，避免阻塞在线请求。

生产环境RAG系统的成本大头通常在embedding调用（文档量大时）和大模型生成调用，缓存和路由这两招组合用下来，实际成本能减少30%以上，这是我多次实测下来的数据。

4. 评估体系：没有评测就等于盲人摸象

4.1 为什么必须构建自己的评测集

上生产之前不做评测，是我见过的AI项目翻车的最常见原因。通用基准（比如公开的评测集）只能作为选模型时的参考，但并不能代表你的业务场景。你的知识库内容、用户的提问习惯、期望的回答风格，可能和公开基准的分布差异非常大。

所以你需要构建自己的评测集。我建议从真实使用场景里收集数据，比如从测试用户、内部试用员工、历史客服工单中整理100到300条典型问题。数量不需要多，但每一条都要做好标注：问题、标准回答、应引用的文档范围、回答的关键要点。然后你每次改动Prompt、调整检索策略、更换模型，都可以跑一遍评测集，量化对比效果变化。

这个动作的价值，是把“我觉得变好了”变成“指标上从75分涨到了82分”。有了这个基准，你做任何改动时都有信心，不会再出现“改了一版Prompt，感觉有点不一样，但说不清好不好”的尴尬境地。

4.2 自动化评估与人工评估怎么结合

评测集有了，具体怎么打分？我通常分两层次。

第一层是自动化指标。现在业界常用的RAG评测框架（比如RAGAS），会计算几个关键指标：忠实度（答案是否严格基于检索内容）、相关性（答案和问题的关联度）、上下文精确率（检索出的内容是否刚好够用）。这些指标可以通过LLM-as-judge的方式自动打分，速度快、成本低，适合每次迭代时做回归测试。

第二层是人工评估。自动评估解决“有没有跑偏”的问题，但“好不好用”这件事还是需要人来看。我的做法是每周从真实线上问题中抽样20到30条，人工对回答质量打三个维度：准确性、完整性、体验感。人工评估的结果再反馈到评测集里，持续扩充数据集覆盖度。

可观测性在这里也同样重要。我会在系统中接入trace链路，记录每次请求的完整路径：用户问题、检索出的chunk ID、送入Prompt的内容、模型的输出、token消耗、每一步的耗时。一旦线上出现用户投诉“答得不对”，就可以通过trace快速定位，问题出在检索环节还是生成环节。这个排查效率，决定了一个AI系统后端维护成本的高低。

5. 踩坑实录与常见问题排查

5.1 高频问题速查表

写了这么多，说几个实际项目中高频出现的问题和我的排查思路。这些都是“上面没写但实践中一定会遇到”的教训。

5.2 从RAG单点功能到AI Agent平台

把RAG做扎实之后，下一个自然的方向是往Agent演进。很多业务场景不满足于“问答”，而是要求“干活”：比如让AI帮你查一下订单状态、拉取某份报表、按规则生成一段内容并发送到某个系统。这就是Agent的价值。

但Agent的工程复杂度比RAG高一个量级。核心要把握三个点：一是工具定义要清晰。每个tool的输入输出参数必须严格定义，最好是schema化的，让模型能准确理解“调这个工具要传什么参数”；二是决策边界要有限制。不要让Agent无限规划，要设置最大步数、超时时间、关键节点的强制确认机制；三是错误处理要完善。工具调用失败时，Agent要有重试、换路、放弃并告知用户的兜底逻辑，而不能无限死循环。

从RAG到Agent的过渡，并不需要推翻已有系统。RAG本身就是Agent的一个工具能力。你可以在现有问答系统外面包一层Agent编排，让模型判断用户意图：需要查资料时走RAG，需要操作时走工具调用。这个“保留RAG核心，向上扩展Agent能力”的演进路径，是我见过最平滑、也最容易出成果的方向。

5.3 给后来者的一些实在建议

最后说点掏心窝的话。AI工程这个领域变化太快，今天学的东西明天可能就更新了一版，但这不应该是你不动手的理由。我的经验是：选一个小而真实的场景，把一个RAG系统完整跑上线，胜过刷一百篇技术文章。从小场景里长出来的评测集、踩坑经验、部署流程、成本数据，才是真正可以复用到下一个项目的东西。

另外，每次技术选型的时候，多问一句“它解决了什么问题”。如果回答不出具体的业务价值，那大概率是被新技术带着跑了。AI工程的核心不是追着最时髦的框架跑，而是让系统在可控的成本内稳定解决业务问题。这一行没有银弹，但有一套经过验证的方法论，把这个方法论打磨成本能，往后碰到任何花哨的新框架，你都有一双能看透本质的眼睛。