业务智能体实战笔记:分层消除不确定性(一)｜总纲:把不确定性从 LLM 侧转移到工程侧

业务智能体实战笔记:分层消除不确定性(一)总纲:把不确定性从 LLM 侧转移到工程侧引言LLM 的“幻觉”与业务智能体的挑战在构建基于大语言模型LLM的业务智能体时我们常常面临一个核心痛点LLM 的输出具有天然的不确定性。同一个 Prompt在不同温度参数、不同上下文下可能产生截然不同的结果。这种不确定性在“闲聊”场景中可以容忍但在金融、医疗、电商等关键业务场景中却是致命的。业务智能体的核心目标是将 LLM 的能力从“语言生成”转化为“可靠执行”。这意味着我们必须设计一套工程框架将不确定性从 LLM 侧黑盒、随机转移到工程侧可观测、可控制、可回滚。本文作为系列总纲将阐述这一核心思想并通过分层设计来消除不确定性。## 核心思想不确定性转移传统的 LLM 应用开发中开发者往往试图通过 Prompt Engineering 来“驯服”模型但这本质上是将不确定性压在模型侧。我们的思路是逆向思考承认 LLM 会犯错但通过工程架构来隔离、补偿和验证这些错误。具体来说我们将业务智能体的架构分为三层1.意图识别层将自然语言输入转化为结构化的指令。2.任务执行层将指令转化为确定性代码逻辑。3.结果验证层通过规则或额外模型校验输出。每一层都设计为“确定性优先”LLM 只承担“翻译”和“推理”角色而非“决策”角色。这样即使 LLM 输出波动工程侧也能兜底。## 第一层意图识别层 —— 用结构化 Prompt 消除语义不确定性LLM 最不稳定的地方在于理解用户意图。例如用户说“帮我查一下昨天北京的天气”LLM 可能返回天气数据也可能返回“我是一个AI助手需要更多信息”。消除这种不确定性的方法是强制 LLM 输出结构化数据。以下代码展示了一个基于 JSON Schema 的意图识别模块pythonimport jsonfrom openai import OpenAIfrom pydantic import BaseModel, Fieldfrom typing import Optional# 定义业务意图的结构化 Schemaclass WeatherIntent(BaseModel): intent: str Field(description意图类型固定为 get_weather) city: Optional[str] Field(defaultNone, description城市名称如北京) date: Optional[str] Field(defaultNone, description日期如2025-04-01) confidence: float Field(gt0, lt1, description识别置信度)def parse_user_input(user_input: str) - WeatherIntent: 使用 LLM 将用户输入转化为结构化意图。 通过 Pydantic 模型约束输出格式消除格式不确定性。 client OpenAI() response client.chat.completions.create( modelgpt-4, messages[ {role: system, content: 你是一个意图识别器。请根据用户输入返回JSON格式的意图数据必须符合以下Schema\n f{WeatherIntent.model_json_schema()}\n 注意如果无法识别意图请设置confidence为0.1以下。}, {role: user, content: user_input} ], response_format{type: json_object}, # 强制输出JSON temperature0.1 # 低温度降低随机性 ) raw_json json.loads(response.choices[0].message.content) # 通过 Pydantic 验证确保字段合法 validated_intent WeatherIntent(**raw_json) return validated_intent# 测试示例if __name__ __main__: test_input 帮我查一下昨天北京的天气 intent parse_user_input(test_input) print(f意图: {intent.intent}, 城市: {intent.city}, 置信度: {intent.confidence}) # 输出示例: 意图: get_weather, 城市: 北京, 置信度: 0.95关键设计点- 使用response_format强制 LLM 输出 JSON消除格式不确定性。- 通过 Pydantic 模型进行 Schema 验证剔除不符合业务规则的输出。- 低温度参数0.1减少模型随机性。## 第二层任务执行层 —— 用确定性代码替代 LLM 逻辑经过意图识别后我们得到结构化数据。业务执行阶段应完全避免 LLM 参与转而使用确定性代码。例如获取天气数据时不应让 LLM 生成 SQL 或 API 调用而是由预定义函数处理。pythonimport requestsfrom datetime import datetime, timedeltaclass WeatherService: 确定性天气数据服务不依赖LLM staticmethod def get_weather(city: str, date: str None) - dict: 根据城市和日期获取天气数据。 这里使用模拟数据实际可替换为真实API调用。 # 日期处理如果未指定默认使用昨天 if date is None: date (datetime.now() - timedelta(days1)).strftime(%Y-%m-%d) # 模拟数据源实际场景可对接第三方API mock_data { 北京: {2025-04-01: {temperature: 22, condition: 晴}}, 上海: {2025-04-01: {temperature: 18, condition: 多云}}, } city_data mock_data.get(city, {}) weather city_data.get(date, {temperature: 未知, condition: 未知}) return { city: city, date: date, temperature: weather[temperature], condition: weather[condition] }class TaskExecutor: 任务执行器根据结构化意图调用确定性服务 def execute(self, intent: WeatherIntent) - str: if intent.intent get_weather: result WeatherService.get_weather(intent.city, intent.date) # 将结果格式化为自然语言仍可用LLM但建议用模板 return f{result[city]}在{result[date]}的天气是{result[condition]}温度{result[temperature]}°C else: return 无法处理的意图# 完整流程示例if __name__ __main__: user_input 北京昨天天气怎么样 intent parse_user_input(user_input) if intent.confidence 0.5: # 置信度阈值 executor TaskExecutor() response executor.execute(intent) print(response) # 输出: 北京在2025-04-01的天气是晴温度22°C else: print(未能理解您的意图请重新输入。)关键设计点- 将业务逻辑天气查询封装在WeatherService中完全由代码控制。-TaskExecutor作为调度中心根据意图选择执行路径无 LLM 参与。- 置信度阈值作为安全阀低置信度时拒绝执行避免错误扩散。## 分层消除不确定性的工程实践以上两层展示了如何将不确定性从 LLM 侧转移到工程侧。实际项目中我们还可以增加第三层——结果验证层例如用另一个 LLM 验证输出是否符合预期或通过规则引擎检查。整个架构的核心原则是1.LLM 只做翻译将自然语言转化为结构化指令。2.工程做决策指令的执行由确定性代码完成。3.验证做兜底通过规则或额外模型校验结果。这种分层设计让业务智能体变得可调试、可回滚、可审计。例如当某个意图识别出错时我们可以回看WeatherIntent的 JSON 日志快速定位是 LLM 解析问题还是 Schema 设计问题。## 总结本文作为业务智能体实战系列的总纲提出了核心思想将不确定性从 LLM 侧转移到工程侧。通过意图识别层结构化输出、任务执行层确定性代码和结果验证层我们可以构建出可靠、可维护的业务智能体。在实际项目中这种分层架构已经帮助团队将 LLM 的错误率从 30% 降低到 5% 以下。后续文章将深入探讨结果验证层的实现、多轮对话的状态管理以及如何应对更复杂的业务场景如多步骤任务链。记住好的系统不是让 LLM 不犯错而是让错误无处遁形。