大模型 Function Call 为什么会产生工具调用幻觉，工程上如何用 schema、权限、校验和反馈闭环降低误调用？｜高频面试题解析

60 秒回答模板

Function Call 幻觉本质上是模型在不该调用工具时调用、调用不存在或不适合的工具、编造参数、漏填必填字段，或者把工具结果错误解释成事实。原因通常有几类：工具描述不清晰或相互重叠，schema 过宽，提示里没有明确调用条件，模型缺少外部状态，历史上下文有冲突，或者工具执行失败后没有有效反馈。工程上我会分层治理。第一层是工具定义：每个工具要有清晰职责、适用条件、禁用条件、参数枚举、范围、默认值和示例，避免多个工具语义重叠。第二层是调用前门禁：先判断任务是否真的需要工具，对高风险工具加确认、权限和速率限制，对低置信调用要求模型补充信息而不是硬调。第三层是参数校验：用严格 schema、类型检查、范围校验、业务规则、资源权限和幂等键拦住编造参数。第四层是执行反馈：工具返回结构化状态、错误码、可重试性和证据，模型不能把失败结果当成功。第五层是观测和评测：记录调用理由、入参、出参、失败原因、人工纠错和误调用样本，构建离线评测集和线上规则回放。还要把高风险工具和低风险工具分级处理，让只读查询、写操作、外发操作和不可逆操作走不同确认策略。这样可以把 Function Call 从“模型想调就调”变成“模型提议、系统校验、工具执行、结果回传、闭环优化”的受控流程。

考点 幻觉类型

难度 真实面经题

回答目标让候选人能把 Function Call 幻觉治理讲成从工具定义到执行闭环的工程系统，覆盖原因、schema、门禁、校验、反馈、观测和评测，而不是只依赖提示词约束。

深入解析

先定义工具调用幻觉的表现

Function Call 幻觉不只是模型编造答案，还包括错误地决定要调用工具、选择了不合适的工具、调用不存在的工具、编造参数、漏掉必要参数、越权访问资源，以及把工具失败或空结果解释成成功。回答时先把问题边界说清楚，才能展开治理手段。

工具契约要减少歧义

很多误调用来自工具描述含糊和职责重叠。工具定义应写清楚用途、何时调用、何时不要调用、输入字段含义、必填项、枚举值、范围、单位、权限要求和返回语义。多个工具如果功能相近，需要有明确路由规则，否则模型会根据名字猜测，产生看似合理但错误的调用。

调用前增加门禁和确认

模型输出 function call 可以被视为调用提议，而不是最终执行命令。系统应根据用户意图、当前状态、权限、风险等级和置信度做门禁。只读低风险工具可以自动执行，高风险写操作、付款、删除、外发和隐私查询需要用户确认或额外授权。信息不足时，应追问缺失字段，而不是让模型补猜参数。

参数和业务规则必须严格校验

Schema 不是摆设。执行前要做类型、必填、枚举、范围、格式、资源归属、权限、幂等和业务状态校验。比如日期范围不能由模型随意扩大，用户 ID 不能跨租户，文件路径不能越权，写操作要有幂等键。校验失败要返回结构化错误，指导模型补充信息或选择其他路径。

工具结果要带证据和失败语义

工具返回不能只有自然语言结果，最好包含状态、错误码、数据来源、命中数量、时间戳、置信度、可重试性和引用。模型收到空结果、超时或权限不足时，应该如实说明限制或采取降级，而不是把失败包装成确定结论。执行层也要防止模型根据旧工具结果回答当前问题。

用日志和评测闭环持续降低误调用

线上要记录调用理由、候选工具、最终工具、参数、校验失败、执行结果、用户纠错和人工标注。离线用这些样本评测工具选择准确率、参数有效率、越权拦截率、无工具场景误调用率、错误恢复率和用户确认通过率。治理 Function Call 幻觉是持续迭代 schema、prompt、门禁和反馈的过程。

易错点

只说加强 prompt，忽略工具 schema、权限门禁、参数校验和执行反馈。
工具描述职责重叠，多个工具都像能解决同一问题，导致模型靠名称猜测。
把模型输出的 function call 直接执行，没有风险分级、用户确认和资源权限检查。
Schema 过宽，允许自由字符串、任意路径、任意 ID 和任意时间范围，给编造参数留下空间。
工具失败后只返回一段自然语言错误，模型无法判断可重试、缺字段、权限不足还是空结果。
只统计调用成功率，不统计误调用、漏调用、越权拦截、参数错误和用户纠错样本。

面试官追问

Function Call 的 schema 写得越详细越好吗？

不是越长越好，而是要清晰、互斥、可校验。过长描述会增加上下文噪声，过宽 schema 会放大模型猜参数空间。关键字段应有类型、枚举、范围和业务含义。

如何处理模型选择了正确工具但参数错了？

执行前做严格参数校验，失败后返回结构化错误和缺失字段，让模型补充或向用户追问。不要用默认值偷偷执行高风险操作，也不要让模型根据猜测修正关键参数。

什么时候需要用户确认工具调用？

涉及写操作、删除、付款、外发、权限变更、隐私数据、不可逆影响或高成本操作时需要确认。只读、低风险、可重试工具可以自动执行，但仍要记录审计。

工具返回失败时模型应该怎么做？

应该基于错误类型处理：可重试就重试或换路由，权限不足就说明限制，参数缺失就追问，空结果就说明未查到。不能把失败结果编造成成功结论。

如何评估 Function Call 幻觉治理效果？

看工具选择准确率、参数有效率、无工具场景误调用率、该调用未调用率、越权拦截率、错误恢复率、用户确认通过率和人工标注 badcase 下降。