datainfra前沿动态 · Vol.101

Lance 开出 v15 主线，zone write seeds 把 NaN 从 min/max 里剥出去、索引插件改由进程注册；Qdrant 1.20.0 把 TurboQuant 变成一等数据类型并修正 HNSW 层级分配；Databricks 用 Unity Gateway 把 AI 花费拆成归因、路由与护栏三层；Google Cloud 给 Knowledge Catalog 装上自学习富化与 Knowledge Studio

本期聚焦 10 月 22 日四条把「由实现内部悄悄决定」改成「有版本号、有默认值、有审批边界的公开契约」的动作：统计语义写进格式、向量精度变成数据类型、AI 花费变成可归因对象、业务上下文变成带置信度与变更请求的受治理资产。

DataInfra Lance LanceDB 列存格式 ZoneMap 索引插件 RaBitQ Qdrant 向量检索 TurboQuant HNSW Databricks Unity Gateway 成本归因 Google Cloud Knowledge Catalog 上下文工程

本期四条动态全部落在 10 月 22 日这一天，来自两个开源项目与两个平台方，做的事可以概括成同一件：把一件原本由实现内部悄悄决定的事，提升成一个有版本号、有默认值、有审批边界的公开契约。Lance 在一天内打出两个标签，v15 主线的第一条破坏性变更把「NaN 怎么算进 min/max」写进格式，并把标量索引的提供者从内置固定注册表改成进程可注册；Qdrant 1.20.0 把向量精度从「量化旁路」提升成一等数据类型 turbo16 与 turbo8，把 HNSW 层级分配改回论文里的 floor()，并把内部鉴权的默认值改成强制；Databricks 用一篇访谈把 AI 花费拆成归因、路由与护栏三层，给出的接口是请求级 tag 与一个所有流量都必须流经的网关；Google Cloud 给 Knowledge Catalog 装上自学习富化，业务定义从人工维护的静态条目变成带来源引用、置信度与变更请求的受治理资产。四处动作的代价也各自写在明面上：v15 是 beta 主线且会自动打开旧客户端读不了的 feature flag，Turbo 数据类型是有损替换不留全精度副本，网关方案只在流量全量接入时成立，自学习富化目前仍是 Preview 且内部基准的数字符号要按符号读。

Lance 开出 v15 主线：把 NaN 语义写进格式，把索引插件改成进程可注册

事件概述

10 月 22 日，lance-format/lance 在同一个 UTC 日内打出两个标签。v15.0.0-beta.1 于 09:20 发布，开出 v15 这条新主线（v14.0.0 对应 Lance 2.3 格式）；v14.0.0-rc.2 于 17:42 发布，给 2.3 格式再补一个 RC。v15 的第一个 beta 只带一条破坏性变更，条目总数也远少于 v14 RC（228 条量级）的规模，但那一条把统计口径从代码行为改成了格式契约。

同日 lancedb/lancedb 发布 v0.41.0-beta.13（11:54），两条破坏性变更都落在「自动刷新」这组创建选项上。

技术解析

  • zone write seeds v1（#10102）：zone write seeds 是写数据文件时顺带收集的每列统计，后续索引更新可以直接复用而不必再把列读一遍。V1 的核心变动是把 NaN 从 min/max 里剥出去：min/max 只约束非空、非 NaN 的取值（含正负无穷），NaN 单独记 nan_count 与 negative_nan_count，zone_length 定为 UInt64。旧行为是只要出现 NaN 就把 max 写成 +NaN，把普通最大值盖掉，也说不清有没有负 NaN。PR 给了一张对照表——取值为 1, 5, +NaN 时，旧种子的边界是 min = 1、max = +NaN，V1 是 min = 1、max = 5，NaN 计为总数 1、负数 0。附带修了三类错误剪枝：只有负 NaN 的 zone 在 x < 0 下被丢掉（按 Arrow Rust 的浮点全序负 NaN 应当匹配）、只有正 NaN 的 zone 在 x > 100 下被当成空区、以及以 NaN 字面量为边界的范围查询被 nan_count 短路而丢掉普通值。
  • 破坏性边界写在明面上：这条 PR 会在带 seed 索引的表上自动打开新的 reader/writer feature flag，不支持 FLAG_ZONE_WRITE_SEEDS 的客户端读不了也写不了新快照。PR 明确说这可能由默认 ZoneMap 选项触发，不限于显式设置 use_seeds: true。
  • ZoneMap 索引 v1（#9986）：格式层同步跟进，IndexMetadata.index_version = 1，新增非空字段 negative_nan_count: UInt32，null bitmap 变为可选（没有它时空值计数只能支持剪枝、候选行需要重查）。V0 仍可读但 NaN 符号未知，也不能简单改标成 V1——补齐缺失统计可能要重新扫一遍。该 PR 只改文档（docs/src/format/index/scalar/zonemap.md），运行时支持另做。
  • 外部标量索引插件（#10111、#10232）：过去应用可以实现 ScalarIndexPlugin，但数据集操作只认一份固定的内置注册表。现在进程启动时可以 lance::index::register_scalar_index_plugin::<MyIndexDetails, MyIndexPlugin>() 注册一次，之后走既有的创建、段提交、重开与索引缓存路径。重名、与内置冲突、注册太晚都会报错，构造函数在锁外执行。约束也写清了：这是绑定到应用所链接 Lance 版本的 unstable Rust 接口；在稳定行 ID 数据集上，未知插件标识域在 compaction 或行重写之后会保守地失去覆盖，那些行退化为扫描直到索引重建。#10232 进一步允许外部维护的统计声明多个字段（例如按另一列分组的 distinct-count profile），依赖全部记进 IndexMetadata.fields，于是任一依赖被 drop 会连带删索引、改字段类型必须先显式 drop、改名则保留。
  • RaBitQ 扫描原语化（#9834、#9835、#9836、#9842、#9940）：这一组把原生多比特 RaBitQ（1 位 sign 加 num_bits - 1 位 ex 的布局）的 sign 阶段边界与候选打分暴露成可复用的扫描原语，常驻列在 open 时加载并在查询内共享，Session 可以装一个 RaBitQ 扫描工厂来选择 prewarm、fallback 与执行各自用的缓存项。#9940 明确声明「当前 head 不宣称性能提升」，只给出正确性对比：修复之前，k=8、refine_factor=3 的过采样 gather 两种情况只返回 8 个候选，修复后是 24。
  • CPU 特性铺路（#10099）：给 CpuFeatures 加 avx512vnni（位 22）、avx512vpopcntdq（位 23）、avx512vbmi（位 24）、avx512bf16（位 25），每个位带各自的 rustc 蕴含边、baseline cfg! 与运行时探测，供后续内核分派使用——这一条本身不搬任何内核。
  • 供应链：#10215 因 eMudhra CA 事件更新 trust-store 钉；LanceDB 侧 #4624 是同一件事。
  • LanceDB 同日（v0.41.0-beta.13）：#4607 给计算列与已注册 Function 输出加上 auto_refresh_enabled 与 auto_refresh_interval_seconds，Python 同步与异步 add_columns 都能传，省略间隔则由服务端决定刷新时机，关掉自动刷新仍可显式刷新；#4621 把物化视图的自动刷新创建选项也暴露出来；#4597 新增 Bootstrap 这一有放回抽样的分裂策略；#4627 保住已注册标量插件的类型名不被改写。前两条都标了 breaking。

行业影响

列式格式这一层的竞争正在从「支持哪些类型」转向「语义由谁定义、边界怎么声明」。Lance 这次把 NaN 在极值统计里的位置写进格式并给版本号，实质是把一个过去藏在实现里的判断变成跨客户端必须一致的契约——只要有一个客户端按旧口径读，剪枝结果就会静默出错，所以代价是 feature flag 级别的硬不兼容，而不是一次温和的行为变更。更值得注意的方向是索引的提供方被开放成插件：标量索引与统计不再只能是格式自带的那几种，外部系统（例如一个已有自己倒排或 skyline 结构的引擎）可以把自己的索引挂进 Lance 的段提交与缓存路径，代价是「未知插件在重写后失去覆盖」这种保守退化被明确接受。对做多模态检索栈的团队来说，这意味着 Lance 正在从「一个文件格式」往「一个可插拔的索引运行时」移动，而 RaBitQ 那一组 PR 的措辞（反复声明不宣称性能提升）也说明这条路还在工程化早期。

相关链接

Qdrant 1.20.0：把压缩精度做成数据类型，把默认值向安全一侧收紧

事件概述

10 月 22 日 14:14，Qdrant 发布 v1.20.0。这一版的主线有两条：一是把向量存储精度从「量化旁路」提升成一等公民的数据类型，二是在默认值层面做了一批收紧——既包括 HNSW 行为向论文回归的修正，也包括鉴权与路径校验这类安全默认值。改动覆盖特征、改进、缺陷修复与安全四组，其中安全组的三条都不是补丁级小修。

技术解析

  • TurboQuant 数据类型 turbo16 与 turbo8（Milestone #57）：每个向量先做一次数学旋转，把各维信息摊平，使压缩时不至于让个别维度损失过多细节，随后每个值用更少位存储。与量化的区别被文档特意点明——量化保留原向量并另加一份压缩副本，数据类型则直接用压缩形式替换原向量，不留全精度副本。文档页标注 turbo16 与 turbo8 自 v1.20.0 起可用，turbo4 自 v1.19.0 起已有。支持稠密向量与 multivector，不能用于配置稀疏向量。
  • 检索面的三项能力：#10750 让 BM25 打分直接作用在全文 payload 索引上；#11180、#11263 新增 code tokenizer；#11125 新增 per-element payload 索引，用新的 nested 参数加速对象数组的逐元素条件过滤。#10711 加了 match: { substring: "..." }（仅全扫），formula 表达式新增 acosh、max、min。
  • HNSW 的三处结构性修正：#11166 把层级分配改用 floor()，与 HNSW 论文一致——m = 16 时 level 1 上约 6.25% 的点，而不是此前的 25%，上层图随之更小；#11083 让 heal 复用旧图链接，并且 m = 0 的图也能 heal；#11009、#11020 把 payload links 的 builder 按 block 而不是 segment 分配并复用。
  • 存储与传输：Milestone #58 的 hnsw_config.inline_storage 让向量只存在 HNSW 图文件里、不再另存一份向量存储，直接降磁盘占用；#10906 对 on-disk 向量在打分前用 madvise(WILLNEED) 批量预取；#11253 把 transfer_raw_points 与 transfer_raw_payloads 默认打开；#11070 把快照流缓冲从 4 KiB 提到 4 MiB；#11206 保证快照名唯一且已存的快照不会被覆盖；#11221 给无响应的快照下载加 60 秒超时。
  • 默认值收紧：#10854 让配置了 API key 时 service.enforce_internal_auth 默认为 true，#10718 在分布式模式下配了 key 却未开启时给出启动告警；#11275、#11290 拒绝会逃出段目录的向量名（含 . 与 ..）；#11278 更新 rustls-webpki 与 webpki-root-certs，对应 RUSTSEC-2026-0382 与 RUSTSEC-2026-0383。
  • 可运维性补充：审计日志输出可配为 file（默认）、stdout 或 stderr（#10466）；collection 记录并在 info 中返回 created_at（#10992）；ID tracker 的内存放置可配（#10597、#10598）；#11273 给内部 p2p gRPC 开 HTTP/2 keepalive，修掉 NAT 与负载均衡后的内部请求停顿；#11255 改善小集群的分片分布；#10977 让整个优化任务跑在低线程优先级上。
  • 缺陷修复里值得记的两条：#11075 修 must_not 条件与某个已索引 must 条件一致时被忽略；#11101 修带微秒的 datetime 过滤在有无 payload 索引时行为不一致。

行业影响

把压缩精度做成数据类型而不是量化选项，改变的是成本模型：量化是「多一份副本换速度」，数据类型是「直接少一半存储、且不保留退路」。文档里那句「没有保留全精度副本」意味着这是一次单向选择——turbo16 把存储压到约一半，代价是没有原始向量可供重算或换量化方案，它适合嵌入模型本身输出精度有限的场景，不适合还要回头做精确重排或重新训练的库。HNSW 层级分配改回 floor() 这一条更值得注意：这是一个长期偏离论文、直到有人对照实现才发现的比例错误，修正后上层图规模降到约四分之一，对内存与构建时间的影响会直接体现在大规模集合上，也提醒任何自研 HNSW 的团队值得回头核对一遍自己的 level 赋值。最后，把内部鉴权默认改成强制、拒绝逃逸路径，说明向量数据库正在从「内网里跑的组件」被当作一个有真实攻击面的服务来对待。

相关链接

Databricks 把 AI 花费拆成归因、路由与护栏三层，路由层从模型扩到 harness

事件概述

10 月 22 日 19:14，Databricks 发布《The new economics of AI cost management》，形式是对 Unity Gateway 技术负责人、高级主任工程师 Kevin Stumpf 的访谈。文章给出的定性是：过去两年企业 AI 的主线是让人用起来，近几个月主题变成了算回报，AI 成本管理被定义成「跨模型、agent、应用与团队度量、归因、控制并优化 AI 支出」的一项实践，目标不是少用 token，而是让每花掉的一美元产出更多业务价值。

技术解析

  • 从 tokenmaxxing 到 valuemaxxing：文中回顾了早期公开排行榜按 token 消耗量排名的做法，指出激励结构被刷——跑一个空转的 agent 反复问天气就能上榜。现在要换的排行榜是「用 AI 产出的影响 ÷ 产出它的成本」，这个数比原始 token 数难量化得多，但才是真正要管的数。
  • 归因回答两个问题：钱从哪来、换到了什么。开箱可用的是按 user、group、agent、AI gateway endpoint、model、provider 与时间段归因；再往上一层是请求级 tag，可以挂任意组织关心的维度——某个 PR、某个 feature、某个外部客户——一旦每个请求都带 tag，就能按它聚合。文中举的内部做法是给正在处理的 PR 打 tag，成本仪表盘上就能看到这个 PR 花掉 300 美元。再往前一步（文中说正在做进产品）是把 PR 连到 feature、把 feature 连到某段时间产生的收入或管道。
  • 路由分两层：Smart Routing 在请求进来时实时评估任务复杂度，决定走前沿模型还是低成本模型，目标是同等质量下更便宜。文中给出的经验比例是只有约 5%–10% 的任务真的需要前沿模型，其余 90% 可以由自托管开源模型或主要实验室的便宜模型族解决；并指出在无人看成本的情况下员工会默认选最贵的模型。Harness routing 是模型路由之上的下一层：同一个模型换一个 harness 成本可以明显不同，因为 harness 决定模型如何与环境交互、何时压缩上下文窗口、什么业务逻辑约束其行为，这些都会直接影响 token 消耗；Databricks 用 Unity Gateway 与它的 meta-harness Omnigent 提供这一层。
  • 护栏的设计原则：人人都要有硬上限（举例：重度用户日常约 300 美元/天，硬上限设 500 美元，留出余量去接住「agent 忘了关在循环里」这类真实错误，又不会误伤正常的高用量日）；预算按团队或项目差异化；预算触发的动作不止硬停，还能告警或削减可用模型容量——例如某团队用掉 70% 预算后关闭默认的前沿模型访问，把余下请求路由到开源模型。四条通用原则被明确列出：防失控、按组或项目分层限额、先告警再限额、用智能降容量而不是 abrupt 切断。
  • 集中化是前提：好的支出可见性要求每一次 AI 交互都流经一个中心系统，网关提供这个控制点；文中强调光有中心系统不够，还要有办法强制所有人把流量导过去——可见性只在采用是普遍而非可选时才成立。
  • tracing 的定位：收集 agent 的完整尾气——在想什么、调了什么工具、拉了什么数据、prompt 好坏——用来挖滥用、浪费、安全泄漏或此前没想到的模式。文中把这个类比到数据行业：早期只有库里的干净结构化数据，之后数据湖一度变成数据沼泽，后来又能从中提取价值；agent trace 属于同一类资产。
  • 质量与成本的平衡点：需要反馈机制，主观的是有人抱怨预算内干不完活（快但易被当成个例），客观的是自动评测（难搭但可靠）。对编码 agent 这类常见场景，可以定义代理指标，比如「两周内没被回滚的已合并 PR」，然后把预算砍一半看这个指标是动、不动甚至变好——约束有时反而催生创造力。
  • 数字与边界：文中的 5%–10%、300/500 美元、70% 都是访谈里的经验值与 Databricks 内部做法，不是基准测试；「成本—回报」视图官方明确说还在建；agent fleet 那段是判断而非实测。

行业影响

这篇的价值不在于给了一个新功能，而在于把「AI 花费」摆到了与传统数据成本同一类治理对象的位置：可归因到人或 PR、可分层设限、可追溯、可回滚。它把优化杠杆从模型选择往上抬了一层——过去团队的决策是「用哪个模型」，现在多出「用哪个 harness」，而后者影响的是上下文压缩时机、工具调用策略与业务规则注入方式，这些恰恰是数据平台团队能直接改的东西。需要留意的是两处前提：一是所有流量必须走同一个网关，否则可见性是局部的、结论会偏；二是文中给出的比例与金额都是经验值，照搬容易失真，真正可复用的部分是它那套可操作的护栏结构（硬上限留出余量、预算分层、先告警后限额、用降容量代替硬切），而不是具体数字。对已经在上 Unity Catalog 的团队来说，这条线与 Vol.98 里记过的 dbt 成本归因是同一方向的两段：前者管数据管道的计算成本，这一段管 AI 调用的推理成本。

相关链接

Google Cloud 给 Knowledge Catalog 装自学习富化：业务上下文变成带置信度与变更请求的受治理资产

事件概述

10 月 22 日 16:00，Google Cloud 在数据分析博客发布 Knowledge Catalog 的两项 Preview：自学习上下文富化（self-learning context enrichment）与重新设计的 Knowledge Studio。Knowledge Catalog 被定位成 Google Cloud 面向 agent 的 context engine。这次升级的方向是把上下文的维护从「人工逐条写」改成「从交互里自动发现缺口并给出带来源的修改建议，再由人来批」。

技术解析

  • 自学习富化做什么：分析 agent 与用户的交互，定位缺失或过期的上下文，从 playbook、代码仓库与业务文档里抽取已验证的定义，汇成受治理、可复用的 context set。连接的结构化数据覆盖一方与三方来源，非结构化数据覆盖 Cloud Storage、Google Workspace、GitHub、Confluence 与 SharePoint。每次运行会检测源侧发生了什么变化、退役过时定义、并把冲突标出来待审。
  • 产出物与学习信号：按需或按计划产出业务定义、表与列描述、join 关系、golden queries 以及面向任务的 agent 指令，每条都带来源引用与一个置信度分数。学习侧可以配置成分析来自 Gemini agents、BigQuery Conversational Analytics 或自建 agent 的交互 trace（带 PII redaction），据此定位 agent 在哪里卡住——列查找有歧义、指标没有依据、定义缺失、或者用户反复换说法问同一个问题——然后找到权威答案并暂存一个修复，让同一个错误不再发生第二次。
  • 审批边界：自动发布可随时开关，可设定自动通过的置信度阈值（文中举例 85%）；低于阈值的改动，以及删除这类敏感更新，会变成 Change Request 交由 steward 批准、编辑或拒绝。可以自带评测集对建议的更新做端到端测试。每次变更都带完整 provenance 且可回滚。文中也声明 Google 不会用这些数据训练模型。
  • context set 与治理：context set 是上下文图中受治理的子集，含某个域、团队、agent 或终端用户群所需的定义、指标、join 逻辑与 golden queries——销售 agent 绑销售集合，财务分析助手绑财务集合，同一个「净收入」在不同域可以各自有定义。访问由 IAM 管：steward 决定谁能读、用、编辑，agent 只能取回它被授权的集合里的内容，底层数据权限继续沿用既有设置。context set 建立在 Open Knowledge Format（OKF）之上，可以导入一个 OKF bundle 变成 context set，也能导出回去，保持可移植。
  • Knowledge Studio：面向 context engineer 与 data steward 的交互入口，能做四件事——可视化地浏览跨云数据资产（从操作库、数仓到语义模型、context set 与文档）、用自然语言探索上下文图并看清 agent 如何基于元数据推理、在一个地方审查每条建议的 diff 与来源引用和置信度并用真实问题测试 context set 后批准或回滚、以及监控每次富化运行的调度、结果、token 用量与耗时并在完成时收到邮件。
  • 数字与边界：文中给出的内部基准是让 AI agent 准确率接近 4 倍、延迟最多降 33%、token 最多省 75%。三项都是内部基准口径，未给出数据集与对比基线。两项功能均为 Preview，官方说会在未来几周内向客户铺开，需要申请即时访问。

行业影响

这条与本期其余三条是同一个动作的不同切面：把「上下文」这种过去散落在文档、wiki 与资深员工脑子里的隐性资产，变成有来源引用、有置信度、有审批流、有 IAM 边界、还能按开放格式导出的对象。值得注意的是它把治理接口设计成了「阈值 + 变更请求」而不是「全自动」——低于阈值的改动与删除类操作强制走人审，这比一次性自动写入目录要稳，也承认了自动抽取必然有错。对数据平台团队来说，真正的看点有两个：一是 join 关系与 golden query 被纳入受治理资产，等于把「agent 会不会连错表」这件事从 prompt 工程挪回了数据治理；二是基于 OKF 的导入导出，意味着上下文层也开始出现可移植性主张，与湖仓里 Iceberg、Delta 的可移植性争夺是同一类博弈。需要打折的是那三个数字——4 倍准确率、33% 延迟、75% token 都出自内部基准且口径未公开，只能当作方向性信号。

相关链接

编者评

本期四条看似分属格式、向量库、平台治理与目录四个不同层面，指向的却是同一个工程动作：把一件过去由实现内部悄悄决定的事，提升成一份有版本号、有默认值、有审批边界的公开契约。Lance 把 NaN 在极值统计里的位置写进格式并配一个 feature flag，Qdrant 把向量精度提升成不保留退路的数据类型、把层级分配改回论文公式、把鉴权默认值改成强制，Databricks 把 AI 花费拆成可归因、可路由、可设护栏的三层并要求所有流量走同一个网关，Google Cloud 把业务上下文变成带置信度与变更请求、可按开放格式导出的资产。四处的代价都被写在了同一个量级上：格式不兼容、精度不可逆、可见性依赖全员接入、数字出自内部基准。一个可以照着做的判据是——看一件事是「换了默认值」还是「定了契约」：换默认值只影响升级那一次，定契约会持续约束实现，本期四条都属于后者。本期中文源（阿里云 blog 与开发者社区、火山引擎文档站与开发者社区）四个入口仍返回 HTTP 200 但无可确认日期的条目，已连续多期无法取到可核对的发布项，本期改以间接观察替代：Doris 停在 4.1.5、Paimon 停在 2.1.0、Hudi 停在 1.1.2、Amoro 停在 0.8.1-incubating、Kyuubi 停在 1.12.0、Linkis 停在 1.8.0、InLong 停在 2.4.0-RC0，窗口内均无新版本；英文侧确认无新的有：AWS Big Data Blog 最新仍为 10 月 19 日、Data Engineering Weekly 最新仍为 10 月 19 日、Flink 博客最新仍为 10 月 10 日、Dremio 最新仍为 10 月 12 日、Trino 仍停在 484、Iceberg 仍停在 1.12.0、Delta 仍停在 4.4.1、Daft 仍停在 0.7.26、dbt Core 仍停在 v1.12.6/v2.0.8 一线。