一、模型到业务之间隔着什么

（一） Demo 与生产的差距

演示环境里，模型能回答大部分问题，看起来已经可用；进入生产后，问题立刻变得具体：回答里混进了过期信息、涉及内部术语时答非所问、多轮对话后忘记前情、遇到需要查系统的请求就编造内容。这些问题的共同点是模型本身没有变，变的是业务对准确性的要求。

（二）三道坎的具体形态

第一道坎是知识：模型的通用知识覆盖不了企业内部的内容。第二道坎是流程：真实业务往往需要查数据、调接口、走审批，不是一问一答就能完成。第三道坎是持续优化：上线只是开始，效果要持续测量并回流改进，否则会随业务变化慢慢失效。

1. 知识接入：把业务知识可靠地送进模型上下文。

2. 流程编排：把多步操作串联成可执行的任务。

3. 持续优化：把线上效果测量并回流到改进环节。

二、第一道坎：知识与数据接入

（一）检索提升的基本做法

把业务知识接入模型，主流做法是检索提升：先把文档切分成片段并建立索引，用户提问时检索出相关片段，拼进提示词一起送给模型。这样模型不必记住全部内容，只需要基于给定片段作答，准确性与可追溯性都更好，更新知识时只需更新索引。

（二）切分与检索质量的决定因素

效果好坏主要取决于两件事：切分是否合理、检索是否命中。切分过大引入无关内容，过小则丢失上下文；检索只看关键词匹配会漏掉语义相近的表述。实践中常按语义单元切分并保留重叠，检索时用向量与关键词两种方式组合，命中率明显提升。

（三）知识更新与权限

知识库不是一次建成的。文档更新之后索引要同步刷新，否则模型会引用过期内容；不同部门的内容还要按权限隔离，减少不应看到的信息被检索出来。天翼云存储可以支撑文档与索引的统一存放，配合天翼云安全的权限控制，让知识更新与访问边界都有据可依。

三、第二道坎：流程编排与工具调用

（一）从一问一答到多步任务

真实业务很少是一问一答。用户说帮我查一下上月的异常订单并生成说明，背后要查询数据库、筛选条件、生成文本、可能还要推送审批。把这类任务拆成可执行的步骤，让模型负责判断与生成、系统负责执行与校验，是应用落地的关键一步。

（二）工具调用的可靠性设计

模型调用外部工具时，可靠性靠三点保证：参数必须由结构化输出产生而不是从文本里截取；每次调用都要有超时与重试；执行结果要回传给模型做二次确认。缺少任何一点，都可能出现参数错误导致的操作失败，或者模型编造一个并未发生的执行结果。

① 结构化参数：用固定格式输出参数，减少解析出错。

② 超时与重试：每次调用都设时限与重试次数，失败可恢复。

③ 结果回传：执行结果返回模型确认，杜绝编造执行结果。

四、第三道坎：效果测量与持续优化

（一）上线后要看什么

上线不是终点。需要持续看的指标包括：回答的采纳率、人工修改比例、检索命中率、任务完成率与失败原因分布。前两项反映效果，后三项反映系统健康度。指标落到天翼云数据库中长期留存，才能看出趋势，而不是只看某一时刻的截图。

（二）如何把问题回流成改进

发现问题之后要有回流机制：检索不命中的补充索引，回答不准确的修正提示词或补充示例，工具调用失败的增加参数校验。每一类问题对应固定的处理动作，并按周复盘处理进度。有了这条回路，系统才会越用越好，而不是停留在上线时的水准。

五、成本与时延的控制

（一）成本从哪些地方涨上去

应用侧的成本主要由三部分构成：调用模型的次数、每次的输入输出长度、以及检索与工具调用带来的额外开销。多轮对话会把历史内容反复送入模型，输入长度快速增长；工具调用失败重试也会叠加消耗。控制成本要先看清这三部分各占多少。

（二）常见的控制手法

降低消耗的手法包括：对超长会话做摘要压缩、对重复出现的前缀做缓存、对简单问题路由到更小的模型、对检索结果做去重与截断。这些改动大多不需要业务代码大改，却能把单位调用的成本明显压下来，是投产比最高的一类优化。

六、分阶段落地的建议

（一）先做窄场景再扩展

落地时不宜一开始追求覆盖面。建议选一个边界清晰、容错空间较大的场景做试点，比如内部知识问答或文档摘要，把检索、编排、测量三个环节跑通并形成模板，再逐步扩展到其他场景。窄场景见效快，也更容易获得业务方的信任。

（二）组织与能力准备

应用落地需要三类定位：懂业务的提出需求与验收标准，懂模型的调整提示词与检索策略，懂系统的负责接口与稳定性。三者缺一，项目就容易卡在某一环。天翼云主机可以支撑编排服务与调度组件，让团队把精力集中在业务逻辑本身。

七、安全与合规的边界

（一）数据边界要清楚

应用侧最需要提前划清的是数据边界：哪些内容可以送进模型、哪些必须留在本地、调用记录保留多久。边界不清时，一旦出现信息外泄，责任难以界定。建议把可送与不可送的内容列成清单，并在系统中做硬性校验。

（二）权限与审计

知识库与工具调用都要按人授权：不同定位能检索的范围不同，能触发的操作也不同。每一次调用都应留下记录，包含调用者、时间、内容与结果摘要。天翼云安全提供访问控制与操作审计能力，可以支撑这类要求。

八、什么时候不该上大模型

（一）规则明确的场景

并非所有场景都适合用模型。规则明确、要求结果严格一致的任务，用规则引擎或传统程序更可靠，成本也更低。判断标准是：能否容忍结果存在波动、是否需要理解模糊表述。两个答案都是否定时，模型并非最优选择。把这类任务留在规则引擎里，反而能让模型资源集中到真正需要理解力的场景，整体投入产出更高。

（二）投入产出的算账方式

上应用之前建议算一笔账：当前人工处理一次的成本与时间、模型方案的单次成本与准确率、需要人工复核的比例。三项相乘之后再比较，结论往往比凭感觉判断更清晰。准确率不达标时，人工复核的成本会迅速吃掉全部收益。

结语：模型效果好只是起点，最后一公里拼的是知识接入是否可靠、流程编排是否可执行、效果能否持续测量回流。这三件事做扎实，应用才真正可用。建议选一个边界清晰的窄场景做试点，把三个环节跑通形成模板后再扩展。成本方面优先做摘要压缩与前缀缓存，改动小、收益明显。