小红书二面：Function Calling 的可靠性怎么保证？

1. 题目分析Function Calling 大概是 LLM 应用开发中最拧巴的一个环节——你让一个概率模型去做一件需要百分之百精确的事。模型生成的自然语言可以有措辞差异、可以有风格变化用户多半不会在意但一个工具调用的参数少了一个字段、日期格式从YYYY-MM-DD变成了DD/MM/YYYY、或者枚举值pending拼成了Pending下游系统直接报错整个 Agent 流程就断了。这就是 Function Calling 可靠性问题的本质一个模糊的系统在试图产出精确的结果。面对这个问题不能只是泛泛而谈做好 Prompt 就行了而是要能把这个问题拆成若干具体的失败模式然后针对每种失败模式给出工程上的应对手段。能讲清楚哪里会出错和怎么防住才能说明你真的在生产环境中跟 Function Calling 打过交道。1.1 先搞清楚到底哪里会出错要保障可靠性第一步是建立对失败模式的完整认知。Function Calling 的失败不是一种而是一串发生在调用链路的不同环节。按照一次工具调用从模型决策到结果返回的完整路径来梳理大致可以分为五类问题。该调的时候不调不该调的时候乱调。这是意图识别层面的错误。用户说帮我查一下明天北京的天气模型应该调用天气查询工具但它可能直接用自己的知识编造了一个天气预报反过来用户只是随口说天气真好啊模型却触发了天气查询。这类问题在工具数量较多、工具功能有重叠的时候尤其严重——十几个工具摆在面前模型很容易选错或者在不需要工具的时候画蛇添足。调对了工具但参数构造出错。这是最常见也是最棘手的一类失败。模型正确地选择了天气查询工具但传的城市名是BJ而不是北京或者日期格式不对或者漏掉了必填的unit参数。参数构造错误的形态非常多样——类型错误、格式不符、值域越界、字段缺失、多余字段——它们在传统开发中靠编译器和类型系统就能拦住但在 LLM 生成的世界里每一个都可能发生。格式层面的解析失败。模型返回的 JSON 不合法——多了个逗号、少了个引号、在 JSON 外面包了一层 markdown 代码块甚至直接返回了自然语言而不是 JSON。虽然现在主流模型的 structured output 能力已经大幅改善但在使用开源模型或者老版本 API 时这个问题仍然常见。工具执行层面的失败。参数没问题格式也没问题但外部 API 本身超时了、限流了、返回了错误码、或者返回了一个出乎意料的数据结构。这不是模型的错但 Agent 需要能理解并应对这些失败。结果误用。工具成功返回了结果但模型在解读结果时出了偏差——比如把美元当成了人民币或者在多个返回字段中选错了要用的那个。1.2 Schema 设计是第一道防线很多人把 Function Calling 的可靠性问题归结为模型能力不够但实际上有相当一部分错误可以通过更好的 Schema 设计来避免。Schema 写得好不好直接决定了模型犯错的空间有多大。工具描述description要写给模型看不是写给人看。很多开发者习惯性地用简短的技术注释来写工具描述比如查询天气数据。但模型需要的是更明确的使用指南什么时候该用这个工具、什么时候不该用、输入应该是什么样的。一个好的描述是当用户询问某个城市未来的天气状况时调用此工具。不要用于查询历史天气。城市名称需使用中文全称如北京而非BJ。描述越具体模型的决策边界就越清晰。参数的约束要在 Schema 里写死不要指望模型自觉。JSON Schema 本身提供了丰富的约束能力——enum限定可选值、pattern用正则约束格式、minimum/maximum限定数值范围、required标明必填字段。这些约束不只是给下游校验用的模型在生成参数时也会参考 Schema 中的约束信息。一个写了enum: [celsius, fahrenheit]的unit字段比一个只写了type: string的字段出错率低得多。控制工具数量避免选择困难症。实验数据表明当可用工具超过 10-15 个时模型的选择准确率会明显下降。如果你的系统确实有几十个工具应该做分组或分级——根据用户意图先做一轮粗筛只把相关的 3-5 个工具放进当前 prompt而不是把全部工具一股脑塞给模型。这种动态工具注入的策略在实际项目中效果非常好。用 few-shot 示例来校准模型的调用行为。在 System Prompt 中给出 2-3 个完整的调用示例——包括用户输入、期望的工具选择、期望的参数格式——可以显著降低模型的调用错误率。示例的作用不仅是教模型怎么调更重要的是帮模型建立什么情况下调和什么情况下不调的判断标准。1.3 Structured Output 与受约束解码Schema 设计再好最终还是要靠模型来生成符合要求的输出。好消息是主流模型厂商这两年在这方面的投入非常大已经提供了多种机制来从模型侧保障输出的格式可靠性。Structured Output结构化输出是目前最强的格式保障手段。OpenAI 在 2024 年推出的 Structured Outputs 功能可以保证模型的输出 100% 符合你提供的 JSON Schema——不是尽量符合是一定符合。它的底层原理是受约束解码Constrained Decoding在模型生成每个 token 时根据当前已生成的内容和目标 Schema动态计算出下一个 token 的合法候选集把所有不合法的 token 的概率置零。比如当模型刚生成了{city:之后如果 Schema 要求 city 是 string 类型那么下一个 token 只能是引号开头的字符串数字和布尔值的 token 概率直接被清零。这种机制从根本上消除了格式层面的错误——不会再出现 JSON 不合法、字段类型错误、缺少必填字段等问题。但要注意Structured Output 保证的是格式正确不保证语义正确。模型可能生成一个格式完美但值完全离谱的 JSON比如把城市名填成了用户名。Function Calling 模式本身也自带一定的格式保障。当你通过 API 的tools参数传入工具定义时模型会进入一种特殊的生成模式输出的格式比普通 chat completion 要稳定得多。结合tool_choice参数你还可以控制模型是自己决定是否调用auto、必须调用某个工具指定工具名、还是不许调用任何工具none进一步缩小决策空间。1.4 验证层、重试与降级模型侧的能力再强工程上也不能把所有赌注压在模型身上。一个成熟的 Function Calling 系统一定有独立于模型的验证和容错机制。参数校验中间层是最基本的工程实践。在模型输出工具调用指令和实际执行工具之间插入一个校验层。这个校验层做的事情很具体拿模型生成的参数去跟 JSON Schema 做一次严格校验用 jsonschema 库或者 Pydantic 模型检查类型是否正确、必填字段是否齐全、枚举值是否合法、数值是否在范围内。校验不通过的不要直接报错而是把错误信息反馈给模型让它修正后重新生成。这种生成→校验→反馈→重试的循环实测中能修复 80% 以上的参数错误。说到重试重试策略的设计也有讲究。不是简单地失败了就再来一次而是要区分失败类型来决定怎么重试。参数校验失败应该把具体的校验错误信息比如date 字段格式不符期望 YYYY-MM-DD实际收到 03/15/2024拼进 prompt 让模型修正这叫带反馈的重试。API 超时或限流导致的失败应该用指数退避Exponential Backoff重试跟模型无关。如果同一个工具连续失败 N 次就应该触发降级策略——要么换一个功能类似的备选工具要么直接告诉用户这个操作暂时无法完成而不是无限重试。Pydantic 在 Python 生态中几乎是 Function Calling 的标配。用 Pydantic 定义工具参数的数据模型一方面自动生成 JSON Schema 给模型用另一方面自动完成参数解析和校验。如果模型返回的参数不符合 Pydantic 模型的定义会直接抛出带有详细错误信息的 ValidationError这些错误信息可以直接拼进下一轮 prompt。LangChain 的tool装饰器和 OpenAI 的 function calling 示例中大量使用了这种模式。1.5 多工具场景下的可靠性挑战当系统中只有两三个工具时上面这些手段基本够用了。但当工具数量上升到十几个甚至几十个可靠性问题会变得复杂得多。工具之间的混淆是头号问题。功能相近的工具特别容易被混淆——search_products和search_inventory都是搜索模型怎么知道该用哪个send_email和send_notification都是发消息边界在哪里解决这个问题要从两方面入手。一方面在工具描述中明确写清彼此的区别不是各自描述自己就行而是要告诉模型当 X 场景用工具 A当 Y 场景用工具 B。另一方面要做工具分组把工具按业务域分成几组模型先选组再选工具像一个两级菜单一样减少每一级的选择数量。Parallel Function Calling并行调用引入了新的复杂度。现在主流模型支持在一次回复中同时调用多个工具。这在效率上是好事但也带来了新问题模型可能在本该串行的场景中错误地并行调用比如先查用户信息才能下单模型同时调了查询和下单或者并行调用的多个工具之间有隐含的参数依赖但模型没意识到。工程上需要在执行层做依赖检查——如果检测到并行调用之间存在数据依赖自动将其转为串行执行。工具调用链路的组合也需要验证。在复杂 Agent 中完成一个任务可能需要调用 3-5 个工具每个工具的输出是下一个工具的输入。单个工具调用的可靠性都保住了但组合在一起时可能出现语义层面的不一致——第一个工具返回的是 ID第二个工具期望的是名称模型需要做一次转换但可能转错。对于关键的工具调用链路可以预定义一些常见的调用模板Tool Chain Template限制模型只能在预定义的链路模式中选择而不是完全自由组合。1.6 评估与监控可靠性不是一次性做到位的事情它需要持续度量、持续优化。工程上要建立一套完整的评估和监控体系。离线评估要建标准测试集。收集真实用户的请求和期望的工具调用结果构建一个 benchmark 数据集。每次修改了 Schema、调整了 Prompt、升级了模型版本都要跑一遍测试集看工具选择准确率、参数正确率、端到端任务完成率这几个核心指标是涨了还是跌了。这跟传统软件的回归测试是一个道理只不过评估的对象从代码输出变成了模型调用行为。线上监控要跟踪关键链路指标。在生产环境中至少需要监控这些指标工具调用的触发率是否在该调的时候调了、参数校验通过率参数质量怎么样、工具执行成功率下游服务是否稳定、重试率和重试成功率容错机制是否有效、端到端任务完成率用户视角的体验。这些指标要有告警阈值一旦某个指标异常下降能及时发现并排查。LLM-as-Judge 可以做更细粒度的质量评估。对于一些难以用规则判断对错的场景——比如模型选了一个也说得过去但不是最优的工具或者参数在语义上有微妙的偏差——可以用另一个 LLM 来做裁判评估调用决策的合理性。这种方式成本较高通常用于离线的抽样评估而不是线上实时检查。最后补充一个实践中的重要认知可靠性保障的投入应该和业务风险成正比。一个内部的数据查询助手工具调用出错了大不了让用户重新问一次做基本的参数校验和重试就够了。但如果是一个能操作用户账户、发起交易的 Agent每一次误操作都可能造成真实损失那就需要在关键操作前加人工确认、在高风险工具上设置更严格的参数约束、甚至对某些操作做双模型交叉验证两个模型都认为该执行才执行。没有一刀切的方案工程上的权衡永远是在可靠性、延迟和成本之间找平衡点。2. 参考回答Function Calling 的可靠性保障需要从多个层面来做我把它理解成一个纵深防御的体系。首先从源头上Schema 设计是第一道防线。工具描述要写得足够具体不只是说做什么还要说什么时候用、什么时候不用。参数定义要用好 JSON Schema 的约束能力——enum 限定可选值、pattern 约束格式、required 标明必填字段。工具数量多的时候要做分组和动态注入避免模型面对太多选择时犯迷糊。配合 few-shot 示例来校准调用行为效果提升会很明显。在模型侧现在主流模型都支持 Structured Output底层用受约束解码来保证输出 100% 符合 JSON Schema这从根本上解决了格式层面的可靠性问题。但它只保证格式正确不保证语义正确所以工程侧还需要独立的兜底机制。工程上最关键的实践是在模型输出和工具执行之间插一个参数校验层我们项目中用 Pydantic 来做。校验失败的不直接报错而是把具体的校验错误信息反馈给模型让它修正重试这种带反馈的重试能修复大部分参数错误。同时要区分失败类型——参数错误走反馈重试API 超时走指数退避连续失败 N 次走降级策略不能一刀切地处理所有失败。最后是持续的评估和监控。我们会维护一个基于真实用户请求的标准测试集每次改 Schema 或升级模型都跑回归测试。线上则监控工具调用触发率、参数校验通过率、执行成功率这些关键指标设好告警阈值。整体来说可靠性不是某一层做到极致就够的而是每一层都做好基本功形成纵深防御。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】