企业官网建设流程全解析

大模型聊了两年，各家发布会看了无数轮，参数越卷越大，榜单刷了一波又一波。但真到了自己负责的产品里，你发现吹过的牛全变成了具体而琐碎的问题：部署在哪个环节、该用多大参数的模型、幻觉怎么处理、业务方要的“精准回答”到底怎么做、成本摊到每个用户头上是多少钱。我这两年带着团队帮不同行业做了不少LLM落地的项目，最大的感受是：阻碍LLM落地的从来不是模型能力，而是大家对“从模型到产品”这条链路缺乏一个系统化的实操认识。

这篇文章不聊论文，不吹架构，只讲我在实际项目里怎么选型、怎么搭RAG、怎么调Agent、怎么准备垂域数据，以及真正上线时会踩哪些坑。目标读者是那些手里有产品、有业务场景，想把LLM接进去但还没想清楚“第一步迈哪只脚”的团队。文章会比较长，因为每一段后面都是真金白银的教训。

1. 先从根上想清楚：LLM在你的产品里到底扮演什么角色

很多团队第一步就搞反了——先选模型，再想场景。正确做法是先定义清楚LLM在你的产品里解决什么问题，这会直接决定后面所有的技术选型。

1.1 四个定位决定了完全不同的技术路线

我习惯把产品里的LLM角色分成四类：

• 对话中枢：用户直接和模型对话，典型如客服机器人、AI助理。这类场景对交互体验、响应速度要求极高，现在通常用Agent架构来组织。
• 内容生成器：帮用户写文案、总结报告、生成邮件。对输出的格式稳定性要求高，需要强指令约束。
• 语义理解引擎：不直接面向用户，而是在后台做分类、抽取、情感判断。这类是当前ROI最高的落地方式，因为出错的影响可控。
• 流程决策大脑：模型自主决策调用哪些工具、走哪条业务逻辑。比如AIoT里的智能家居管家，模型根据用户模糊指令编排设备联动。

这四个定位对应的工作量天差地别。最稳妥的切入点是“语义理解引擎”，因为它不需要模型输出长篇大论，容错率高，可以先用小参数模型跑通。最需要谨慎的是“流程决策大脑”，因为一旦让模型做自主决策，就必须配套完整的安全护栏和回退机制。

我见过一个典型的反面案例：某团队想做智能客服，上来就采购了市面上最大的商用模型，结果每次调用的成本是行业均价的几十倍，响应延迟还让用户反复催单。后来我们把场景拆成意图识别、知识检索、话术生成三段，前两段用开源小模型本地部署，最后一段才调用大模型，整体成本直接降了一个数量级。这就是“角色定位决定方案”的典型体现。

1.2 “大模型万能论”为什么会让项目烂尾

现在行业内有一种风气，觉得LLM什么都能干，什么场景都往里塞。这种“万能论”是项目烂尾率最高的原因。我拆解过一些失败项目，共性惊人的一致：团队没有想清楚“模型回答错了会怎样”。

以法律咨询为例，模型给合同纠纷给错了建议，用户真去起诉，责任算谁的？以医疗为例，模型推荐错了用药方向，出了事故谁兜底？这不是技术问题，是产品定责问题。一个可以承担部分错误的产品和一个绝对不能出错的产品，技术方案完全是两套。

所以我的建议是：先盘点你产品里的所有需求，按“容错率”分级，优先做容错率高的场景。比如新闻资讯的摘要、非敏感数据的分类、辅助人类决策的打标，这些场景就算错了也有办法兜底，适合做LLM的“试验田”。等团队积累够RAG调优、Agent编排、模型微调的真实手感，再逐步向高容错率要求的核心业务推进。

2. 选型：到底用闭源API还是开源模型私有化部署

选型是项目里第一个让团队吵架的环节。技术负责人想私有化保障数据安全，业务负责人想快速上线选商用API，财务在旁边看成本预算。我的经验是：这个决策不需要纠结太久，因为两者之间的差距正在快速缩小，但有一个判断标准特别实用——你的业务数据是否允许出域。

2.1 开源闭源的决策树和真实成本账

先给一张我实际做项目时用的选型参考表，是我自己整理的经验值，不同地区价格有差异，但结构是通用的：

如果你问我要一个更简单的决策规则，我会说：日均调用量低于10万次，闭源API通常更划算；超过这个量级且数据敏感，私有化部署的性价比开始凸显。这不是精确的数学公式，而是我做过多次成本测算后的经验判断。闭源API的综合成本不只是调用费，还包括你为合规做的数据脱敏改造、审计系统的开发成本。

有个做企业知识库的客户让我印象很深。他们一开始用闭源API，每个月账单在6位数，而且每次大版本升级Prompt就失效需要重调。后来我们把36B参数的开源模型部署到两台8卡机器上，一次性硬件投入虽然大，但三个月后综合成本已经低于API费用，关键是再也不用担心哪天API策略调整导致产品停摆。核心权衡逻辑是：短期项目用闭源，长期产品自建。

2.2 参数量不是越大越好：7B、14B、72B怎么选

大模型领域有一个普遍误区：参数越大越聪明，所以我选最大的。现实是：“够用”比“最强”重要得多。我自己的项目经验可以分享几个参考值：

• 7B-8B级别（如Qwen2.5-7B、Llama3.1-8B）：意图识别、文本分类、信息抽取、简单的格式转换。单张消费级显卡即可部署，延迟极低，适合高频调用。
• 14B-32B级别（如Qwen2.5-14B/32B、GLM-4-9B）：复杂指令跟随、多轮对话、有一定推理要求的场景。需要一张48G或两张24G的显卡，是“性价比甜点区”。
• 70B级别及以上：复杂推理、深度分析、长文本理解。至少需要4张以上48G显卡，推理成本较高，适合对答案质量极度敏感的垂域场景。

这里有个反直觉的经验：小模型的“调教潜力”被严重低估了。在特定垂域任务上，一个经过精心微调的7B模型，效果可以接近甚至超过通用大模型。因为垂域数据的高质量指令能让小模型把参数专注在特定模式上。所以选型时别只盯着参数，先评估你手里的数据质量、标注能力和场景复杂度。

从另一个角度看，参数量选择本质是“智能密度”的权衡。最近行业里的趋势是所谓“小而专”的模型越来越能打。你有个做合同审查的场景，用72B的通用模型和用基于千条高质量标注微调过的7B模型比，后者在合同条款识别这个单一技能上反而可能更强、更快、更便宜。这就是垂域模型存在的意义。

2.3 量化、上下文长度和推理框架的经验值

选定模型后，具体部署时还有几个关键参数。我直接给结论和踩坑经验：

量化。如果追求极致性能，优先考虑4-bit量化（如AWQ、GPTQ或GGUF的Q4_K_M)。4-bit下模型显存占用约为原始FP16的四分之一，推理速度提升明显，质量损失通常是可接受的。但注意，如果任务涉及代码生成、数学推理、长文档复核，建议至少保留6-bit或8-bit。另外我自己用的习惯是跑一批测试集做量化前后对比，别拍脑袋决定。对比维度包括：关键指标是否变化、生成格式是否稳定、长文本下是否更容易“胡说八道”。

上下文长度。开头和结尾最容易被模型重视，中间部分容易“迷失”。所以长文档场景务必配合“引用溯源”，强迫模型在回答中引用原文片段，既能缓解幻觉，也方便用户复核。还有一个小技巧：上下文窗口不是越长越好，过长的输入会让生成质量下降，因为注意力被分散了。对大多数场景，4K到8K的输入足够，除非是做文档级分析。

推理框架。通用推荐vLLM，吞吐量高、兼容性好。需要注意vLLM对显存的管理策略比较激进，建议关闭自动显存分配，手动设置gpu-memory-utilization为0.85-0.9更稳定。轻量场景可以考虑Ollama或llama.cpp，胜在部署简单。如果是超大并发生产环境，需要做张量并行和流水线并行时，可考虑TensorRT-LLM，它针对NVIDIA显卡有更深的优化，但配置复杂度也更高。

3. RAG：让模型“用数据说话”的完整工程链路

RAG（检索增强生成）几乎是目前把LLM落地到企业知识库、智能客服、文档问答场景的必选方案。但很多团队以为RAG就是“向量数据库+Prompt拼装”，结果做出来的效果不如直接用搜索引擎。原因很简单：RAG的坑不在架构，而在各种细节的串联。

3.1 文档解析和切分的那些细节

RAG链路的第一步是知识库数据准备，也是决定效果上限的一步。这里最大的坑是“格式丰富陷阱”。很多团队拿到一堆PDF就急着灌进向量库，结果答案质量惨不忍睹。真实场景中我会按这样的优先级处理源文档：

1. 优先拿原始电子文档（Word、Markdown、HTML），比拿PDF去解析强一个数量级。
2. PDF优先用带文本层的，不要用扫描件。扫描件需要OCR，而OCR对表格、公式、多栏排版的识别错误会传导到RAG检索阶段。
3. 表格结构尽量转成Markdown表格或HTML表格，转成纯文本后列对齐信息丢失，检索效果明显变差。

切分策略上，我总结的规律是：固定窗口切分是最差方案，虽然它最省事。固定按512个字切，把一段完整的业务逻辑拦腰截断，检索时就找不准。更好的做法是“按语义结构切分”——先按文档的标题层级（H1、H2、H3）分块，块内如果太长再结合段落和句子边界处理。块与块之间保留一定重叠（通常50-100个字符），防止边界处语义断裂。

关于chunk大小给一组经验值：面向“定位型问答”（问某个具体数值、条款）的，chunk建议256-512个字符；面向“综述型问答”（总结某章节内容）的，chunk建议1024-2048个字符。这不是死标准，你要根据实际检索结果的命中情况反复调。还有个小窍门：chunk里可以手动加上“标题链路”，比如“某合同/第三章/违约责任/第三款”，让模型能理解这个chunk在整体结构中的位置，大幅度提升回答准确性。

3.2 Embedding模型选择和混合检索策略

向量化模型是RAG的另一个关键组件。这个领域变化非常快，我的建议是放弃“追求SOTA”的心态，专注三个要素：领域适配度、向量维度、中文本地化支持。

领域适配度是指模型对你业务领域文本的理解能力。通用Embedding模型在财经、法律、医疗这些专业术语密集的领域表现都不算好。如果你所在的行业比较垂直，建议用行业语料对Embedding模型做二次训练，这个技术叫“领域自适应对比学习”，实现起来比微调LLM简单，但收益非常显著。

向量维度和索引性能相关，维度越高越占内存，检索越慢，但通常效果越好。看你的数据规模：百万级以下，512维够用；几百万到千万级，考虑256维或加降维。索引方式上，绝大多数场景用HNSW（分层导航小世界）就够，配置M=16、efConstruction=100起步，检索时efSearch设到检索量级的合理范围。

但我必须强调：纯向量检索撑不起生产级RAG。正式项目一定要做混合检索——向量检索捕捉语义相似，BM25或全文检索捕捉关键词命中。现实情况是很多用户问的是代码标识符、型号、编号、人名这类“字面精确匹配”的信息，语义相似的向量检索反而找不到。混合检索再把两部分结果用RRF（倒数排名融合）合并，实测下来的效果每一次都比纯向量检索好。

3.3 重排：最容易被忽视却最值钱的一步

我发现很多团队做RAG到混合检索就停了，直接把Top-K结果丢给大模型。这导致了一个尴尬：检索召回了正确相关内容，但因为答案在第三四位，前面的噪音干扰了模型，最终输出并不理想。解法就是加一个重排模型（Reranker）。

重排模型的原理说起来简单——把检索回来的几十条候选重新按相关度精排一遍。但它的价值巨大，因为粗排（向量检索）追求的是效率，精排（重排）追求的是准确度。我实测过的典型场景里，加一个重排模型，首位命中率能提升20到30个百分点，这个提升幅度在NLP任务里非常可观。

实操上注意几点。重排模型的输入通常是“查询+文档”对，计算量比向量模型大，不要用来跑全库检索，只处理粗排后的Top-50结果就好。生产环境可以把它单独部署到GPU上，加一层缓存，相同的查询直接命中。重排模型同样有领域适配问题，如果你的业务术语很专业，考虑在领域数据上微调重排模型。当前中文场景里有不少开源重排模型，选择标准是看它在你要用的领域数据上的表现，而不是刷榜分数。

3.4 RAG效果调优的“三板斧”

如果你的RAG问答效果还不满意，按这个顺序排查，90%的问题能解决：

第一板斧看召回质量。先在库里搜索一个你确定有标准答案的问题，看相关chunk有没有被召回。没召回，问题在切分或Embedding；召回了但不对，问题在重排。这一步可以借助向量检索界面直接观察Top-K结果，不用反复调用完整链路。

第二板斧看上下文组织。召回对了但模型答不上来，大概率是Prompt里给模型的上下文太乱。我的做法是把召回结果按相关度排序，附上文档来源标签，在Prompt中明确告诉模型“优先依据带[高相关]标签的内容回答，内容冲突时说明冲突”。给模型一条清晰的使用逻辑，比堆砌更多片段更有效。

第三板斧看答案评估。用一套固定的测试集持续回归。测试集至少100条真实用户问题，覆盖正常问法、模糊问法和刁钻问法。每次调参后跑一遍，看正确率变化。不要凭感觉认为“这次效果好像变好了”，要用数据说话。

4. Agent：别急着给产品加“自主决策”

Agent是LLM应用里听着最性感、落地最容易翻车的话题。所谓Agent，本质是让模型作为“大脑”，根据目标自主调用外部工具、规划步骤和执行动作。这个方向确实能解决很多复杂任务，但我的态度很明确：先在受控环境里跑通工具调用，再谈自主规划。

4.1 工具调用的工程化实现细节

大多数Agent框架（LangChain、Dify、Coze等）底层原理一致：把外部功能封装成“工具”，每个工具有明确的名称、描述和参数Schema，模型根据用户指令选择工具并回填参数，程序收到参数后执行真实逻辑。

这里面最容易忽略的是“工具描述”的质量。很多团队写工具描述极度敷衍，比如“获取天气”。模型是靠描述理解工具的，它不知道这个工具能干什么、参数怎么填、什么场景下用。好的工具描述应该长这样：“获取指定城市当前天气情况，支持中文城市名和经纬度坐标，返回内容包括温度、湿度、风力和降水概率，适用于用户询问天气、出行建议、穿衣建议时调用”。描述越准确，模型选对工具的概率越高。

参数Schema同样要精细。类型要严格（integer就是integer，别填成string）、必填项要明确、取值范围要给枚举或正则约束。实际环境中很多工具调用失败都是参数非法导致的，这不是模型笨，是你在Schema设计上就给错误留了门。

4.2 ReAct模式的两条安全红线

当下Agent任务规划的主流范式是ReAct——让模型先思考（Reason），再行动（Act），循环进行。这种模式在演示Demo里非常酷，模型可以自己拆解任务，逐条调用工具，最后汇总结果。但在生产环境里，有两个安全红线必须提前设防。

第一个是动作白名单。模型能调用的工具必须经过严格审批，默认最小权限。比如你做智能家居的AIoT agent，模型可以控制灯光、空调、窗帘，但绝不能让模型有权限执行“删除用户配置”“修改安全密码”这类高风险动作。白名单机制要在产品架构层做硬约束，不能只靠Prompt告诉模型“你小心一点”——LLM的指令遵循能力在多轮复杂对话里会下降，你依赖它的自觉就等着出事。

第二个是流程步数上限。给Agent的整个任务循环设一个最大步数（比如10步），超过就强制停止并切换到人工兜底。这是防模型进入死循环的关键保险。我见过一个真实案例：Agent要查一个订单状态，调了查询工具发现查不到，于是反复重试、改写参数、调用关联工具，总共跑了40多步，产生了大量无效调用和延迟。设置步数上限后，这种场景会在可控范围内自动停止，用户体验反而更好。

4.3 Agent的“确定性”改造：预设流程为主、自由规划为辅

如果你现在要设计一个面向真实用户的Agent产品，我的建议是别一上来就追求“完全自主”，尽量采用“预设流程为主、自由规划为辅”的混合模式。

具体做法是把高频场景固化成流程模板。比如客服场景里的“退款流程”：第一步收集订单号，第二步验证订单状态，第三步核对退款原因，第四步确认退款金额。每一步都绑定特定的工具调用，模型不需要自行规划，只需要按模板一步步执行，每步执行完校验结果。这种设计下的出错面非常小，因为流程是确定的，模型只是在流程里做填参和判断。

对于流程模板覆盖不到的长尾场景，再开放模型自由规划，但设置更严格的安全护栏和人工审核节点。这样做的好处是：高频场景稳定可靠，长尾场景保留灵活性，整个产品给人“聪明但靠谱”的体验。市面上真正成功的Agent产品，基本都是这个路子。那些动不动就“你随便说，我自己规划”的产品，秀完Demo后往往留下一地鸡毛。

5. 垂域数据的准备与微调：什么时候该动模型本身

很多团队做垂域LLM，第一反应是“我要微调”。但我的经验是：至少一半的垂域场景，靠RAG就能解决，不需要微调。微调是高成本、高风险、不可逆的动作，应该在RAG和Prompt工程都证明不够之后才考虑。

5.1 先判断要不要微调：三种必须微调的情况

就我的实践经验，有三种情况是值得做微调的，其他情况请先回去优化RAG。

第一种是输出格式和风格有硬性要求。比如你的产品要求模型必须按企业标准化格式输出报告，固定章节结构、固定措辞风格、特定术语表达。这种“格式刚性”需求光靠Prompt很难稳定满足，微调模型在这方面很有效。

第二种是领域知识与表达习惯差异巨大。比如中医问诊场景、航空维修场景、企业内部审批场景，这些领域的语料分布和通用互联网语料差异太大，模型的领域词汇表达完全不在线。用几万条高质量领域数据做微调，模型在领域内的流畅度和准确性能有质的提升。

第三种是推理链路需要模仿特定专家路径。比如法律条款分析，专家会先看案件事实，再匹配法律条文，再分析既往判例，最后给出结论。这种分步骤的推理过程可以做成“思维链”数据微调，让模型学会这套分析路径。

5.2 垂域数据准备：质量比数量重要一个数量级

垂域微调最核心的是数据准备。很多数据团队的做法是到处爬数据，凑够几十万条再开始训练。这个思路说实话不太对。有效的垂域数据应该有几个特征。

第一是“指令-回答”对齐明确。不要只准备一堆领域文档然后期望模型从中“感悟”，要明确构造大量“你问什么-模型该答什么”的配对样本。第二是覆盖边界案例。模型犯错常常因为没见过“不该这么做”的例子，准备一些困难样本、易错样本，模型才能学会边界在哪。第三是去重和清洗非常关键。重复数据会让模型过拟合，噪声数据会让模型学到错误模式。

关于数据量，我的经验参考是：不要少于5000条高质量指令对，不要超过5万条（SFT阶段）。少于5000条，模型学不到稳定的领域模式；超过5万条且质量一般，收益会明显递减，甚至开始出现灾难性遗忘——模型变得只会垂域任务，通用能力反而下降了。数据质量的重要性怎么强调都不过分。我见过用8000条精选数据和用8万条网爬数据微调出的模型，前者的效果明显更稳定，因为精选数据里的每个样本都是经过人工校验的。

5.3 微调之后别忘了评测和回归

微调最容易被忽视的是评测环节。很多团队微调完，拿几条测试数据试一下，觉得“效果不错”，就上线了。这是非常危险的。

我建议微调项目必须建一套三层评测体系。第一层是领域能力评测——用你准备的测试集，检查在垂域任务上的准确率、召回率是否符合预期。第二层是通用能力回归——用一套通用能力基准（常识问答、数学计算、代码生成、逻辑推理）测试，确保模型没出现明显的灾难性遗忘。第三层是安全性测试——用对抗样本、恶意Prompt、越狱攻击等评测集，确认模型在加入垂域知识后没有变得更容易被诱导输出不安全内容。

三层评测都通过后再考虑灰度上线。上线后还要持续收集badcase，定期打标、补充数据、做增量训练。垂域模型不是一个“训练一次用一年”的东西，它是需要持续运营的资产。

6. 落地工程实践：推理成本、迭代节奏和评估体系

前五节讲的都是模型和应用层，最后一节聊聊真正上生产时那几个容易被忽视的工程问题。这几件事决定你的LLM功能能不能长期稳定跑下去，而不只是“演示能跑通”。

6.1 推理成本到底怎么算：不只是GPU价格

很多团队核算推理成本只盯着GPU采购或租赁价格，这是明显不够的。真实生产环境里，推理成本由四部分组成：计算资源成本、延迟成本（用户体验变差导致的流失）、运维成本（监控、告警、模型更新）、数据成本（RAG链路中知识库的维护更新）。

计算资源这块有个很实用的优化手段：用模型路由（Routing）把简单请求和复杂请求分流。做一个轻量级意图分类器，识别“简单问候、关键词查询、格式转换”这类基础请求，直接走小模型或预设模板，不需要上大模型；只有真正复杂的请求才路由到满血版大模型。这个优化最多能省下80%左右的推理成本，而且响应速度更快。

此外，不要忽视Prompt缓存、KV Cache复用这类工程优化。同一个高频问题在短时间内被反复问到，Prompt前缀其实是一样的，通过语义缓存直接命中结果，不用每次都跑一次模型推理。这些优化在规模上来后效果非常明显，但需要你在架构设计阶段就留好接口，后期再加比较痛苦。

6.2 迭代节奏：小步快跑，别憋大招

LLM领域的迭代速度和传统软件工程完全不同。模型一个季度就出一代，Prompt的技巧几个月就可能过时。如果你的团队用“六个月一次大版本”的节奏来做LLM功能，等你上线时用的可能已经是上一代技术。

我的经验是建立两周一个迭代周期的节奏。每个周期做四件事：收集badcase、评估现有方案的效果短板、针对短板做Prompt优化或RAG调参或数据补充、灰度发布并继续收集badcase。这个循环看着平淡，但坚持三个周期以后，产品效果会有肉眼可见的提升。原因很简单：LLM产品的效果优化是一个逐步逼近的过程，数据反馈驱动的迭代效率远高于一次性设计的效率。

迭代时要注意变更管理的规范性。Prompt的每次改动都要记录版本，模型的每次替换都要跑完整回归。我在项目里吃过亏：有一次升级了Embedding模型，没跑回归，结果所有旧文档没重新向量化，检索全部走偏，用户在线上搜什么都相当于全库扫描。这种事故其实是完全可以避免的。

6.3 建立可量化的评估体系：没有度量就没有优化

最后这一点我想多说两句。LLM产品最常被吐槽的一点是“效果说不清楚”。业务方问“这功能到底行不行”，你只能说“感觉还行”。这种状态对项目非常不利——你无法证明自己的价值，也无法说服团队继续投入。

所以从第一天起就要建评估体系。核心是三类指标：效果指标（回答准确率、召回率、幻觉率）、性能指标（首Token延迟、总响应时间、吞吐量）、商业指标（用户留存、任务完成率、客服转人工率）。效果指标需要人工标注或LLM-as-Judge辅助评估，性能指标靠监控系统采集，商业指标接产品数据分析。

LLM-as-Judge是一种用大模型来给模型回答打分的评估方式，实测下来和人工评估的相关性很高，可以大大降低评估成本。具体做法是构造一个评估Prompt，把原始问题、模型回答、参考答案一起丢给一个强模型，让它输出1到5分的评分和理由。需要定期校验评估模型和人工评分的一致性，防止评估模型“口味漂移”。

有了这套评估体系，你的每次优化都变成了可验证、可量化、可复盘的动作。它不会直接提升模型效果，但它是你后续所有优化工作的基石。我做过近十个LLM落地项目，凡是从第一天就建立评估体系的，项目上线后的迭代质量都明显优于凭感觉优化的团队。这不是玄学，是工程方法论的力量。

我个人做了这么多LLM落地项目后最深的体会是：这个领域虽然变化快，但只要把场景定位、数据链路、评估闭环和成本结构这四件事想清楚，不容易跑偏。模型会有更替，框架会有更迭，但围绕真实业务场景持续打磨确定性、降低不确定性的思路，会一直是落地的核心。如果这篇文章能帮你的项目少走一步弯路，那就很值了。