企业官网建设流程全解析

1. 从一句判断说起：模型为什么只是放大器

“模型是放大器，不是发电机”这句话，我在过去一年里跟至少二十个团队讲过。每次讲完，总有人先愣一下，然后点头，接着问：那我的应用到底卡在哪一环？这个问题问得好，因为它直接决定了你是把预算砸在换更强的模型上，还是回头去修数据管道、检索链路和评测体系。

先把这句话拆开。发电机是从零创造能量，放大器是把已有的信号放大。大语言模型（LLM）在应用里的真实角色，更接近后者。它能把一份结构清晰、上下文充分的输入，转化成高质量的摘要、判断、代码或对话；但如果输入本身是噪声、缺失、矛盾或者压根没喂进去，再强的模型也只能一本正经地胡说。这不是模型能力问题，是信息论层面的硬约束——输出质量的上限，由输入信号的信噪比决定。

我在一个企业知识问答项目里做过对照实验。同一套问题集，同一版模型，只改检索环节：第一版用朴素向量检索，第二版加了查询改写和重排序。结果第二版的答案准确率从 61% 提到 84%，而模型本身一个字没动。这个差距说明什么？说明大部分所谓“模型不够聪明”的抱怨，其实是“信号没送到模型面前”。

所以这篇内容想聊的不是某个模型的跑分，而是 AI 应用从 Demo 走向生产时，真正会拦住你的那 15 类问题，以及 Agent 场景下必须提前列出的风险清单。适合谁看？适合已经跑通 Demo、正在往生产推的工程师和产品负责人；也适合还在选型阶段、想少走弯路的团队。关键词里的 RAG、Agent、Token、LLM 框架，都会在具体问题里落到实操层面，不讲空话。

2. 生产化路上的 15 个真问题

2.1 问题一到五：数据与检索层的隐性债务

问题一：你的知识库到底“新鲜”到什么程度？很多团队上线 RAG 后才发现，知识库更新是个持续工程，不是一次性导入。文档会改版、会废弃、会有新旧版本并存。如果检索层没有版本管理和时效过滤，模型就会拿着去年的政策回答今年的问题。我的做法是给每条切片打上effective_date和deprecated标记，检索时先按时间过滤再算相似度。这个改动很小，但能消掉一大类“答非所问”。

问题二：切片粒度是不是拍脑袋定的？切片太大，检索命中后噪声多，模型要在长上下文里自己找重点；切片太小，语义不完整，检索容易断章取义。我一般会按文档结构切，标题层级作为天然边界，再对超长段落做二次切分，目标控制在 300 到 500 token。这个区间不是玄学，是实测下来召回率和上下文完整性的平衡点。

问题三：向量检索的“相似”真的等于“相关”吗？这是 RAG 最容易被低估的坑。向量相似度衡量的是语义接近，但用户问“报销流程”，最相关的可能是“费用管理制度”而不是“差旅报销常见问题”。纯向量检索经常把语义相近但用途不同的内容排前面。解决办法是混合检索：向量召回加关键词召回，再用重排序模型统一打分。LangChain4j 这类框架里都有现成的混合检索组件，接上就行。

问题四：查询改写做了没有？用户的问题往往口语化、省略主语、带错别字。直接拿原始 query 去检索，召回质量会打折。加一层查询改写，把“那个报销的事咋弄”改写成“员工费用报销流程和所需材料”，召回率会有肉眼可见的提升。这一步可以用小模型做，成本低，收益高。

问题五：检索结果要不要压缩？召回十条切片全塞进上下文，Token 消耗大不说，还可能引入干扰。我习惯在重排序后只保留 Top 3 到 Top 5，并对每条做摘要压缩，只留和问题最相关的句子。这样既省 Token，又降低模型被无关信息带偏的概率。

2.2 问题六到十：模型调用与 Token 经济性

问题六：Token 用量你算清楚了吗？很多团队上线后第一个月账单超预期，就是因为没算清 Token。一次问答的 Token 消耗等于系统提示词加检索上下文加用户问题加模型输出。系统提示词如果写得很长，每次调用都在重复付费。我的经验是把稳定不变的部分做成缓存，能省下相当一部分成本。Token 用量监控要按接口、按场景拆开看，不然你根本不知道钱花在哪。

问题七：上下文窗口大就一定要塞满吗？不是。上下文越长，模型注意力越容易分散，而且延迟和成本都上升。我见过把整本手册塞进去的做法，效果反而不如精准检索三条。上下文是资源，不是越多越好，够用且精准才是目标。

问题八：模型选型是选最强还是选最合适？生产环境里，最强模型往往最贵最慢。我的策略是分层：简单分类、改写、抽取用小模型，复杂推理和生成用大模型。一个请求里可以串多个模型，各司其职。这样整体成本和延迟都能压下来，效果不打折。

问题九：超时和重试怎么设计？模型接口会抖动，会超时，会返回限流。如果没有重试和降级，用户体验就是随机失败。我的做法是设置合理超时，配合指数退避重试，重试仍失败则降级到缓存答案或提示稍后再试。关键是别让一次接口抖动直接变成用户看到的报错。

问题十：流式输出做了吗？对交互式应用，流式输出几乎是体验刚需。用户看到字一个个出来，感知延迟大幅降低。技术上就是把模型返回按块推给前端，同时处理好中断和错误。这个改动不大，但体验提升明显。

2.3 问题十一到十五：评测、监控与迭代闭环

问题十一：你怎么知道这次改动是变好还是变坏？没有评测集，所有优化都是凭感觉。我建议在项目早期就攒一个 100 到 300 条的问题集，覆盖常见问题和边界情况，每次改动跑一遍，看准确率、召回率、幻觉率的变化。这个评测集是团队的资产，越早建越值钱。

问题十二：幻觉怎么发现和抑制？幻觉分两种：一种是模型编造事实，一种是模型过度推断。抑制手段包括：要求模型只基于给定上下文回答、在提示词里明确“不知道就说不知道”、对关键结论做引用溯源。但更重要的是评测环节要专门测幻觉，把它当成一个可量化的指标来管。

问题十三：线上出问题怎么定位？必须做全链路日志：用户问题、改写后的 query、召回的切片、最终提示词、模型输出、Token 消耗、耗时。缺任何一环，排查都会变成猜谜。我习惯把这些字段结构化打点，出问题时能按请求 ID 串起来看。

问题十四：用户反馈怎么变成迭代输入？点赞点踩只是开始。要把差评样本定期捞出来分析，归类是检索问题、提示词问题还是模型能力问题，然后针对性修。没有这个闭环，系统会一直停在原地。

问题十五：版本管理和灰度怎么做？提示词、检索配置、模型版本都是会变的。每次变更要有版本记录，能回滚，能灰度。我见过提示词改了一行导致整体效果下滑却找不到旧版本的情况，教训很直接。

3. Agent 风险清单：从能跑到敢用之间隔着什么

3.1 工具调用的失控风险

Agent 和普通 RAG 最大的区别是它会调用工具、执行动作。这就带来一类全新风险：模型可能调用错误的工具、传入错误的参数、或者在多步任务里越走越偏。我见过 Agent 把“查询订单”理解成“取消订单”的案例，虽然最后被权限拦住了，但足以说明问题。

控制手段有几层。第一层是工具白名单，Agent 只能调用明确授权的工具。第二层是参数校验，工具入口对参数做严格类型和范围检查，不信任模型传进来的任何东西。第三层是危险操作二次确认，涉及写操作、删除、支付这类动作，必须有人工确认或额外的策略校验。第四层是步数上限，防止 Agent 陷入循环或无限调用。

3.2 循环与死锁：Agent 最容易翻车的地方

Agent 在多步推理里可能反复调用同一个工具，或者两个工具互相触发形成循环。表现是请求迟迟不返回，Token 哗哗地烧。防御手段是设置最大步数和最大 Token 预算，超限就强制终止并返回当前结果。同时要在日志里记录每一步的决策，方便事后分析它为什么绕不出来。

还有一种隐蔽情况是工具返回了模型没预期的格式，模型反复重试同一个调用。这要求工具返回格式尽量稳定，并在提示词里说明异常情况的处理方式。

3.3 权限边界与数据泄露

Agent 能访问的工具和数据，就是它的能力边界，也是风险边界。最小权限原则在这里必须严格执行：Agent 只拿到完成任务所需的最小权限，不因为“以后可能用到”就放开。多租户场景下，要确保 Agent 不会跨租户访问数据，检索层和工具层都要做租户隔离校验。

数据泄露还有一条路径是提示词注入。用户输入里可能藏有指令，试图让 Agent 忽略原有规则、泄露系统提示词或调用未授权工具。防御上，用户输入和系统指令要明确分隔，对可疑输入做过滤，关键操作不依赖模型自觉而是靠外部策略校验。

3.4 可观测性与人工兜底

Agent 的决策链路比普通问答长得多，可观测性要求也更高。每一步的输入、输出、耗时、Token 都要记录。更重要的是要有中断机制：用户能随时叫停，系统能在异常时自动降级到人工。我坚持一个原则——Agent 可以自动完成，但关键节点必须留人工介入的口子。这不是不信任技术，是生产系统的基本要求。

4. 把放大器调好的几个实操抓手

4.1 提示词工程：稳定比花哨重要

提示词不是写得越长越好，也不是越玄越好。生产环境的提示词要稳定、可测试、可版本管理。我的习惯是把提示词拆成几块：角色定义、任务说明、约束条件、输出格式、示例。每块单独维护，改动时能定位影响范围。输出格式尽量用结构化格式，方便下游解析，也方便评测。

一个常被忽略的点是提示词里的“不知道”处理。必须明确告诉模型，当上下文不足以回答时，应该输出什么。否则模型会用编造来填补空白。

4.2 评测集建设：从第一天就开始攒

评测集不需要一开始就很完美。从上线第一天起，把真实用户问题抽样存下来，人工标注期望答案，慢慢积累。评测指标至少覆盖：答案准确性、检索召回率、幻觉率、拒答合理性。每次改动跑一遍，用数据说话。这个习惯坚持三个月，团队的迭代效率会有质的变化。

4.3 成本与延迟的平衡术

成本和延迟是一对需要持续调优的矛盾。我的做法是先设预算上限，再在这个约束下找最优方案。具体手段包括：小模型做前置处理、检索结果压缩、缓存高频问题、流式输出降低感知延迟、按场景分级调用不同模型。这些手段叠加起来，能把成本和延迟都控制在可接受范围。

5. 我在实际项目里踩过的几个坑

第一个坑是过早优化模型。项目初期效果不好，第一反应是换更强的模型，结果换完提升有限，钱花了不少。后来回头看，问题在检索和提示词，跟模型关系不大。这个教训让我养成了一个习惯：效果不好时，先查数据链路，再查提示词，最后才考虑模型。

第二个坑是忽略 Token 成本。早期没做用量监控，月底账单出来才发现某个场景的 Token 消耗是预期的五倍，原因是系统提示词太长且每次都全量发送。加上缓存和精简后，成本降了一半以上。

第三个坑是 Agent 没有步数上限。测试时一个任务跑了十几步才结束，上线后遇到边界情况直接绕进循环，请求超时。加上步数和 Token 双上限后，这类问题再没出现过。

第四个坑是评测集建得太晚。前期靠人工抽查，感觉还行，实际上线后差评不断。后来补建评测集，才发现有一类问题一直答错，只是没被抽查到。评测集这东西，早建早受益。

6. 给正在推进生产化的团队几句实在话

如果你的应用还停在 Demo 阶段，先别急着堆功能，把检索链路和评测集做扎实。这两样是地基，地基不稳，上面盖什么都会晃。如果你已经在生产环境跑，重点看三件事：Token 成本有没有监控、线上问题能不能定位、用户反馈有没有闭环。这三件事做到位，系统才算真正可控。

Agent 场景额外多一条：把风险清单当成上线检查项，逐条过一遍。工具权限、步数上限、人工兜底、注入防御，缺哪条补哪条。别等出了问题再补，那时候代价高得多。

模型是放大器，这个判断我越来越确信。它放大的是你已有的信号质量，也放大你链路里的每一个缺陷。把信号调干净，把链路做扎实，模型的价值自然就出来了。反过来，指望模型去填补数据和工程的窟窿，最后大概率是失望。这个道理不复杂，但真正做到，需要在每一个环节上较真。