Data Formulator 开源模型评估实战基于 Ollama 的双维度成功率 × 质量Agent 基准方案【免费下载链接】data-formulator Data Formulator is an interactive AI-powered data analysis system makes it easy to connect, explore and visualize data.项目地址: https://gitcode.com/GitHub_Trending/da/data-formulator导读Data Formulator 是一个由 AI Agent 驱动的交互式数据分析系统其核心能力依赖大模型驱动 analyst 类智能体完成查看表格 → 编写转换代码 → 提交可视化的完整链路。为了让开源社区与部署者能在本地Ollama跑通并量化这类开源模型的真实表现仓库在loops/model-evaluation/plan.md中沉淀了一份端到端评测计划用冻结的 45 道题、15 个数据集对 1B → 120B 各规模档位的 Ollama 模型在两种 Agent 传输协议analyst原生工具调用 /mini纯 JSON 契约下做正交评测并始终与 Azure 侧gpt-5.5、gpt-5-mini参考基线对照。读完本文你将掌握这套两轴分离成功率 × 0-100 质量分的基准设计、五步执行流水线与仓库内的源码支撑可以直接复用到自己的模型选型与调优中。一、评估目标为什么必须把成功率和质量拆成两个轴计划开篇就点明了核心方法论不要用一个总分掩盖两种本质不同的失败。轴一成功率reliability——Agent 是否真正产出了一张渲染成功的图表它度量的是能不能把事做完即端到端可靠性。轴二质量competence——当图表确实产出后它画得有多好由代码 视觉双通道评分器给出 0-100 分度量的是模型能力上限。计划特别强调一个模型可能写出好代码却无法把它通过协议送达并渲染出来。这正是开源模型与商用模型差距最大的环节。计划中有一句非常关键的经验判断The dominant open-model failure mode isdriving the tool/transport, not analyzing the data.也就是说开源小模型最容易翻车的地方不在读懂数据、写对 pandas 代码而在正确驱动工具调用/传输协议。因此每个模型都必须在不止一种 Agent 传输下运行否则你会把传输能力差误判成数据分析能力差。二、被评估对象两种 Agent 传输 Azure 参考基线2.1analyst原生函数/工具调用循环analyst是 Data Formulator 的统一数据分析 Agent采用经典的tool-calling 循环inspect → act → observe → 重复。从 AnalystAgent 实现 可以看到它的核心设计检查型工具inspection toolsexecute_python_script、inspect_source_data、load_skill等只读、可并行、无副作用用于收集信息提交型动作committing actionsvisualize、delegate等渲染用户可见的结果动作结果以 observation 字符串的形式作为 tool-call 结果回喂给模型让模型自行决定下一步gated 动作如write_report只有先通过load_skill加载对应 skill 后才开放。运行以模型不再提交动作、直接给出纯文本回答而结束即completion事件见 run() 的事件类型契约。计划为它配置的默认max_iterations 5恰好就是 Agent 构造器的默认值agent.py 第 283 行系统提示词中明确这是动作预算的硬上限SYSTEM_PROMPT 的 budget 段落。计划还提到 analyst 带有一个content-JSON salvage fallback当模型尤其是开源模型不按原生 tool-call 协议输出时客户端会从响应的 content 文本中抢救出工具调用。这一点在 Client._dispatch 的实现 中有直接证据对 Ollama 端点总是以非流式调用并在传入 tools 时调用_salvage_tool_calls_from_content从 content 中解析 JSON 形式的工具调用该函数定义于 client_utils.py 第 169 行。2.2mini单决策、纯提示词 JSON 契约生产低成本 Agentmini是计划认定的生产环境低成本 Agent对应源码中的 MiniAnalystAgent每次运行只做一个分析决策就停止返回二者之一visualize——一段数据转换脚本 图表规格默认路径几乎每个问题都该走这里explain——一段简短纯文本回答仅当用户明确不要求图表如是非/事实性问题。它完全走纯文本 JSON 传输_call_model/_parse_action/_run_inspection_tool三条传输缝隙所以函数调用能力弱甚至缺失的模型也能工作。关键工程细节图表类型被刻意收窄为 7 种常见类型_MINI_CHART_TYPES避免小模型在二十多种图表类型里瞎猜单决策意味着max_iterations被强制为 1mini_agent.py 第 221 行但在图表失败时会做就地修复把错误回喂模型让它修同一张图默认修复预算_AUTO_REVISION_ATTEMPTS 3mini_agent.py 第 216 行提交的 visualize 仍复用基础 core-skill 分发_dispatch_skill_action所以产出的事件结构与 analyst 完全一致评测脚本可统一消费。2.3 参考基线Azuregpt-5.5/gpt-5-mini计划要求每个单元格cell都始终包含 Azure 侧的gpt-5.5、gpt-5-mini作为参考基线。它们不参与排名竞争而是作为同题同条件下的能力天花板参照用来回答开源模型距商用基线差多少、差在哪传输还是分析。三、评测数据45 问 / 15 数据集的强制自 join设计计划刻意不采用 VisBench 派生的单表data.csv而是喂给 Agent原始表 / 按组归并的表逼它自己完成 join。三路来源总计 45 问、15 数据集来源形态题量考察重点vega_datasets单表9单表查询与聚合TidyTuesday每周多 CSV18多文件 join 与清洗Spider按数据库分组的库表18多表 join 库模式理解每道题复用 VisBench 的质量过滤后问题与参考图表reference chart。单表 vs 多表9 / 36是模型表现分化最大的轴因此后续所有报告都必须呈现这个维度拆分。需要注意的是plan.md中引用的../visbench基准目录位于本仓库快照之外相对loops/model-evaluation/的上一级loops/下评测前需自行获取并物化该基准。四、五步执行流水线步骤 1模型选取与拉取1B → 120B 分层 3 个 Azure 参考计划要求覆盖 1B 到 120B 的开放模型名册按规模档位分层外加三个 Azure 参考。Ollama 本地模型通过ollama pull拉取例如按测试用例可见的命名习惯qwen3:32b见 test_model_registry.py 中的 Ollama 样例配置。在 Data Formulator 侧Ollama 是内置 providerBUILTIN_PROVIDERS含ollama通过环境变量注册全局模型与自定义 providerDEEPSEEK 等走同一套契约OLLAMA_ENABLEDtrue OLLAMA_API_BASEhttp://localhost:11434 # 默认即 localhost:11434可省略 OLLAMA_MODELSqwen3:32b,llama3.1:8b,qwen2.5:1.5bModelRegistry._reload()会扫描所有以_ENABLEDtrue结尾的环境变量把模型注册为global-ollama-model形态的 IDAPI Key 只保留在服务端list_public()对外暴露的公共信息不含任何敏感字段model_registry.py 第 87-102 行并有 test_no_api_key_in_public_info 守卫。客户端侧Client 的 Ollama 分支 会自动补全ollama/前缀、剥离多余的/api尾巴避免拼出/api/api/generate。步骤 2准备基准物化 冻结把 45 道题物化为 raw/grouped 源表并将 VisBench 问题 参考图表冻结frozen。冻结的意义是每个模型、每种 agent、每次运行面对的输入完全一致评测可复现、可对比、可审计。所有中间产物题面物化表、冻结清单等统一落盘到loops/model-evaluation/work/目录。步骤 3运行 Agent正交矩阵 冻结控制对每个(agent, model, question)单元格运行即analyst与mini各跑全部 45 题 × 全部模型通过--agent analyst与--agent mini选择传输计划明确禁止--agent simplesimple已被移除详见第五节原则捕获完整事件流thinking_text/tool_start/tool_result/action/result/completion/error事件类型与 AnalystAgent.run 的文档 一致并把每张图表渲染成 PNG 存档冻结控制项max_iterations 5、单次运行 240 秒超时、可恢复resumable——中途断掉的单元格可以从断点续跑这是长矩阵评测的刚需。步骤 4两阶段评分GPT-5.5 作裁判评分由 GPT-5.5 作为统一 grader分两个阶段、严格先后阶段一可靠性五道顺序门禁responded → emitted action → code ran → output → produced chart五个门必须逐级通过其中produced chart是否真的产出了渲染图表是决定性的一关只有通过这一关的运行才进入阶段二。成功率 通过图表门的运行数 / 总运行数。这五道门的设计恰好对应 Agent 事件流中的可观测里程碑模型是否应答、是否提交了动作、动作里的代码是否在沙箱里跑通、是否产出了结果数据、是否最终渲染出图表。阶段二质量0-100仅对已产出图表的运行代码审查0-50对照题目评估转换代码的合理性视觉审查0-50对照参考图表评估渲染 PNG 的匹配度。两者相加得质量分。两轴必须分开呈现严禁合并成一个数。步骤 5聚合与报告报告需要同时包含成功率与质量分两个独立轴的完整呈现绝不塌缩成一个指标仅用于排名时的派生指标success-weighted quality对全部 45 题计阶段二无图计 0与combined综合分combined 0.3 × (success_rate × 100) 0.7 × success-weighted quality单表 vs 多表拆分9 / 36 分化轴逐门门禁的 drop-off五道门各流失多少运行直接定位失败发生在应答/动作/代码/输出/图表哪一环与 Azure 参考基线的对比按规模档位的选型推荐并给出对应推荐的--agent例如小模型优先mini大模型上analyst。五、评估原则四条铁律计划的 Principles 部分是整份方案的纪律约束缺一不可两轴永不合并——combined只用于排名不做结论依据冻结控制Freeze controls——所有单元格共享同一批题目、同一个 grader、同一个max_iterations与超时任何一处不一致都会污染对比mini是生产低成本 Agentsimple已被移除——不要运行--agent simpleuvonly、无 secrets——依赖与执行统一走 uvAzure 认证走 Entra ID对应客户端 azure 分支 用DefaultAzureCredential换取azure_ad_token_provider的方式无需在代码或环境里存放明文密钥全程可恢复所有工作产物归置于work/下。六、从计划到实现仓库内的源码支撑地图Agent 主体analyst/agent.py循环型tools vs actions 契约、gated skills、max_iterations预算analyst/mini_agent.py单决策 纯 JSON 传输 就地修复。Ollama 接入model_registry.py内置 provider 与环境变量注册agents/client_utils.pyapi_base 默认http://localhost:11434、ollama/前缀归一、非流式 content salvage。Ollama 专属降级由于 LiteLLM 把reasoning_effort映射为 Ollama 的think标志不支持思考的模型会报 does not support thinkingClient.get_completion 会识别该错误并去掉该参数重试错误识别逻辑见 client_utils.py 第 325-336 行。计划评测中analyst默认 reasoning effort 为lowagent_config.py 第 51 行也可用DF_REASONING_EFFORT_ANALYST...环境变量逐 agent 覆盖。测试佐证test_model_registry.py 覆盖了OLLAMA_ENABLED / OLLAMA_API_BASE / OLLAMA_MODELS的注册、公共列表不含密钥等安全关键路径。七、产出物与后续计划的最终交付物是loops/model-evaluation/report.md最终报告与loops/model-evaluation/work/全部工作产物两者均在执行过程中生成、不在当前仓库快照内。报告须按上文第六节的结构输出让任何一个后来者都能独立复现同一批冻结题目、同一种两阶段打分、同样的双轴呈现。这套方案的价值在于把开源模型能不能撑起 Data Formulator 的 Agent 链路这个问题从印象流变成可量化、可对比、可回归的数字。【免费下载链接】data-formulator Data Formulator is an interactive AI-powered data analysis system makes it easy to connect, explore and visualize data.项目地址: https://gitcode.com/GitHub_Trending/da/data-formulator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Data Formulator 开源模型评估实战：基于 Ollama 的双维度（成功率 × 质量）Agent 基准方案
Data Formulator 开源模型评估实战基于 Ollama 的双维度成功率 × 质量Agent 基准方案【免费下载链接】data-formulator Data Formulator is an interactive AI-powered data analysis system makes it easy to connect, explore and visualize data.项目地址: https://gitcode.com/GitHub_Trending/da/data-formulator导读Data Formulator 是一个由 AI Agent 驱动的交互式数据分析系统其核心能力依赖大模型驱动 analyst 类智能体完成查看表格 → 编写转换代码 → 提交可视化的完整链路。为了让开源社区与部署者能在本地Ollama跑通并量化这类开源模型的真实表现仓库在loops/model-evaluation/plan.md中沉淀了一份端到端评测计划用冻结的 45 道题、15 个数据集对 1B → 120B 各规模档位的 Ollama 模型在两种 Agent 传输协议analyst原生工具调用 /mini纯 JSON 契约下做正交评测并始终与 Azure 侧gpt-5.5、gpt-5-mini参考基线对照。读完本文你将掌握这套两轴分离成功率 × 0-100 质量分的基准设计、五步执行流水线与仓库内的源码支撑可以直接复用到自己的模型选型与调优中。一、评估目标为什么必须把成功率和质量拆成两个轴计划开篇就点明了核心方法论不要用一个总分掩盖两种本质不同的失败。轴一成功率reliability——Agent 是否真正产出了一张渲染成功的图表它度量的是能不能把事做完即端到端可靠性。轴二质量competence——当图表确实产出后它画得有多好由代码 视觉双通道评分器给出 0-100 分度量的是模型能力上限。计划特别强调一个模型可能写出好代码却无法把它通过协议送达并渲染出来。这正是开源模型与商用模型差距最大的环节。计划中有一句非常关键的经验判断The dominant open-model failure mode isdriving the tool/transport, not analyzing the data.也就是说开源小模型最容易翻车的地方不在读懂数据、写对 pandas 代码而在正确驱动工具调用/传输协议。因此每个模型都必须在不止一种 Agent 传输下运行否则你会把传输能力差误判成数据分析能力差。二、被评估对象两种 Agent 传输 Azure 参考基线2.1analyst原生函数/工具调用循环analyst是 Data Formulator 的统一数据分析 Agent采用经典的tool-calling 循环inspect → act → observe → 重复。从 AnalystAgent 实现 可以看到它的核心设计检查型工具inspection toolsexecute_python_script、inspect_source_data、load_skill等只读、可并行、无副作用用于收集信息提交型动作committing actionsvisualize、delegate等渲染用户可见的结果动作结果以 observation 字符串的形式作为 tool-call 结果回喂给模型让模型自行决定下一步gated 动作如write_report只有先通过load_skill加载对应 skill 后才开放。运行以模型不再提交动作、直接给出纯文本回答而结束即completion事件见 run() 的事件类型契约。计划为它配置的默认max_iterations 5恰好就是 Agent 构造器的默认值agent.py 第 283 行系统提示词中明确这是动作预算的硬上限SYSTEM_PROMPT 的 budget 段落。计划还提到 analyst 带有一个content-JSON salvage fallback当模型尤其是开源模型不按原生 tool-call 协议输出时客户端会从响应的 content 文本中抢救出工具调用。这一点在 Client._dispatch 的实现 中有直接证据对 Ollama 端点总是以非流式调用并在传入 tools 时调用_salvage_tool_calls_from_content从 content 中解析 JSON 形式的工具调用该函数定义于 client_utils.py 第 169 行。2.2mini单决策、纯提示词 JSON 契约生产低成本 Agentmini是计划认定的生产环境低成本 Agent对应源码中的 MiniAnalystAgent每次运行只做一个分析决策就停止返回二者之一visualize——一段数据转换脚本 图表规格默认路径几乎每个问题都该走这里explain——一段简短纯文本回答仅当用户明确不要求图表如是非/事实性问题。它完全走纯文本 JSON 传输_call_model/_parse_action/_run_inspection_tool三条传输缝隙所以函数调用能力弱甚至缺失的模型也能工作。关键工程细节图表类型被刻意收窄为 7 种常见类型_MINI_CHART_TYPES避免小模型在二十多种图表类型里瞎猜单决策意味着max_iterations被强制为 1mini_agent.py 第 221 行但在图表失败时会做就地修复把错误回喂模型让它修同一张图默认修复预算_AUTO_REVISION_ATTEMPTS 3mini_agent.py 第 216 行提交的 visualize 仍复用基础 core-skill 分发_dispatch_skill_action所以产出的事件结构与 analyst 完全一致评测脚本可统一消费。2.3 参考基线Azuregpt-5.5/gpt-5-mini计划要求每个单元格cell都始终包含 Azure 侧的gpt-5.5、gpt-5-mini作为参考基线。它们不参与排名竞争而是作为同题同条件下的能力天花板参照用来回答开源模型距商用基线差多少、差在哪传输还是分析。三、评测数据45 问 / 15 数据集的强制自 join设计计划刻意不采用 VisBench 派生的单表data.csv而是喂给 Agent原始表 / 按组归并的表逼它自己完成 join。三路来源总计 45 问、15 数据集来源形态题量考察重点vega_datasets单表9单表查询与聚合TidyTuesday每周多 CSV18多文件 join 与清洗Spider按数据库分组的库表18多表 join 库模式理解每道题复用 VisBench 的质量过滤后问题与参考图表reference chart。单表 vs 多表9 / 36是模型表现分化最大的轴因此后续所有报告都必须呈现这个维度拆分。需要注意的是plan.md中引用的../visbench基准目录位于本仓库快照之外相对loops/model-evaluation/的上一级loops/下评测前需自行获取并物化该基准。四、五步执行流水线步骤 1模型选取与拉取1B → 120B 分层 3 个 Azure 参考计划要求覆盖 1B 到 120B 的开放模型名册按规模档位分层外加三个 Azure 参考。Ollama 本地模型通过ollama pull拉取例如按测试用例可见的命名习惯qwen3:32b见 test_model_registry.py 中的 Ollama 样例配置。在 Data Formulator 侧Ollama 是内置 providerBUILTIN_PROVIDERS含ollama通过环境变量注册全局模型与自定义 providerDEEPSEEK 等走同一套契约OLLAMA_ENABLEDtrue OLLAMA_API_BASEhttp://localhost:11434 # 默认即 localhost:11434可省略 OLLAMA_MODELSqwen3:32b,llama3.1:8b,qwen2.5:1.5bModelRegistry._reload()会扫描所有以_ENABLEDtrue结尾的环境变量把模型注册为global-ollama-model形态的 IDAPI Key 只保留在服务端list_public()对外暴露的公共信息不含任何敏感字段model_registry.py 第 87-102 行并有 test_no_api_key_in_public_info 守卫。客户端侧Client 的 Ollama 分支 会自动补全ollama/前缀、剥离多余的/api尾巴避免拼出/api/api/generate。步骤 2准备基准物化 冻结把 45 道题物化为 raw/grouped 源表并将 VisBench 问题 参考图表冻结frozen。冻结的意义是每个模型、每种 agent、每次运行面对的输入完全一致评测可复现、可对比、可审计。所有中间产物题面物化表、冻结清单等统一落盘到loops/model-evaluation/work/目录。步骤 3运行 Agent正交矩阵 冻结控制对每个(agent, model, question)单元格运行即analyst与mini各跑全部 45 题 × 全部模型通过--agent analyst与--agent mini选择传输计划明确禁止--agent simplesimple已被移除详见第五节原则捕获完整事件流thinking_text/tool_start/tool_result/action/result/completion/error事件类型与 AnalystAgent.run 的文档 一致并把每张图表渲染成 PNG 存档冻结控制项max_iterations 5、单次运行 240 秒超时、可恢复resumable——中途断掉的单元格可以从断点续跑这是长矩阵评测的刚需。步骤 4两阶段评分GPT-5.5 作裁判评分由 GPT-5.5 作为统一 grader分两个阶段、严格先后阶段一可靠性五道顺序门禁responded → emitted action → code ran → output → produced chart五个门必须逐级通过其中produced chart是否真的产出了渲染图表是决定性的一关只有通过这一关的运行才进入阶段二。成功率 通过图表门的运行数 / 总运行数。这五道门的设计恰好对应 Agent 事件流中的可观测里程碑模型是否应答、是否提交了动作、动作里的代码是否在沙箱里跑通、是否产出了结果数据、是否最终渲染出图表。阶段二质量0-100仅对已产出图表的运行代码审查0-50对照题目评估转换代码的合理性视觉审查0-50对照参考图表评估渲染 PNG 的匹配度。两者相加得质量分。两轴必须分开呈现严禁合并成一个数。步骤 5聚合与报告报告需要同时包含成功率与质量分两个独立轴的完整呈现绝不塌缩成一个指标仅用于排名时的派生指标success-weighted quality对全部 45 题计阶段二无图计 0与combined综合分combined 0.3 × (success_rate × 100) 0.7 × success-weighted quality单表 vs 多表拆分9 / 36 分化轴逐门门禁的 drop-off五道门各流失多少运行直接定位失败发生在应答/动作/代码/输出/图表哪一环与 Azure 参考基线的对比按规模档位的选型推荐并给出对应推荐的--agent例如小模型优先mini大模型上analyst。五、评估原则四条铁律计划的 Principles 部分是整份方案的纪律约束缺一不可两轴永不合并——combined只用于排名不做结论依据冻结控制Freeze controls——所有单元格共享同一批题目、同一个 grader、同一个max_iterations与超时任何一处不一致都会污染对比mini是生产低成本 Agentsimple已被移除——不要运行--agent simpleuvonly、无 secrets——依赖与执行统一走 uvAzure 认证走 Entra ID对应客户端 azure 分支 用DefaultAzureCredential换取azure_ad_token_provider的方式无需在代码或环境里存放明文密钥全程可恢复所有工作产物归置于work/下。六、从计划到实现仓库内的源码支撑地图Agent 主体analyst/agent.py循环型tools vs actions 契约、gated skills、max_iterations预算analyst/mini_agent.py单决策 纯 JSON 传输 就地修复。Ollama 接入model_registry.py内置 provider 与环境变量注册agents/client_utils.pyapi_base 默认http://localhost:11434、ollama/前缀归一、非流式 content salvage。Ollama 专属降级由于 LiteLLM 把reasoning_effort映射为 Ollama 的think标志不支持思考的模型会报 does not support thinkingClient.get_completion 会识别该错误并去掉该参数重试错误识别逻辑见 client_utils.py 第 325-336 行。计划评测中analyst默认 reasoning effort 为lowagent_config.py 第 51 行也可用DF_REASONING_EFFORT_ANALYST...环境变量逐 agent 覆盖。测试佐证test_model_registry.py 覆盖了OLLAMA_ENABLED / OLLAMA_API_BASE / OLLAMA_MODELS的注册、公共列表不含密钥等安全关键路径。七、产出物与后续计划的最终交付物是loops/model-evaluation/report.md最终报告与loops/model-evaluation/work/全部工作产物两者均在执行过程中生成、不在当前仓库快照内。报告须按上文第六节的结构输出让任何一个后来者都能独立复现同一批冻结题目、同一种两阶段打分、同样的双轴呈现。这套方案的价值在于把开源模型能不能撑起 Data Formulator 的 Agent 链路这个问题从印象流变成可量化、可对比、可回归的数字。【免费下载链接】data-formulator Data Formulator is an interactive AI-powered data analysis system makes it easy to connect, explore and visualize data.项目地址: https://gitcode.com/GitHub_Trending/da/data-formulator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考