工具选择评测：给 AI 的分诊台发一张考核单

可视化演示

演示AI Agent工具选择评测：工具选择展示请求与候选工具的匹配过程；指标体系展示单工具准确率、多工具准确率与错误类型分类；位置偏差展示首因效应对工具列表不同位置选择准确率的影响。

1. 概念与流程

急诊分诊台是医院的第一道防线。患者被推进门时，护士必须在三秒内从脑海中调出全部科室的收治范围，快速与症状比对，然后作出判断。分诊错了，后面再高级的治疗设备也白搭。工具选择在大模型系统中扮演着同样重要的“第一道防线”角色：模型必须在调用任何外部 API 之前，先从工具清单里挑出正确的那一个。

在技术上，工具选择属于大模型工具调用（function calling）的第一个环节。系统提供给模型一份工具清单，模型根据用户请求选择一个工具并生成 JSON 参数。比如用户说“帮我订明天去上海的机票”，模型不能调“查天气”工具，而应当选择“订机票”工具并填好出发地、目的地和日期。工具选择评测，就是把这个环节当成独立对象来考核，看模型在大量请求下能否做出正确选择。

评测的整体流程通常拆成四步：输入构造（准备用户查询与工具列表）、模型推理（让模型输出工具调用）、输出解析（提取工具名与参数）、结果判定（与标准答案比对）。其中最常用的基础指标是 Top-1 工具命中率，它衡量模型把正确工具排在第一位并选中的比例。

分诊台靠标准作业流程保证服务质量，工具选择评测也靠同样的标准化思路，把模糊的“模型好不好”变成清晰可对比的数字。有了这个起点，后续的维度设计、数据构建和错误分析才能展开。

2. 评估维度

一个只会背标准答案的护士并不合格。真实分诊中，患者症状很少和教科书完全一致：胸痛可能是心梗，也可能是胃酸反流；头晕可能是低血糖，也可能是脑供血不足。一名好的分诊护士要同时具备三种能力：能看出细微差别、能听懂模糊描述、敢在超出范围时说“这个不归急诊管”。

对应到工具选择评测，这三个能力正好映射为三个核心维度。工具辨识考察模型能否区分名字或描述相近的工具，比如“发送邮件”和“保存草稿”之间的边界；参数匹配考察模型是否填全并填对了工具要求的参数，比如订机票时必须提供出发地、目的地和日期；否决判断则考察当工具列表里没有合适选项时，模型能否干脆地拒绝调用，而不是硬选一个勉强相关的工具。

为了让多个维度的得分可以合成一个整体分数，工程上常用加权综合分。权重 w 由业务重要性决定，比如参数错误会导致调用失败，权重就应高于对工具描述细节的辨识。

分诊考核表上每一项打分都有意义，工具选择评测也一样。只看总分容易掩盖问题，拆开维度逐个打分，才能让工程师清楚地知道“这版模型到底差在识别工具，还是差在填参数”。

3. 数据构建

考卷一成不变，考核就失去意义。如果急诊考核清一色是“手指划破去外科”这种送分题，再差的学生也能及格；如果全是闻所未闻的罕见病，又无法反映真实水平。好的病例库必须覆盖轻伤、重症、复合伤、伪症状，既要有典型样本，也要有易混淆样本。

工具选择评测的数据集构建有几种常见手段。人工标注由领域专家编写典型三元组：用户请求、目标工具、期望参数，质量最高但成本也最高；自动生成借助模板和大模型批量产出请求与工具调用，速度快但容易出现模式化文本；数据增强对已有样本做同义改写、参数扰动和场景扩展，以低成本提升覆盖度。无论用哪种方式，最后都必须经过质量检查，剔除答案错误、描述不清或语义重复的样本。

数据质量可以用难度系数 d 来刻画，d 接近 0 表示极其简单，d 接近 1 表示非常困难。单个样本的难度由目标工具是否唯一、参数是否容易被推断等因素决定，数据集整体难度取所有样本的平均值。

考试难易要适中，智能体的考核题也一样。适度难度才能拉开差距，让你真正看出哪个模型是经验丰富的老手，哪个只是背下了一堆标准答案。

4. 评测实施

有试卷还不够，还得有考场纪律和批卷标准。分诊考核中，监考老师会严格控制情境和时间，并要求每一份分诊单按固定格式填写。如果有的考生用中文答、有的用英文答、有的随手画个箭头指向科室，批卷人根本没法公平打分。

评测实施同样有三个关键环节。输入设计要保证测试样本里的工具描述干净、参数齐全，避免模型因为工具描述混乱而误判，还要把用户请求写得自然真实。输出解析负责把模型返回的内容稳定解析成结构化数据，即使模型输出里混着多余的文字或解释，也要能够准确提取出工具调用片段。判定标准则决定打分尺度，常用两种口径：精确匹配要求工具名和参数全部严格一致；宽松匹配只比对工具名，不检查参数细节。

这两种口径各有适用场景：精确匹配用于正式评估，宽松匹配适合早期粗筛。使用多种口径时，可以给不同匹配级别计不同权重，得到一个综合准确率。

只有考场严格，分数才可信。把输入设计标准化、输出解析鲁棒化、判定口径明确化，评测拿到手的准确率才能服众，也才能安全地用于模型选型。

5. 错误分析

考试最重要的一环是复盘。分诊护士如果从来没人告诉她“刚才那个是误判，患者其实应该去心内科而不是急诊科”，她下一次还会犯同样的错。没有反馈的评测，只是一堆冰冷的数字。

工具选择评测的错误分析通常先按类型归类。工具选错指目标工具识别错误，比如把“查快递”选成了“查天气”；格式错误指模型输出无法被解析成工具调用，比如返回了纯文本而不是 JSON；参数错误指工具选对了但参数缺失或填错，比如订机票只写了目的地没写日期。除这三类之外，还有一类高频问题叫相似工具混淆，例如“咨询人工客服”和“提交工单”这两个工具语义距离很近，模型很容易摇摆不定。

把各类错误样本数加起来，就是总错误数。分析时看哪一项占比最高，就优先优化哪一项。常见的优化手段包括：补充更精确的工具描述、给每个工具附加一两个典型调用示例、在系统提示词中明确“没有合适工具时不要调用”。

复盘会开完了，分诊水平才能提升。在评测环节引入细致的错误分析，等于给模型开了一堂“错题讲解课”——改进工具描述、补充示例、强化提示词，每一项优化都会在下一轮分数上得到直接反馈。

6. 场景应用

分诊考核不是为了在台上表演，而是为了让整个医院更高效地运转。工具选择评测同样不是实验室里的摆设，它已经在 RAG 与 Agent 的实际落地场景中发挥关键作用。

在 RAG 应用中，模型可能需要选择不同的检索器：学术问题去查向量知识库，订单问题去查业务数据库，常见问题去查 FAQ 知识库。这个“路由器”如果选错，后续的检索和生成都会被带偏。工具选择评测可以系统性地验证路由器在各类型问题上的分流正确率。在 Agent 应用中，多步规划场景下模型每走一步都要决定调用哪个工具，评测关注的不再是单次选择，而是整个对话流程中的累积命中率。

评估多轮 Agent 的表现时，常使用前 k 轮累积正确率 P@k。它把每个测试场景前 k 轮内正确工具调用的总数，除以理论上应发生的工具调用总数，最终得到一个百分比。

无论是前台接待还是多科室协作，分诊能力都是系统可靠性的地基。工具选择评测让这块地基有据可查：RAG 不会查错库，Agent 不会走错步，多轮对话不会越聊越偏。

7. 工程要点

分诊培训不是期末考一次就完事。医院质量部会定期抽考、追踪每位护士的通过率变化，并针对新出现的病例更新培训手册。评测要真正发挥价值，也必须成为持续运转的工程体系，而不是一次性脚本。

工程化落地工具选择评测，通常需要四个组件。测试套件把测试数据分层管理，比如按业务域、难度等级和错误类型分目录存放；指标报表把每次评测的得分、错误分布和趋势变化可视化，方便团队快速决策；回归机制在模型每次迭代后自动重跑评测集，防止新版本“按下葫芦浮起瓢”；迭代闭环把线上新收集的错误样本持续回填进测试集，让评测覆盖范围越滚越大。

回归机制中一个很直观的指标是回归合格率 R。它表示新模型在既有测试集上通过的用例数占全部回归用例数的比例，只有这个比例不下降，新版本才允许进入上线流程。

持续抽考、持续反馈，分诊台才会越用越稳。工具选择评测进入 CI/CD 流程之后，AI 系统每一次迭代都能稳稳走在正轨上——这，才是从“一次性考核”走向“质量管理体系”的关键一步。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""工具选择评测小型演示 - 模拟一场分诊考核""" TOOLS = [    {"name": "get_weather", "desc": "查询城市天气", "params": ["city"]},    {"name": "book_flight", "desc": "预订航班", "params": ["from", "to"]},    {"name": "send_email", "desc": "发送邮件", "params": ["to", "content"]},] TESTS = [    {"query": "北京今天冷吗", "target": {"name": "get_weather", "params": {"city": "北京"}}},    {"query": "帮我订一张去上海的机票", "target": {"name": "book_flight", "params": {"from": "深圳", "to": "上海"}}},    {"query": "把周报发给经理", "target": {"name": "send_email", "params": {"to": "manager", "content": "周报"}}},    {"query": "我想知道上海降水概率", "target": {"name": "get_weather", "params": {"city": "上海"}}},]  def mock_llm_select(query):    """模拟大模型的工具选择输出"""    if any(word in query for word in ["天气", "冷", "热"]):        return {"name": "get_weather", "params": {"city": "北京"}}    if any(word in query for word in ["机票", "航班", "订票"]):        return {"name": "book_flight", "params": {"from": "深圳", "to": "上海"}}    if any(word in query for word in ["周报", "邮件", "发给"]):        return {"name": "send_email", "params": {"to": "manager", "content": "周报"}}    return {"name": "send_email", "params": {"to": "unknown", "content": query}}  def exact_match(pred, target):    return pred["name"] == target["name"] and pred["params"] == target["params"]  def loose_match(pred, target):    return pred["name"] == target["name"]  def run_evaluation(tests, mode="exact"):    """按指定判定模式跑一次评测, 返回统计结果"""    judge = exact_match if mode == "exact" else loose_match    passed = 0    for case in tests:        pred = mock_llm_select(case["query"])        if judge(pred, case["target"]):            passed += 1    accuracy = passed / len(tests) * 100    return {"total": len(tests), "passed": passed, "accuracy": accuracy}  if __name__ == "__main__":    for mode in ["exact", "loose"]:        result = run_evaluation(TESTS, mode)        print("mode={} total={} passed={} accuracy={:.1f}%".format(            mode, result["total"], result["passed"], result["accuracy"]))

1. TOOLS = [...]定义候选工具池，每个工具包含名称、描述和参数列表，相当于急诊室的科室名录。
2. mock_llm_select(query)模拟大模型对用户请求的工具选择行为，返回一个包含工具名和参数的字典。
3. if any(word in query for word in ["天气", "冷", "热"])模拟模型通过语义匹配把请求路由到天气工具。
4. exact_match(pred, target)精确匹配判定：工具名和参数全部一致才算通过。
5. loose_match(pred, target)宽松匹配判定：只比对工具名，不检查参数细节。
6. judge = exact_match if mode == "exact" else loose_match根据评测模式动态选择判定函数。
7. accuracy = passed / len(tests) * 100计算评测准确率，这是工具选择评测最核心的输出指标。

常见误区

面试题