企业官网建设流程全解析

很多人问我“AI工程从零开始”到底怎么起步，我通常先反问一句：你做这个，是想成为训练模型的研究型选手，还是想把模型真的用起来、跑起来、持续迭代起来？如果是后者，那你和我现在做的事基本一样，都属于AI工程这条路。

这几年AI工程这个岗位很微妙，很多人把“会调API、会套提示词”当成全部，也有人一上来就啃神经网络论文，结果学了半年还在原地打转。我的理解是，AI工程的核心不是“发明模型”，而是“让模型在真实业务里稳定干活”。今天这篇文章不打算给你列一堆课程链接，也不做那种“30天精通AI”的唬人承诺，我尽量用自己的真实项目经历，把“从零开始”这几年踩过的坑、摸索出的路，拆开了讲给你听。如果你正准备入行、刚接手AI项目，或者想把手头业务跟大模型结合，这篇文章会比较对胃口。

另外先说明白，我这里聊的“从零”，不是从高等数学的零开始，而是从“能动手、能出结果”的零开始。理论基础当然要补，但顺序和方法非常关键，顺序搞反了，你会学得很痛苦而且看不到成果。

1. 先把“AI工程”这个词拆明白

1.1 AI工程师和研究员、算法工程师的分工边界在哪

很多人看到“AI工程”四个字，第一反应是“又要写神经网络了”。实际上AI工程更接近“搬运工+装修工+监理”的综合体。研究员的工作是探索新模型结构，算法工程师的战场是模型训练与调参，而AI工程师的核心精力往往花费在数据管道、模型调用的稳定性、推理成本、效果评测和上线后的持续监控上。

举个真实例子，我之前接过一个任务，要把公司十几份产品手册做成内部问答机器人。研究员不需要关心这个问题，算法工程师研究的是怎么微调一个开源模型来做这件事，而我会优先考虑：文档怎么清洗、切片策略怎么定、用哪种向量库、检索回来以后提示词怎么组织、模型推理延迟能不能压到两秒以内、误答了用户投诉怎么办。这个项目最终的瓶颈完全不在模型能力，而在检索召回率和稳定性——这正是AI工程要解决的事。

还有一层经常被忽视：AI工程是连接业务和技术的那层“胶水”。你得能跟业务方聊清楚“什么能做、什么做不到”，也得能跟后端同事解释“为什么这个接口偶尔会超时”。所以我的经验是，入行第一课学的不是PyTorch，而是“搞清楚角色边界”，知道自己该在哪层发力。

1.2 从零开始，真正要练的是这三件事

既然角色边界清楚了，那从零开始练什么就呼之欲出。我自己的总结是三个能力：第一，数据获取与处理能力。模型是嘴，数据是饭。你给模型吃什么，它就只能说什么。清洗数据、格式统一、去重、切分，这些活看起来不起眼，却决定了项目成败。第二，模型调用与集成能力。不管是API接口还是本地模型，你得知道怎么稳定地调用、怎么处理超时、怎么做并发控制、怎么降级兜底。第三，评估与迭代能力。没有评估就没有迭代方向。你能说出“现在的准确率比上周高了多少”，才算真正开始做AI工程。

这三件事对应到实操上，就是你会反复摸到Python脚本、HTTP接口、JSON结构、日志分析和一点统计学常识。而写模型训练代码反而是阶段性需求，不是每天都必须上手。

注意：这里说的“从零”，我默认你至少会基本的Python语法和Linux命令。如果这两样还不熟，先花两周补上，别急着碰任何AI框架。

2. 基础技能怎么补才不跑偏

2.1 数学和统计：不要恐惧，但也不能完全跳过

很多人一听AI就想起高等数学、线性代数、概率论，吓得直接放弃。我的建议是分阶段学习，第一轮不需要达到应试水平，只需要“看得懂公式、说得出含义”。比如向量点积，你不需要推导它的几何性质，但要知道它衡量两个向量的相似程度，因为后面所有向量检索都建立在这个概念上。矩阵乘法也一样，你不需要手算，但要明白它就是把一组特征变换到另一组空间，模型的每一层都在做这个事。

概率统计比较重要，但也不需要啃数理统计教材。重点理解分布、均值、方差、条件概率，尤其是贝叶斯思想：你对一件事的判断，会因为新增证据而更新。模型的“幻觉”问题，本质就是一种概率生成过程，理解了这种不确定性，你就知道为什么模型不能保证每个字都准确，为什么要在工程上设计兜底逻辑。

我的学习方式是“逆向学习”：先看一段代码，发现理解不了某个参数，再回头补对应的数学概念。比如看到Embedding向量的维度是768，就回头理解一下为什么高维空间能表达语义相似性。这样学得快、记得牢。

2.2 Python生态和学习路径：以项目驱动而非知识点驱动

我强烈不建议按“Python基础→Numpy→Pandas→机器学习算法→深度学习”这个顺序一路学到底，因为九成的人会在机器学习算法那一步失去动力。换成“项目驱动”会好很多。你可以给自己定一个目标：两个月内搭出一个能跑通的知识库问答小系统。围绕这个系统，你用Python处理文档、用Pandas清理数据表、用Requests调用接口、用FastAPI写一个应用入口，这些技能点都是自己冒出来的，学起来效率极高。

深度学习框架方面，我建议首选PyTorch，并不是因为别的框架不好，而是它生态最大，遇到问题搜索时容易找到答案。入门时别急着训练模型，先把“加载一个预训练模型并做推理”跑通，再尝试简单的微调。这一步做出来，基础模型训练的流程你就走了一遍。至于Transformer结构，知道自注意力机制大概在干什么就行，不用一开始就手写注意力层。

提示：环境配置往往是新手第一道墙，建议直接装Anaconda管理Python环境，每个项目创建独立虚拟环境，避免依赖冲突。这个习惯我从入行第一天保持到现在，拯救过无数个周末。

2.3 一套顺手的工具栈，从第一天就养好习惯

工欲善其事，必先利其器。我推荐的起步工具栈是：Git做版本管理，Jupyter Notebook做探索分析，VS Code做日常开发，Docker做环境打包。这四样东西看起来跟AI没什么关系，但每一项都能在项目关键节点救你一把。

Git不多说了，代码回溯、多人协作都离不开。Jupyter Notebook适合做数据分析、调试提示词和对返回结果做可视化诊断，它的交互式特性让你能一边跑一边改。VS Code加上Python插件后，调试和代码补全体验足够流畅。Docker一开始可能觉得难，但我建议尽早接触，因为模型依赖非常复杂，六个环境变量、三个CUDA版本对不齐是常态。把环境写进Dockerfile里，换机器跑的时候能少掉一层皮。

除了这些，你还需要一个实验管理工具。简单项目用Excel记录就行，参数、数据集版本、效果得分写清楚；复杂一点可以上MLflow、WandB或者类似工具。没有实验记录，你调了三天的参数后会发现完全忘掉了哪组效果最好，那种挫败感我体会过太多次。

3. 完整实操：从零搭一个RAG知识问答系统

3.1 任务定义与数据准备

纸上谈兵没意思，我拿一个真实项目做样板：做一个基于公司内部产品文档的知识问答系统。为什么选RAG而非微调？主要原因有三个。第一，文档内容持续更新，微调一次模型成本高，而RAG只需要换文档库。第二，RAG生成的答案可以引用原文，方便用户核对，这在内部场景非常重要。第三，初期我们并不需要模型具备新的推理能力，只需要把已有知识准确提取出来，RAG对这种“知识密度高、推理复杂度低”的场景高度匹配。

数据准备阶段比想象中花时间。文档格式很杂，有Word、PDF、Markdown，还有扫描件。我的处理顺序是：先统一转成文本，再用脚本清洗页面页眉页脚、目录和乱码字符。这里有一个容易被忽视的细节：PDF转文本后经常出现断行混乱，如果直接切块，语义会被破坏，检索效果会很差。我的办法是先按段落边界重组文本，再做下一步。

切块策略上，我推荐“标题感知切块”。简单说就是优先保留完整章节，把文本按标题层级拆分，控制每块在500到1000字之间，块之间可以保留少量重叠。这样做的好处是，后续检索命中的往往是一个语义完整的片段，生成答案时上下文不会东拼西凑。

3.2 向量化与检索实现

数据准备好以后，下一步是把文本块转换成向量。这里有两种思路：用商用Embedding服务或本地开源模型。商用服务效果好、省心，但涉及外部网络和费用；本地模型部署自由、隐私更有保障，但效果需要调。我这个项目最终选了本地方案，用的是一个中等规模的Embedding模型，输出向量维度是1024。切换模型的代价比想象中大，因为不同模型的向量维度不一样，一旦上线后要换模型，整个向量库都得重新生成，所以选型时尽量一次到位。

向量化之后需要一个存储和检索的介质。数据量只有几万块文本时，用FAISS就够了。它跑在内存里，检索速度极快。构建索引时就几个步骤：把向量喂进去，指定相似度度量方式，保存索引文件。我自己常用的是点积或余弦相似度，具体选哪个看Embedding模型训的时候用的是什么，没有绝对优劣。

检索环节有一个标准代码之外的技巧，叫“混合检索”。仅靠向量检索，遇到专有名词、型号编号这类精确匹配场景很容易翻车，因为向量相似度讲的是“语义相近”，不是“字面相同”。我后来在向量检索之外加了一层BM25关键词检索，把两种结果做加权融合。效果立竿见影，用户问“XK-200型号的功率是多少”时，字面匹配立刻能命中原文。

# 简化的混合检索流程 # 1. 向量检索 vector_scores = vector_index.search(query_vector, top_k=20) # 2. 关键词检索（BM25） keyword_scores = bm25_index.search(query_text, top_k=10) # 3. 结果融合（简单加权+去重） merged = merge_results(vector_scores, keyword_scores, weight=(0.7, 0.3))

这一步走下来，我最大的体会是：不要迷信某一个检索方案的宣传效果，组合拳远比单点最优靠谱。工程里最终看的是整体命中率，而不是某一个环节的完美。

3.3 生成链路与提示词设计

检索出来的文本块不会自动变成答案，需要交给生成模型组织语言。这个环节的关键有两个：提示词结构和上下文控制。提示词我用了一段固定的System指令，明确告诉模型“你是文档助手，只能根据提供的资料回答，资料里没有的内容就说不知道，不要编造”。这段指令看起来简单，但确实能明显降低幻觉比例。

控制上下文长度同样很重要。模型输入有Token上限，我的策略是：检索结果的文本块拼接后，按字数截断到模型可接受的输入范围，同时保留引用来源。这里有个常被忽略的问题：文本块之间的顺序影响模型输出质量。我一般把相关度最高的块放在最后，因为部分模型会对输入末尾的内容更敏感，这个操作在多次测试中都有正向收益。

生成阶段还涉及一个隐蔽问题：重复请求。在线问答场景里，用户可能会反复问同一类问题。缓存策略可以省很多成本。我的做法是，把“规范化后的问题句式+检索到的文档块ID列表”作为缓存的Key，如果后续命中的文档块没变化，就直接复用之前的生成结果。如果文档库更新了，就让Key自动失效，避免旧答案污染。

3.4 评估指标与上线部署

效果好不好，不能靠拍脑袋。我的评估方法分两层：离线评估和在线监控。离线阶段准备一份带标准答案的测试集，大概一两百条问题就够，覆盖不同来源和问法。然后计算三个指标：命中率（检索结果是否包含关键信息）、答案准确率（生成答案和标准答案语义是否一致，这里需要人看，也可以辅助模型打分）、拒绝率（模型对未知问题说“不知道”的比例是否合理）。这些指标跑完，基本能判断系统能不能见人。

在线监控又是另一套逻辑。在接口层记录每次请求的检索延迟、生成延迟、Token消耗和返回状态。答案本身的质量在线上不太容易自动化判断，可以加一个用户反馈按钮，也可以在下游做一个“内容漂移检测”——对比用户问到的问题和答案之间的相关性，相关性异常就提醒人复核。

部署阶段的标配是FastAPI加Docker。模型服务单独拆成一个进程，业务API调它，这样如果模型服务崩了，业务层还能返回友好提示而不是直接超时。GPU资源的分配我当时很头疼，因为推理服务很吃显存，但业务API只需要CPU。后来把两部分拆到不同容器，配合进程级并发控制，才把资源利用理顺。上线之后，我每天早晨第一件事是看昨天的监控指标，而不是等用户投诉。

4. 踩坑实录：几个最容易翻车的地方

4.1 切片策略不佳导致检索结果永远不准

我调过最久的一个Bug，是某类问题怎么调都检索不准。排查了很久，最后发现根源是切块太机械。有些文本块从一句完整的话中间断开，语义被切断，向量化之后整个块的意义都偏了。检索模型看着觉得这块跟问题不相关，自然不返回。

后来我改成按段落和标题先做Luneng早先的重组，再把长段落拆成有边界的子块，块与块之间保留约50到100字的重叠。这个改动上线后，命中率直接涨了十几个百分点。我想表达的是，检索效果差的根因经常不在检索本身，而在上游的文本切分质量。你要是遇到检索差，先别急着换Embedding模型或调索引参数，回去看看自己切出来的文本块长什么样。

4.2 生成答案“看起来很对，实际在胡扯”

很多RAG系统都会遇到这个问题：检索回来的资料里根本没有答案，但模型还是答得一本正经。这就是幻觉的典型形态。我的处理办法是三层防线。第一层在提示词里反复强调边界，资料没有就直说；第二层在代码里做“证据检验”，检查答案中的关键实体是否在检索回的文本块中出现，没出现就拦截；第三层是对高风险的问答类型放宽门槛，比如数值类问题，要求必须引用原文中的具体数字才能放行。

三层防线叠加以后，幻觉比例降到了一个可以接受的区间。注意，我这里说的是“降低”不是“消除”，任何做大模型应用的人都应该对“绝对可靠”保持警惕，工程手段只能逼近，不能等于。

4.3 成本失控：一次批量任务花了没必要的钱

我接手过一个批量分析任务，需要把一万多条客户反馈交给大模型做分类和总结。最初直接用长文本反复调用，成本高得吓人。后来做两件事：第一，把每条反馈先压缩，只保留关键句，能把输入Token减少一半多；第二，对相似反馈做去重，同模板的反馈只跑一次。就这么两个改动，成本降到原来的四分之一。

预算控制是AI工程里永远躲不开的命题。我的习惯是每个上线功能申请资源前，先按最坏情况测算Token消耗，写在接口文档里。同时给模型调用加两层限流：用户维度限流和功能维度限流。别等功能被刷爆了才想起要做限流，那会儿账单已经出来了。

4.4 混合检索的权重与阈值也要调，不是配好就能用

前面提到混合检索效果好，但它也不是开箱即用。我调试初期，向量和关键词的融合权重是瞎拍的，结果有的问题拼命命中关键词，有的问题完全被高频词带偏。后来我用测试集做了小范围网格搜索，把两个检索通道的结果都做了归一化再融合，效果才稳定下来。

还有一个细节：不要把向量检索的Top K设得太大，否则生成阶段的输入会被低质量文本块污染。也不要设太小，否则漏召回会成为常态。具体数值因文档库而异，但大概范围可以体会一下：几百到几千条文本的库，Top K取5到10比较常见。

5. 在真实项目中继续成长的一些建议

聊了这么多实操细节，最后想说几句“如何持续成长”的真心话。

AI工程这个方向更新太快，今天还在用的框架，明天可能就出了新的替代品。我的应对方式很朴素：每个季度给自己立一个“新东西验证”任务，比如新的推理框架、新的OCR工具、新的评估方法，用一周时间做小规模试用，并写一份给它“找茬”的记录。这个习惯让我面对技术演进时心态比较稳，因为真正吃透过一个工具后，再看同类工具会快很多。

还有一点我特别想强调：写文档写总结不是浪费时间，而是修炼。每次项目复盘，我必写三段：哪里做得好、哪里做得差、下一次会怎么做。这些笔记是我自己的私人知识库。刚入行时我觉得写文档耽误写代码，后来才发现，代码会过时，而经验不会。

如果你也在从零开始走这条路，我希望你记住一个朴素的原则：不要跟风追逐每一个新词，找一个真实场景的小问题，用AI老老实实解决它，把全流程走通。一个完整的、虽然小的项目，胜过十本只翻了一半的书。技术栈可以慢慢替换，你的工程判断力才是真正值钱的东西。等到能独立把一个AI项目从想法带到上线，并让它稳定跑起来，你那时候回过头来看，会发现这个“从零开始”的起点，已经在不知不觉中甩开了一大截。