跳转至

四十五:工具 Tool自测题答案

来源:http://mp.weixin.qq.com/s?__biz=MzYyNTk3Njg1NA==&mid=2247484617&idx=1&sn=d03404756b240b3963ad71fe0d9c3863&chksm=f01eb7b0c7693ea604df66491a310574b19d5810e831075e681de8cb0cfc77d5418d06b4acf8#rd

参考资料

  • Toolformer: Language Models Can Teach Themselves to Use Tools: https://arxiv.org/abs/2302.04761

  • MRKL Systems: A modular, neuro-symbolic architecture that combines large language models, external knowledge sources and discrete reasoning: https://arxiv.org/abs/2205.00445

  • HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face: https://arxiv.org/abs/2303.17580

  • OpenAI Function Calling guide: https://platform.openai.com/docs/guides/function-calling

A. Tool 基础

1. LLM Agent 中的 Tool 是什么?它解决了哪些模型能力边界问题?

Tool 是 LLM 通过结构化接口调用的外部能力,例如搜索、数据库、计算器、代码执行器、业务 API 或多模态模型。它解决 LLM 在实时信息、精确计算、外部动作、专业模型能力和可验证执行方面的不足。评分点:要强调 Tool 是外部可执行能力,不只是 prompt 技巧。

2. Tool Calling 和 Agent 有什么区别?

Tool Calling 是模型生成工具调用意图和参数的能力;Agent 是围绕目标进行规划、调用工具、观察结果、更新状态和完成任务的系统。一个 Agent 可以使用 Tool Calling,但一次 Tool Calling 不等同于完整 Agent。

3. 为什么说 Tool 是 Agent 的动作空间?

Agent 需要对外部世界采取行动。工具定义了 Agent 可以执行哪些动作,例如搜索、写文件、查询数据库、调用模型。Planning 决定行动顺序,Tool 提供可执行动作,Observation 提供反馈。

4. 一个工具接口通常应包含哪些组成部分?

通常包含工具名、描述、参数 schema、执行函数、返回 schema、错误约定、权限策略和审计信息。生产系统还应定义超时、重试、幂等性和风险等级。

5. 工具描述为什么会显著影响模型的工具选择?

模型根据工具名和描述判断工具适用场景。描述过宽会导致误调用,描述过窄会导致漏调用,描述与真实能力不一致会导致模型提出工具无法完成的请求。工具描述本质上是模型的路由提示。

6. 参数 schema 在工具调用中有什么作用?

参数 schema 限定输入字段、类型、必填项、枚举值和嵌套结构。它减少自然语言歧义,便于参数验证、自动补全、日志记录和调用执行。没有 schema,工具调用会变成难以校验的自由文本。

7. 工具返回结果为什么也需要结构化?

结构化返回便于模型理解结果、区分成功和失败、提取关键字段、进行后续工具调用和审计。非结构化长文本容易让模型误读工具结果,尤其在多步工具链中。

8. 工具调用循环的基本流程是什么?

基本流程是用户输入、模型判断是否需要工具、生成工具名和参数、宿主程序验证并执行工具、工具返回 observation、模型融合结果生成最终回答或继续调用工具。

9. 工具型 Agent 和普通 RAG 系统有什么区别?

RAG 主要检索外部知识并生成答案,动作通常是检索。工具型 Agent 的动作空间更广,可以搜索、计算、执行代码、调用业务系统、控制多模态模型,还需要规划、权限、执行和错误处理。

10. 工具型 Agent 为什么需要权限控制和审计?

工具可能读写文件、调用业务接口、产生费用或改变外部状态。权限控制防止越权和高风险操作,审计日志用于追踪调用原因、参数、结果和责任归属。

B. Function Calling

11. Function Calling 的基本工程流程是什么?

开发者定义函数 schema,模型根据用户请求输出函数调用和参数,宿主程序验证参数并执行函数,再把函数结果返回给模型,模型基于结果生成最终回复或继续调用其他函数。

12. 模型在 Function Calling 中负责什么,宿主程序负责什么?

模型负责理解意图、选择函数和生成参数。宿主程序负责校验参数、执行函数、处理权限、捕获错误、记录日志和把结果返回给模型。真正执行不应由模型本身完成。

13. 为什么不能直接信任模型生成的函数参数?

模型可能误解用户意图、缺少字段、生成非法值、编造 ID、越权请求或受 prompt injection 影响。参数必须经过类型检查、范围检查、权限检查和业务规则验证。

14. Function Calling 适合哪些任务场景?

适合参数明确、可程序化执行、返回可验证的任务,例如查询订单、搜索文档、调用天气 API、执行计算、创建日程、读写结构化数据和触发低风险自动化流程。

15. Function Calling 不适合或需要谨慎使用哪些场景?

需要谨慎处理支付、删除数据、权限变更、医疗金融法律决策、不可逆操作和需要强身份确认的操作。这类场景即使用 Function Calling,也要增加用户确认和人工审核。

16. 多次 Function Calling 时需要管理哪些状态?

需要管理对话状态、已调用工具、工具返回结果、中间变量、任务计划、依赖关系、错误状态、重试次数和最终完成条件。否则多步调用容易重复、漏步或顺序错误。

17. 工具调用失败后系统应如何处理?

应识别失败类型,返回结构化错误,必要时重试、换工具、请求用户补充参数或降级回答。不能让模型把失败结果说成成功结果。

18. 高风险函数调用为什么需要用户确认?

高风险调用可能造成真实世界影响或不可逆后果。模型参数可能错误或被攻击操纵,因此需要在执行前向用户展示动作、目标对象和影响范围,获得明确确认。

19. 如何评估 Function Calling 的参数正确性?

可以评估函数选择准确率、必填字段完整率、字段类型正确率、值准确率、约束满足率、执行成功率和最终任务成功率。最好用包含负例和歧义请求的测试集。

20. Function Calling 与传统 API 调用有什么区别?

传统 API 调用由程序员显式写逻辑触发。Function Calling 中,模型根据自然语言动态选择 API 并生成参数,但执行和权限仍由程序控制。它把自然语言意图解析与 API 调用连接起来。

C. Toolformer

21. Toolformer 的核心思想是什么?

Toolformer 的核心思想是让语言模型通过自监督方式学会使用工具。模型在普通文本中采样 API 调用,执行 API 后把结果插回文本,再保留能降低语言建模损失的调用样本用于微调。

22. Toolformer 为什么被称为自监督学习工具使用的方法?

因为它不依赖大量人工标注的工具调用数据,而是从普通文本中自动生成候选调用,并用模型自身的语言建模损失判断调用是否有帮助。筛选后的样本构成训练数据。

23. Toolformer 如何从普通文本中构造工具调用训练样本?

流程是对文本位置采样可能的 API 调用,生成调用参数,执行 API,把结果插入文本,比较插入前后的语言建模损失。只有明显改善预测的调用会被保留。

24. Toolformer 为什么要用语言建模损失筛选 API 调用?

损失下降说明工具结果对预测后续文本有帮助,从而可作为自监督信号。这样可以过滤掉无用、错误或位置不合适的 API 调用,提升训练数据质量。

25. Toolformer 论文中涉及哪些典型工具?

包括计算器、日历、搜索引擎、问答系统和机器翻译系统。这些工具对应 LLM 常见短板:精确计算、日期推理、外部事实、专业问答和翻译。

26. Toolformer 学到的是哪些工具使用能力?

它学习何时调用工具、调用哪个工具、如何生成参数、如何把工具返回结果纳入后续生成。核心是工具使用行为内化到模型生成过程中。

27. Toolformer 相比人工标注工具调用数据有什么优势?

优势是标注成本低、可扩展、能利用大规模原始文本,并减少对人工设计样本的依赖。它适合探索工具使用的自动数据构造方法。

28. Toolformer 的主要限制是什么?

限制包括依赖可自动执行的 API、采样和筛选质量影响很大、工具集合扩展成本高、微调成本较高、对复杂多步规划支持有限,并且不解决完整执行系统的权限和错误处理。

29. Toolformer 和 Function Calling 的区别是什么?

Toolformer 是训练方法,让模型通过自监督数据学习工具使用;Function Calling 是推理时的工程接口,让模型输出结构化函数调用。前者偏模型学习,后者偏系统集成。

30. Toolformer 为什么不等同于完整 Agent 系统?

Toolformer 主要解决工具调用能力,不包含完整的长期目标管理、状态跟踪、权限控制、错误恢复、反思、记忆和复杂执行编排。因此它是工具使用方法,不是完整 Agent 架构。

D. MRKL

31. MRKL 的全称和核心思想是什么?

MRKL 是 Modular Reasoning, Knowledge and Language。核心思想是把 LLM 与外部知识源、符号推理模块和专家系统组合,由路由器把任务分发给合适模块。

32. MRKL 为什么被称为神经符号架构?

因为它结合了神经网络模型的语言理解和生成能力,以及符号系统、数据库、计算器、规则引擎等可解释、可验证模块。它不是让 LLM 独自完成所有任务。

33. MRKL 中 router 的作用是什么?

Router 判断输入应交给哪个专家模块或模块组合处理。它可以基于规则、分类器或 LLM 决策。Router 质量直接影响系统是否调用正确能力。

34. MRKL 中 expert module 可以包括哪些能力?

可以包括计算器、搜索、知识库查询、数据库、规则引擎、代码执行器、翻译模型、领域分类器、规划器和其他专用模型。

35. MRKL 相比单一 LLM 有什么优势?

优势是能使用可靠专业模块,提高精确性、可解释性和可扩展性;还可以按任务接入不同知识源,减少让 LLM 记住所有事实或执行所有计算的压力。

36. MRKL 的主要工程挑战是什么?

挑战包括路由准确性、模块接口统一、模块结果融合、错误传播、延迟成本、权限控制和可观测性。专家模块越多,调度和调试越复杂。

37. MRKL 和现代 Tool Calling 有什么关系?

现代 Tool Calling 可以看作 MRKL 思想的工程化实现之一。工具就是专家模块,模型或系统路由器负责选择工具,返回结果再交给 LLM 融合。

38. MRKL 和 RAG 有什么区别?

RAG 主要是检索外部文档增强生成,MRKL 是更广义的模块化架构,可包含检索、计算、规则推理、API、代码执行等多种专家模块。RAG 可以是 MRKL 中的一个模块。

39. MRKL 如何提升可解释性?

MRKL 可以记录路由到哪个模块、模块输入是什么、返回结果是什么。相比纯 LLM 生成,模块调用链更容易审计和定位错误。

40. MRKL 架构在今天的 Agent 系统中仍有什么价值?

它提供了模块化、专家化和可审计的系统设计原则。现代 Agent 的 tool routing、retriever、代码执行器和业务 API 调用都延续了 MRKL 的思想。

E. HuggingGPT

41. HuggingGPT 想解决什么问题?

HuggingGPT 想解决单个 LLM 无法处理所有专业和多模态任务的问题。它让 ChatGPT 作为控制器,调用 Hugging Face 上的大量专用模型完成复杂 AI 任务。

42. HuggingGPT 的总体架构是什么?

总体架构是 LLM 控制器加模型库工具集合。流程包括任务规划、模型选择、任务执行和响应生成。LLM 负责理解和协调,Hugging Face 模型负责具体任务执行。

43. HuggingGPT 为什么选择 ChatGPT 作为控制器?

因为 ChatGPT 具备较强自然语言理解、任务分解、指令跟随和结果组织能力,适合作为中枢控制器把用户请求转成子任务和模型调用计划。

44. HuggingGPT 的四个阶段分别是什么?

四个阶段是 Task Planning、Model Selection、Task Execution、Response Generation。它们分别解决拆任务、选模型、执行模型和汇总结果。

45. Task Planning 阶段负责什么?

负责理解用户请求,拆分成多个结构化子任务,确定任务类型、输入输出、依赖关系和执行顺序。规划质量决定后续系统是否在正确方向上执行。

46. Task Planning 中为什么需要识别子任务依赖关系?

因为多模态任务常有前后依赖,例如先图像描述,再翻译,再文生图。如果依赖关系错误,后续模型可能拿不到正确输入,导致整个任务失败。

47. Model Selection 阶段如何选择合适模型?

根据子任务类型、模型描述、输入输出格式、可用性、性能信息和资源约束选择模型。模型描述越准确,选择越可靠。

48. 模型描述质量为什么会影响 HuggingGPT 效果?

模型选择依赖模型描述。如果描述含糊、过时或夸大能力,LLM 控制器会把任务分配给不合适模型,导致执行失败或结果质量差。

49. Task Execution 阶段需要解决哪些工程问题?

需要处理模型调用、输入输出格式转换、文件路径、依赖顺序、并行执行、失败重试、超时、资源限制和中间结果传递。这一阶段必须由真实执行系统支持。

50. Response Generation 阶段有哪些风险?

风险包括忽略工具错误、编造执行结果、过度解释模型输出、漏掉部分子任务结果、把中间结果当最终答案。最终回答应基于真实执行 trace。

51. HuggingGPT 如何处理多模态任务?

它把多模态请求拆成不同任务类型,如图像分类、图像描述、语音识别、文本生成、翻译、文生图,再为每个子任务选择 Hugging Face 模型,并把输出串联成后续输入。

52. HuggingGPT 与 Toolformer 的区别是什么?

Toolformer 关注模型如何通过自监督学习使用工具,偏训练方法。HuggingGPT 关注 LLM 如何作为控制器调度大量外部模型,偏系统架构和多模型编排。

53. HuggingGPT 与 MRKL 的区别是什么?

MRKL 是模块化神经符号架构的通用思想,HuggingGPT 是把这种思想应用到 Hugging Face 模型库的具体系统,并明确提出四阶段流程。

54. HuggingGPT 与 Function Calling 的关系是什么?

Function Calling 可以作为 HuggingGPT 的工具调用接口。HuggingGPT 解决如何规划任务和选择模型,Function Calling 解决如何把模型调用结构化、校验和执行。

55. HuggingGPT 可以被看作哪类 Agent 系统?

可以看作工具增强型、多模型调度型、多模态 Agent 系统。它以 LLM 为 planner/coordinator,以模型库为工具集合。

F. 工具型 Agent 失败模式

56. 工具选择错误通常有哪些原因?

原因包括工具描述不清、工具能力重叠、任务理解错误、缺少路由规则、模型不了解工具边界、上下文中有错误示例或工具不可用。

57. 参数抽取错误会如何影响工具调用结果?

参数错误会导致查询错误对象、时间范围不对、输入格式不合法、调用失败或返回误导性结果。多步链路中,早期参数错误会传播到后续工具调用。

58. 工具描述不清会造成哪些问题?

会造成误调用、漏调用、参数误填、工具之间混淆和模型对工具能力过度假设。工具描述应明确适用场景、输入要求、输出格式和限制。

59. 任务拆分错误为什么会导致 HuggingGPT 失败?

HuggingGPT 后续模型选择和执行都依赖任务规划。如果子任务缺失、顺序错误或依赖错误,即使选中的单个模型表现很好,整体任务也会失败。

60. 模型选择错误在 HuggingGPT 中如何发生?

可能因为任务类型识别错误、模型描述不准确、输入输出格式不匹配、模型不可用或 LLM 对模型能力理解错误。选择错误会导致执行失败或输出不符合需求。

61. 工具返回结果被误读会造成什么后果?

模型可能把错误结果当成功、把低置信结果当确定事实、忽略 warning,或误解结构化字段。最终回答会脱离真实工具结果,产生 grounding 问题。

62. 工具调用失败后没有重试或降级会带来什么风险?

系统可能直接失败、编造结果或输出不完整答案。可靠系统应根据错误类型决定重试、换工具、降级、请求用户补充或明确报告失败。

63. 什么是工具结果幻觉?

工具结果幻觉是指模型声称工具返回了某个结果,但实际工具没有返回、调用失败或结果并不支持该结论。解决方法是最终回答绑定 tool trace 和实际 observation。

64. 工具权限过宽为什么危险?

权限过宽会让模型或攻击者触发不该执行的操作,例如删除文件、泄露数据、调用昂贵 API 或修改业务状态。工具权限应遵循最小权限原则。

65. 如何设计工具型 Agent 的 tool trace?

Trace 应记录工具名、调用时间、调用者、参数、权限检查、返回结果、错误、重试、耗时、成本和最终答案引用。这样可以定位工具链路中的失败点。

G. 评估与生产化

66. 工具型 Agent 应该评估哪些指标?

应评估工具选择准确率、参数准确率、执行成功率、结果 grounding、端到端任务成功率、延迟、成本、安全合规率、错误恢复率和用户确认命中率。

67. 如何评估 HuggingGPT 的端到端任务成功率?

应构造多模态、多步骤任务集,检查任务规划是否完整、模型选择是否正确、执行是否成功、中间结果是否正确传递、最终回答是否满足用户请求。只看最终文本流畅度不够。

68. 如何提升工具型 Agent 的可靠性?

可以改进工具描述和 schema、加入参数验证、使用 planner 和 verifier、记录 tool trace、对失败做重试降级、限制高风险工具权限、引入测试集和持续监控。

69. 工具型 Agent 在生产中需要哪些安全边界?

需要最小权限、用户确认、参数校验、沙箱执行、敏感数据过滤、调用限额、审计日志、错误隔离和 prompt injection 防护。高风险工具不应无条件由模型自由调用。

70. 请系统总结 Toolformer、MRKL、Function Calling 和 HuggingGPT 的原理、区别、优缺点和面试表达要点。

Toolformer 是自监督训练方法,让模型学习何时以及如何调用工具。MRKL 是模块化神经符号架构,把 LLM 和专家模块通过路由组合。Function Calling 是工程接口,让模型输出结构化工具调用参数。HuggingGPT 是系统架构,用 ChatGPT 调度 Hugging Face 模型完成复杂多模态任务。面试中要强调四者层级不同:训练方法、架构思想、工程接口、具体系统。共同难点是工具选择、参数正确性、执行可靠性、结果 grounding、安全边界和可观测性。

            预览时标签不可点




































<div class="