基于结构化表格发现的多样化模型检索 Diversed Model Discovery via Structured Table Discovery
用模型卡中的表格做结构化检索，让模型搜索兼顾任务对齐与多样性
前置知识
Model Lake（模型湖）
模型湖是对 HuggingFace、ModelScope 这类大规模模型仓库的统称，里面存放着成千上万个机器学习模型，每个模型配有一张 model card（模型卡）记录训练数据、评测结果和适用场景。本文使用的 ModelTables 语料就包含从 HuggingFace 抽取的 6 万多张模型卡。模型湖的核心难点是模型卡文本异构、写作风格不一致，且模型数量持续膨胀。
整篇论文的研究对象就是模型湖中的模型检索问题，理解模型卡的内容结构（文本 + 结构化表格混杂）才能明白为什么作者主张用表格而非全文做检索证据。
Semantic Search / 语义检索（dense、sparse、hybrid）
语义检索是把查询和文档都编码成向量再算相似度的检索方式。本文用到的三种变体：dense retrieval 用 Sentence-BERT 编码 + FAISS 向量索引做稠密检索；sparse retrieval 用 Pyserini 做基于词项的稀疏检索；hybrid retrieval 先扩大稀疏候选池再用稠密模型重排。它们共同构成本文的基线 Unstructured Semantic Search（NL2Card）。
本文要改进的就是这类纯文本语义检索方法，必须先理解它的工作方式和它'塌缩结果集'的缺陷，才能看懂作者为什么要引入表格检索。
Table Discovery Operators（unionability / joinability / keyword）
这是数据湖领域研究的三种表格发现算子，本文直接复用自 Blend 系统。Keyword search 按查询词在表头和首列出现在的频次排序候选表；Joinable search 找的是能通过某一列（如模型名、数据集名）与锚表做 join 的表；Unionable search 找的是列结构能对齐、内容可以 union 起来的表，对发现'不同模型的可比 benchmark 表'尤其有用。三者按可对齐的锚表列数排序。
这三种算子是 Structured Semantic Search 的核心检索引擎，论文的全部技术新颖性都建立在如何把这三种发现算子从通用数据湖迁移到模型卡的表格上。
Nugget-based Evaluation（基于信息点的评测）
Nugget 评测源自 TREC QA 和 RAG 评测：把文档/答案拆成一个个原子信息单元（nugget），用检索结果覆盖了多少个 query 相关的 nugget 来打分，而不是只看文档级相关性（如 nDCG、MAP）。本文把 nugget 定义成固定的 6 元组 $(model, base\ model, model\ variant, dataset, metric\ name, metric\ value)$，从模型卡抽取后用 prompt 把 query 映射成对 nugget 属性的约束 $\phi(q)$，再统计候选集去重后满足约束的 nugget 数量。
本文全部实验结果都用 nugget 数量来度量，理解 nugget 的定义和打分逻辑才能看懂 Figure 3 里的那些平均值（如 top-5 unionable avg=37.6 vs dense avg=15.0）到底在比什么。
Orientation-aware Table Integration（方向感知的表格集成）
模型卡里的表格经常被转置（一行是一个 benchmark、一列是一个模型，或反过来），直接集成会产生大量缺失值。Orientation-aware 集成在两两比较表头关键词在对方表头行和首列的重叠模式，若判定是转置关系就先转置再做集成。本文用 ALITE 系统做底座，再叠加这个方向识别补丁（Algorithm 2）。
这是论文四大贡献之一，也是把检索到的表格变成'用户能并排比较的可读视图'的关键步骤，理解它才能看懂 Figure 4、Figure 5 里那些集成表是怎么来的。
研究动机
现有模型搜索系统（HuggingFace、ModelScope、ModelDB、TensorFlow Hub、PyTorch Hub、DL-Hub）一律把模型卡当成非结构化文档来处理，主要靠关键词搜索、元数据过滤、分面搜索或对模型卡文本的语义检索。这些机制擅长找'单独相关的模型'，却几乎不支持构建'用于比较的候选模型集合'。具体表现为：纯语义相似度优化的是文本近似度，会把结果塌缩到主导模型家族周围（比如同一机构发布的一系列模型），加上共享的写作模板和汇报惯例，同一作者或同一模型家族的卡片叙事高度雷同，即便它们经验行为差异很大。与此同时，模型卡里的性能摘要、benchmark 结果、配置清单这些结构化表格才是高密度、决策相关的证据，且对写作风格的依赖更小，却几乎没有被检索系统利用。作者指出，模型搜索本质上是'比较性'的——用户想要的不是一个最相似的模型，而是一组在任务层对齐、又在可测量维度上彼此差异化的模型。
本文的目标是本文的目标是设计一套'结构感知'的模型检索框架 Structured Semantic Search（流程名 NL2Card2Tab2Card），在保留语义检索做任务对齐的同时，用模型卡里的结构化表格作为检索证据，从而让结果集既相关又多样化。配套目标包括：（1）定义一套基于 nugget 的可审计评测协议，能在模型湖持续扩张、固定标注很快失效的情况下稳定比较不同检索方法；（2）设计方向感知的表格集成策略，把检索到的部分重叠、可能被转置的表格拼成用户能并排比较的紧凑视图；（3）在 597 条改编自 LitSearch 的模型推荐查询上，验证结构化检索相比三种语义基线（dense/sparse/hybrid）能否在 nugget 覆盖上取得提升。
与已有工作不同的是，作者的独特切入角度是把'数据湖表格发现'（data discovery / table search / table integration）这套数据库社区成熟工具，第一次系统性地迁移到'模型检索'这个应用场景上。之前的工作要么在文本/元数据层面做模型检索（Achille 的 Task2Vec、内容检索、图学习选模型），要么在通用数据湖里做表格发现（Aurum、Blend、SANTOS、ALITE），两条线没汇合。本文的洞察是：模型卡里那些 leaderboard 式表格本身就是天然的高密度比较证据，把 unionability/joinability/keyword 三种算子用到这些表上，就能天然地召回'共享 benchmark 或共享 schema'的不同模型，从而把'多样性'从抽象目标变成可由表格结构直接驱动的检索行为。另一个独特点是把 nugget 评测（RAG 社区刚兴起的方向）首次应用到模型卡上，并用固定 6 元组 schema 让评测可复现、可增量计算。
核心方法
直觉上，作者认为好的模型搜索不该只看'文本像不像'，而该看'证据覆盖得广不广'——而模型卡里的表格正是浓缩、高质量、风格无关的证据来源。于是技术路线设计成一个 query-to-card-to-table-to-card 的两阶段流水线：先用语义检索（Unstructured Semantic Search）找一个任务对齐的锚点模型卡，再用锚点卡上的表格作为'查询表'，到模型表格湖里跑三种 Blend 表格发现算子（keyword / joinable / unionable）召回相关表，把每张召回表映射回一个最具语义相似度的模型卡，最后按语义相似度重排、在 top-$k$ 预算下截断。这样做的好处是把'表格发现'的效果隔离出来：锚点卡保证任务相关性，表格发现负责扩展候选集的多样性。配套的评测用 nugget 6 元组度量候选集覆盖了多少 query 相关证据，集成的表格视图则供用户人工比较。
核心创新点是'用表格做检索证据、用表格发现算子驱动多样性'。和已有方法的本质区别在于：（1）传统语义检索把整张模型卡文本当一个文档，本文把卡里的每张表当成独立、可比、可发现的检索单元；（2）unionability 算子天然召回'列结构对齐但内容来自不同模型'的表，这恰好就是用户想要的'同任务、不同模型家族'的对比候选；（3）作者提出 orientation-aware 集成，先识别转置关系再集成，解决了模型卡表格横竖方向不一致导致 ALITE 直接集成会产大量缺失值的问题（Algorithm 2：当重叠矩阵 $M$ 满足 $M[0,1]>0$ 且 $M[0,0]=0$ 且 $M[1,1]=0$ 时判定为转置）。此外，nugget 定义为固定 6 元组 $(model, base\ model, model\ variant, dataset, metric\ name, metric\ value)$，让评测在 schema 上一致、可增量计算（新卡只需在摄入时跑一次抽取），这是与开放式自由文本标注相比的关键工程优势。
方法步骤详情
完整流程见 Algorithm 1（NL2Card2Tab2Card）：输入是查询 $q$、模型卡语料 $C$、表格湖 $L$ 和 top-$k$ 预算。第 1 步 $A \leftarrow \text{UnstructuredSemanticSearch}(q, C)$ 拿到锚点候选卡；第 2-4 步收集所有锚点卡关联的表作为种子 $T_{seed}$；第 5-8 步对每张种子表 $Q$ 调用 Blend 的发现算子 $T_{cand} \leftarrow \text{Discovery}(Q, L)$，把候选表并入 $T_{ret}$；第 9-13 步对每张召回表用 MapTableToCards 找到关联卡集合 $C_T$，再用语义相似度重排选出唯一代表卡 $m^*$（保证一张表只贡献一张卡，避免同一证据被多张卡膨胀候选集）；第 14-16 步把所有代表卡按语义相似度做最终重排 FinalRerank 并截断到 top-$k$。评测侧（nugget pipeline）有两阶段：阶段一在摄入时对每张卡跑 prompt 抽取器，把全文（含表格、tag、benchmark 摘要、评测小节）标准化成 nugget 6 元组，存成带第 7 列（卡 ID）的表；阶段二用 prompt 把查询 $q$ 映射成约束 $\phi(q)$（指明相关属性及取值约束），对 nugget 表做语义过滤（不做字面精确匹配以容纳模糊查询），统计候选集 $R_q = \{m_1, \ldots, m_k\}$ 去重后满足 $\phi(q)$ 的 nugget 个数，即 $\text{Score}(R_q, q)$。
技术新颖性
技术新颖性体现在三处交叉创新。第一，把数据库社区的表格发现算子（unionable/joinable/keyword）首次适配到模型卡表格场景：本文注意到模型表里表头和首列承载语义标签和标识符（benchmark 名、模型名、数据集名），内部单元格多为数值，因此 keyword 查询专门针对表头+首列构造，joinable 查询用首列作 query 列，unionable 按可对齐的锚表列数排序——这些适配反映了模型表的领域特性。第二，orientation-aware 集成是一个具体、可操作的技术贡献，直接修补了 ALITE 不能处理转置表格的缺陷，让模型家族内部版本差异（Figure 5 中 granite-vision-3.2-2b 与 3.1-2b-preview 的对比）能被并排展示。第三，nugget 评测首次以固定 6 元组 schema 应用到模型卡，明确声明评测只针对'从候选集抽取出的 nugget'而非全卡处理，并支持模型湖动态扩张下的近似、可审计标注——这套协议本身可扩展为未来模型搜索 benchmark 的 ground-truth 来源。
实验结果
核心结论是：在所有 top-$k$ 预算下，结构化检索家族的 nugget 覆盖都显著高于语义基线，且 unionable 是最强的结构化算子。Figure 3 的数据非常清晰——top-1 时 unionable 平均召回 9.4 个 nugget，对比 dense 仅 2.5、sparse 4.0、hybrid 3.4，结构化优势接近 3-4 倍；top-3 时 unionable 升到 28.8 vs dense 8.4 / sparse 11.9 / hybrid 10.5；top-5 时 37.6 vs 15.0 / 19.8 / 17.9；只有到 top-10 时差距才缩小（unionable 45.5 vs sparse 39.6 / hybrid 39.8 / dense 34.7），说明检索深度是影响准确率的关键因素——给足预算，语义检索能追平一部分，但小预算下结构化优势压倒性。底部的 query-level rank 分析显示，unionable 在 top-1/top-3/top-5 的 rank-1 占比最高（top-1 时 16% rank-1，且整体分布偏向高位），joinable 更挑剔故命中率低，keyword 依赖词汇重叠最脆弱；但到 top-10 时 sparse 和 hybrid 反超，因为此时足够深的词项重叠能抓住强任务对齐。两个定性案例进一步佐证：Figure 4 的边端图像分类查询里，dense 检索返回 timm/edgenext 等同家族模型，而 unionable 召回 qualcomm 的 MobileNet-V3、QuickSRNet、Midas-V2 等量化模型，并集成了含 device/chipset/runtime/latency/memory/precision/compute 等列的 159 行×9 列比较表；Figure 5 的 OCR 查询里，dense 顶部的 robertknight/ocrs 等卡片完全没有可用表，而 unionable 召回 granite-vision 3.2-2b 和 3.1-2b-preview 两张 schema 几乎一致的 benchmark 表，集成后支持跨模型家族和家族内版本的双重比较。作者还观察到一个查询可能匹配上百个 nugget（如 fblgit/juanako-7b-v1 在几十个 benchmark 上报告性能，单卡就产出 134 个匹配 nugget），凸显 set-level 度量的必要性。此外 Figure 2 的意图分布显示 evidence-based 查询占绝对主导，这也是作者承认的局限——其他意图类型的检索表现未被充分研究。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 模型卡候选集 nugget 覆盖（top-1） | 平均满足 query 的去重 nugget 数 | Unionable 9.4 / Joinable 8.8 / Keyword 8.7 | Dense 2.5 / Sparse 4.0 / Hybrid 3.4 | Unionable 相比最强基线 Sparse 提升 2.35×（9.4 vs 4.0） |
| 模型卡候选集 nugget 覆盖（top-3） | 平均满足 query 的去重 nugget 数 | Unionable 28.8 / Keyword 25.6 / Joinable 24.0 | Sparse 11.9 / Hybrid 10.5 / Dense 8.4 | Unionable 相比 Sparse 提升 2.42×（28.8 vs 11.9） |
| 模型卡候选集 nugget 覆盖（top-5） | 平均满足 query 的去重 nugget 数 | Unionable 37.6 / Keyword 31.1 / Joinable 29.1 | Sparse 19.8 / Hybrid 17.9 / Dense 15.0 | Unionable 相比 Sparse 提升 1.90×（37.6 vs 19.8） |
| 模型卡候选集 nugget 覆盖（top-10） | 平均满足 query 的去重 nugget 数 | Unionable 45.5 / Keyword 37.9 / Joinable 34.1 | Hybrid 39.8 / Sparse 39.6 / Dense 34.7 | Unionable 仍领先，但基线差距大幅收窄（45.5 vs 39.8） |
| Query-level rank-1 占比（top-1） | 方法在单查询比较中排第一的频率 | Keyword 31% / Joinable 20% / Unionable 16% | Sparse 21% / Hybrid 13% / Dense 8% | Keyword 在 top-1 rank-1 上领先，但平均 nugget 数仍低于 unionable，说明'常赢'与'平均广'是两个维度 |
局限与改进
作者自己承认的局限有四点：（1）集成阶段用的 ALITE 不能很好处理转置或更一般的 schema 异构（一个表的数据在另一个表里被用作表头），虽然加了 orientation-aware 补丁但只是启发式，模型湖里这类异构很常见；（2）很多模型卡仍不完整或完全没有表格支撑，未来需要推断或补全缺失结构；（3）查询集中 evidence-based 意图压倒性多数（Figure 2），comparison/experience/reason/instruction/debate 等意图下结构化检索的相对优势未被验证；（4）nugget 目前只用于比较不同检索策略，尚未作为 ground-truth 来报告 precision/recall。我自己观察到的额外局限：nugget 的抽取和 query-to-nugget 映射高度依赖 prompt 工程和大模型，论文未报告这些 prompt 在不同 LLM 上的稳定性、也未报告抽取的准确率/召回率本身；评测完全基于 ModelTables 这一单一语料（6 万 HuggingFace 模型），未在 ModelScope、ModelDB 等其他模型湖验证泛化；query 是从 LitSearch 'paper-recommendation' 改写而来（把 paper/studies 换成 model/method），这种最小词汇改写能否真实反映用户的模型搜索意图存疑；此外 unionable 在 top-10 优势明显收窄，说明在'用户愿意看更多结果'的场景里，结构化方法的边际收益会被语义检索稀释，论文未给出何时该选哪种方法的决策建议。
独立分析的弱点
第一个弱点是表格抽取和 nugget 抽取的鲁棒性。整条流水线两端都依赖 LLM prompt（抽表、抽 nugget、做 query-to-nugget 映射），但论文既没报告这些 prompt 在不同模型（GPT-4 vs 开源模型）下的稳定性，也没报告 nugget 抽取本身的精度——如果抽取漏掉了某张卡的真实 benchmark 行，下游所有 nugget 计数都会系统性偏低且无从察觉。改进方向：给 nugget 抽取引入抽样人工校验，报告抽取的 P/R，并设计'抽不出的卡片'的兜底回退到全文检索。第二个弱点是评测的'自评价'风险：nugget schema 和 query-to-nugget 映射都是作者自己定义的，有可能恰好有利于表格检索——比如固定 6 元组天然对应表格单元格，全文卡里的叙述性证据（如'this model excels at low-resource translation'这类无数字的能力陈述）会被系统性忽略，从而低估语义基线。改进方向：引入人类标注的 query-卡 相关性做交叉验证，或扩展 nugget schema 容纳叙述性能力。第三个弱点是查询集的生态单一：597 条全是 LitSearch 改写的 evidence-based 风格，缺少真实的 HuggingFace 用户查询日志，结论在'我要部署到手机上'这类部署约束查询（Figure 4 那种）上的外推缺乏统计支撑。改进方向：和 HuggingFace 合作拿到脱敏真实查询，或构造覆盖六类意图的平衡查询集。第四个弱点是 ALITE 集成对小表的偏好（论文预处理时砍掉了 >200 行或 >100 列的大表），那些真正大的 leaderboard 表（几十个模型 × 几十个 benchmark）恰恰是高价值比较对象却被排除，改进方向是支持流式/分块集成大表。
未来方向
作者明确提出的未来方向有四条：（1）研究如何更好地集成 schema 异构、互为转置的模型卡表格，超越 ALITE 和当前 orientation-aware 补丁的能力；（2）为不完整或非表格支撑的模型卡推断或补全结构，提升检索和集成覆盖率；（3）研究不同查询意图负载（非 evidence-based 占主导时）下搜索表现的权衡变化；（4）把 nugget 从比较工具升级为 ground-truth 来源，从而报告真正的 precision/recall，构建一个稳定的模型搜索 benchmark。基于本文成果可延伸的方向我自己补充：可以把 unionable/joinable/keyword 的离散选择换成一个学习型的路由器，根据 query 特征自适应挑选算子或加权融合，可能在小预算下进一步拉开优势；nugget 6 元组可以扩展为带时间戳和版本号的 7+ 元组以支持模型版本演化的时序比较；表格发现还可与 RAG 结合，把集成表作为 LLM 的结构化上下文做'table QA'，论文 Figure 5 已暗示这条路径；最后整个框架可推广到 ModelScope、ModelDB 等其他模型湖做跨湖一致性检索。
复现评估
复现友好度较高。作者明确声明所有代码、prompt、数据和输出都开源在 https://github.com/RJMillerLab/ModelSearch。底座组件都是公开的：ModelTables 语料（arXiv:2512.16106）公开、Blend 表格发现系统公开、ALITE 集成系统公开、Sentence-BERT+FAISS（dense）、Pyserini（sparse）都是标准库、LitSearch 查询集公开。查询改写和 nugget 抽取的 prompt 也都开源。算力方面，6 万模型卡的向量化 + 表格发现索引构建需要一定资源但属于单机可承受规模（没有训练新模型，只做检索和推理），评测阶段主要是 prompt 调用成本。难度主要在于：（1）需要正确复现 ModelTables 的表格抽取管线；（2）Blend 和 ALITE 的环境搭建有一定工程门槛；（3）prompt 抽取的稳定性依赖具体使用的 LLM，论文未锁定具体模型版本，跨 LLM 复现数值可能漂移。整体看，这是一个工程量大但路径清晰、可复现的研究，适合作为后续工作的基线。
论文图表
用伪代码给出主检索流程的 16 步：从 UnstructuredSemanticSearch 拿锚点卡 $A$，收集种子表 $T_{seed}$，对每张种子表跑 Discovery 召回候选表 $T_{ret}$，对每张召回表映射到唯一代表卡 $m^*$（按语义相似度重排），最后 FinalRerank 并 Truncate 到 top-$k$。
它是方法章节的形式化定义，把 Figure 1 的 Pipeline 2 落到可执行步骤，尤其第 11-13 步'一张表只贡献一张卡'的去重逻辑是保证多样性的关键，读懂它才能理解为什么 Structured Semantic Search 的候选集比语义基线更去冗余。
8 行伪代码给出方向感知集成：以查询表 $Q$ 为初始 $I$，对每张检索表 $T$ 算重叠矩阵 $M$，当 $M[0,1]>0$ 且 $M[0,0]=0$ 且 $M[1,1]=0$ 时判定为转置并对 $T$ 做 Transpose 再 Integrate。
它是论文四大贡献之一'orientation-aware integration'的精确表述，解释了为什么模型卡表格在集成前需要先识别横竖方向，是 Figure 4/5 集成表能正常拼出来的技术前提。