跳到正文
世界时间EU--:--UK--:--USA--:--CN--:--PLDEFRIT中文EN

关于人工智能与技术的门户事件 · 分析 · 访谈 · 技术背景

搜索
直播
›

体育科技的数据叙事撞上更难的问题:钥匙在谁手里

体育分析一直被当成一个数据问题,等着更多人工智能来解决。但本周资料里更有用的争论在架构层面:该把原始数据交给智能体,还是给它一个可查询的数据库。

体育分析陈思远发布: 2026年9月27日5 分钟阅读资料来源 4
体育科技的数据叙事撞上更难的问题:钥匙在谁手里

体育科技多年来卖的都是同一个承诺:更多数据、更快答案、更聪明的决策。每周送到桌上的市场研究标题都靠增长率和缩写词撑场面。工程现实要乱得多。本周这批材料里有两份文件值得放在一起读。它们描述了两种相反的做法,都是把数字喂给人工智能智能体,而体育组织越来越声称自己靠这些数字运转。

Starburst 于 9 月 11 日发布了一份分析,讲智能体数据分析的两种架构。文章写给企业数据团队看,不是写给俱乐部或联赛的,但它用的例子刻意平常:一家杂货店问,上周的鸡蛋促销是否赚钱。要回答这个问题,就得知道这次促销是否拉来了本来不会上门的顾客,新顾客有没有再来,同一笔交易里还买了什么,这些商品摆在店里什么位置,它们的利润有多高。这是一条跨多个数据集的追问链。体育组织在问某次赞助活动为何拉动了门票销售时,面对的是同一形状的问题。

选项 0:把数据送到模型那里

第一种做法被 Starburst 称为选项 0:把相关数据表抽出来,以文件或直连管道的形式把原始数据送给智能体,让它自己做处理。该公司对取舍说得很直白。当智能体按接收或处理的数据项计费时,把数 TB 的数据送过去可能贵得离谱。Starburst 说,性能上的劣势让这个选项的实用性大打折扣,已经算不上一个好选项,这也是它被标成选项 0 而不是选项 1 的原因。

对体育球队来说,这笔账本来就不划算。一场比赛现在就会产生追踪数据、从视频提取的事件、票务记录、商品交易和应用遥测数据,而对这些数据提问的人却很少。按行付费把这些搬进模型,不是大多数分析部门能拿得出手的预算科目。

第二种做法是 Starburst 推荐的。让智能体直接访问数据库系统,自己写 SQL,在逐步聚焦的过程中反复迭代。数据库引擎做它本就擅长的事,用优化过的查询计划处理本地数据。智能体则负责监督,不断发出串行或并行的请求,直到有值得返回的结果。Starburst 也承认已知的缺点:智能体可能比人类难伺候得多,在工作时用试探性查询把数据库压垮。

数据库行业今后会全力支持智能体工作负载,现代数据库系统处理这类可扩展数据处理的能力也越来越强。

这就是那句话的论点,它既是工程论证,也是销售论证。Starburst 卖的就是数据库系统。即便如此,关于优化发生在哪一层的判断很难反驳:智能体在进步,但它们不会像建立在数十年查询研究之上的引擎那样高效处理数 TB 的结构化数据。

工具链实际长什么样

本周这批材料里的两个开源项目展示了在较小规模的一端,这套管道是怎么搭起来的。Adaca Analytics 于 9 月 8 日在 GitHub 上以 MIT 许可证发布,在 GA4 数据之上重建了旧的 Google Analytics 仪表盘。来自 GA4 Data API 或 BigQuery 导出的每日汇总数据进入运营方自己拥有的 D1 数据库,实时数据则留在谷歌那边。开箱即用提供六个仪表盘,每个数字都能点开进入详情页,看自己的趋势和细分。整套东西跑在 Cloudflare Workers 上,前面是 Cloudflare Access 或内置 Basic Auth。没有登录功能。

Plainoldanalytics 于 9 月 13 日发布在 GitHub 上,走的是相反路线:嵌进 Go 应用里的附加式网站分析。它不绑定存储,导入核心包不会拉进任何后端,gin 和 chi 都有适配器。流量大约每秒刷一次磁盘。运营方可以按请求设置键和值属性,把某些路由排除在日志之外,或者记录字面路由路径而不是路径参数。

这两个项目都不是体育产品。它们之所以相关,是因为它们显示出默认假设正在转移:数据留在运营方放它的地方,分析层是你自己运行的东西,而不是你租来的东西。

没人拿来做基准测试的隐私问题

DataZen 是 8 月 29 日发到 Hacker News 上的本地优先数据库客户端,它把问题直接摆出来:我的数据去哪了?这个工具以 GPLv3 发布,不需要账号,默认支持 PostgreSQL、MySQL、SQLite 和 Redis,另有 MongoDB、ClickHouse、DuckDB 和 SQL Server 的可选驱动。它内置 MCP 服务器,让 Claude、Cursor、Cline 这类智能体通过模型上下文协议查询数据库,它也能当 MCP 客户端。凭据用 AES-256-GCM 加密后存在操作系统钥匙串里。项目称只有模式和查询上下文会与用户配置的人工智能提供商共享。

最后这个区分正是体育组织该问的。模式和查询上下文不等于原始数据,但也不是无关紧要。模式会暴露一个俱乐部测量什么:存了哪些球迷属性,如何给购票者分群,追踪球员负荷的哪些方面。在一项伤病数据和合同谈判与票务数据放在同一个数据资产里的运动中,元数据本身就具有商业敏感性。

这批材料没有告诉我们任何俱乐部或联赛实际部署了什么,市场预测背后的厂商材料也不能证明采用情况。它确实显示出一条分界线。一派主张智能体应当驱动数据库,现代引擎能扛住这个负载。另一派在造工具,让数据留在本地,只把上下文送出去。体育科技将继承其数据团队选择的那个答案,而这个选择正在此刻做出,地点是开源代码仓库,而不是新闻稿。

评论 0

资料来源

4
  1. 01An Analysis of Two Architectures for Agentic Data AnalysisEN
  2. 02We rebuilt the old Google Analytics on top of GA4's dataEN
  3. 03Show HN: Plainoldanalytics: Analytics Middlware for GoEN
  4. 04Show HN: DataZen – a local-first client for cross-database workflowsEN

本文所有数字与引语均来自下列来源,未添加来源之外的内容。

本内容由编辑部在人工智能辅助下制作完成。

陈思远

陈思远

体育、汽车与旅行

陈思远负责FLASH24的体育、汽车与旅行报道,他从联赛官方数据、车队技术公报和旅行目的地统计中提取信息,重点关注规则执行与数据一致性,不放过任何一处数字矛盾。在体育报道中,他逐场核对射门、跑动和犯规数据,并比对视频助理裁判的判罚记录;在汽车与旅行板块,他同样坚持用实测油耗、里程和票价来验证每一条结论。他常与赛事数据员、车队工程师和当地向导沟通,每逢联赛关键轮次或新车发布便提前整理对比表格。业余时间他打业余篮球,也研究联赛数据与视频助理裁判的判罚逻辑,这些爱好让他更清楚数据背后的实际节奏。他坚持一条原则:未经核实的数据不写进稿子。

编辑部 →

评论

0
  1. 还没有评论——来说两句吧。

写评论

评论公开展示。我们不发布辱骂、垃圾信息和广告内容。