“同一本书”在图书馆检索系统里经常是散的。假设读者想找《红楼梦》的英译本他在发现系统里看到人民文学出版社校注本、岳麓书社简体本、某英文全译本、某个注释本被当作一组“相似记录”返回却没有被归并成一个作品整体。这里缺的不是关键词匹配而是编目层面一个被称为 Superwork 的作品聚合层。过去十几年图书馆界解决这个问题主要靠规则引擎抽取题名、责任者、ISBN算相似度再用人工审核兜底。为什么至今没有彻底解决因为书目记录是人写的题名可以有原名、并列题名、封面题名、丛编名作者可以有汉名、罗马拼音、笔名甚至同一部作品的不同译本会出现在不同书目数据库里。规则写得再细也会在边界条件上失控。大语言模型LLM带来了一个真正值得重新评估的机会它可以用自然语言理解两条书目记录的语义关系判断它们是否属于同一个“超作品”。但如果直接把 LLM 扔进全库做两两配对成本高、误报大、不可控。所以本文想表达一个明确判断在实际项目中应采用“规则硬过滤 向量召回 本地 LLM 裁决 传递闭包合并”的混合管线把 LLM 真正用在对的位置上并坚持本地部署以保护书目数据。读完这篇文章你会理解 Superwork 聚类的业务逻辑掌握用 Ollama 运行本地模型的方法并能实现一个可运行的最小书目聚类脚本知道如何评估聚类质量也能避开我在工程化中看到的典型坑。1. 为什么要构建 Bibliographic Superwork Clusters图书馆发现系统Discovery System承担着面向读者的统一检索入口。无论是 Primo、Sumo 还是开源 Blacklight其底层都依赖书目元数据。但多数图书馆目录的原始记录是分库建立、按批导入的同一种作品的不同版本会反复出现出版社不同、ISBN 不同、编目员著录习惯不同。结果是读者查“红楼梦”会拿到一堆孤立的 record而不是一个可浏览的作品树。行业里的概念是 Work 聚合。传统 FRBRFunctional Requirements for Bibliographic Records模型把书目实体分为 Work、Expression、Manifestation、Item 四层。简单说层级含义例子Work抽象的知识创作《红楼梦》这部小说Expression某种文字/版本形式曹雪芹原文、杨宪益英译本Manifestation某次出版发行的物理体现人民文学出版社 1996 年平装本Item图书馆里的单本复本某馆藏的某一本Superwork 是在 Work 之上再往上聚合的一层解决更广的“知识作品家族”问题。它不仅能把同一著作的不同语言版本放在一起还能把某一作品的各种校注本、增订本、图文改编本按主题血缘关系聚成大簇。为什么需要做 Superwork Clusters主要有三个业务点用户浏览体验。读者进入发现系统后应该能看到“相关版本”聚合而不是反复看到几乎一样的条目。馆藏分析与去重。图书馆在评估电子书与纸质书重复采购时需要知道全馆到底有多少个“作品实体”而不是多少条 MARC 记录。数字人文研究。研究者做计量分析时希望把同一作品的不同版本作为一个稳定的分析单位。传统规则聚类无法完整覆盖这个问题但本地大语言模型的语义理解能力正好补上了“人工规则写不清楚”的那一段。2. Superwork 聚类中的核心难点先看一个典型例子。假设有这几条书目记录《Designing Semantic Search Systems》by Zhang Yuanqing, translated by Li Min《语义搜索系统设计第二版》by 张远清《语义搜索系统设计》by 张远清这显然是同一部作品在不同语言、不同版次下的呈现。但纯字符串匹配会失败因为题名不同作者姓名写法也不同。更麻烦的是同一作者写了多本相似主题的书应该被拆开。同一作品的不同译本责任者字段经常是译者原著者信息放在其他字段。版本说明如“第2版”“修订本”不应成为拆分的理由。装帧、出版社、载体形态差异也不应阻碍合并。传统规则的做法往往是“作者姓氏相同 题名相似度大于阈值”。这种设计有两个系统性缺陷规则太强则漏召回recall 低。比如英译本的题名与中文原题名没有共同 token很难靠字符串相似命中。规则太弱则误合并precision 低。如果同一作者写了两本书题名都带“语义搜索”规则就可能把它们错误地塞进同一个簇。这两个缺陷正好是大模型擅长的地方。LLM 能理解“这是原著的中文版本那是英译本”也能判断“虽然题名很接近但一本是张三写的《神经网络》另一本是张三写的《深度学习》不是同一作品”。不过要注意LLM 并不是万能的。它对 ISBN 这种长串数字不敏感在某些情况下会把顺序搞错如果数据量达到数百万条直接让 LLM 做两两比对是不可行的。所以在真实系统里要让 LLM 做“判断”而不是让它做“搜索”。3. 为什么必须用本地 LLM在做这个方案时一个常见疑问是为什么不直接调用云端的通用大模型 API真正处理图书馆书目数据时需要警惕几点。第一书目元数据不一定全部“公开”。许多图书馆的商业采购数据、试用资源清单、未出版的特藏编目数据都有协议约束不能随便发送给外部服务。第二有些数据里混有读者行为或馆藏流通信息虽然本文强调只处理纯书目字段但在真实环境里元数据管线经常会和用户数据出现在同一数据库。第三如果把海量记录反复发送到外部 API成本不可控而书目数据本身就包含大量重复比较请求。本地 LLM 在这些场景下的价值很明显维度公有云 API本地 LLM数据出域纪录会离开你所在网络数据不出本地服务单次请求成本按 token 计费算力自持批量成本可预测调参与测试受制于服务方限流可反复调整 prompt 和参数离线可用依赖外部服务状态可离线执行部署门槛接入简单需要 GPU 或较好 CPU本地模型也有缺点模型能力总体弱于当前顶尖商业 API必须用更严格的结构化 prompt 和召回策略来弥补如果只有 CPU推理速度会明显偏低。但从批量处理书目记录的角度看本地部署的“可控性”比“跑分”更重要。推荐考虑以下开源模型组合Embedding 模型bge-m3。多语言能力强适合中文书目与英文书目混合的馆藏数据。判断模型qwen2.5:7b-instruct或更小的qwen2.5:3b-instruct。7B 在精度上更稳定3B 的推理速度更快可先小规模实验后再选定。如果本地环境没有足够资源可以先拿一个小规模抽样集验证效果不要一上来就处理全库。4. 方案架构把 LLM 放在管线正确的位置不要尝试“把所有记录两两丢给 LLM 判断”。全库 100 万条记录的理论两两对数是 4999.5 亿对即使每秒处理 10 对也需要超过一万年。正确路线是构建一个候选集召回的管线。整体流程如下数据抽取与规整化。从 MARC 或数据库里读取书目字段统一为 JSON做全半角转换、大小写折叠、去除多余标点。规则硬过滤Hard Filter。用 ISBN 归一匹配、作者归一匹配、题名精确匹配等低成本规则先找出高置信候选对。向量召回Embedding Recall。对每条记录生成题名和作者的向量表示用 cosine 相似度召回每个记录最相似的 TopK。LLM 语义裁决。对候选对做两两判断输出是否属于同一个 Superwork。传递闭包合并。把“匹配为真”的关系用 Union-Find 合并成一个个不相交的簇。人工抽检评估。每年抽取部分簇进行人工复核用于校准 prompt 和决定是否调整召回阈值。这里最容易被忽视的是步骤 4 和 5 的连接。很多人会让 LLM 对大量 pair 输出 0~1 分数再用固定阈值切。这样做问题很大不同模型对分数的校准能力不同同一个模型在不同 prompt 下的分布也完全不同。更稳妥的做法是让 LLM 先输出一个有依据的match: true/false再结合置信度做分层分析而不是只依赖一个分数。为什么不能直接对全库做 embedding 全两两矩阵因为向量矩阵的尺寸是 N x D两两相似度矩阵是 N x N。100 万条记录的 N x N float 矩阵需要大约 4 TB 内存。所以真实场景建议用 faiss、Elasticsearch kNN 或专用向量库做 TopK 召回而不是造全量矩阵。本文的示例代码为了便于复现会采用小数据量下的 NumPy 简化实现并给出可替换的工程建议。5. 环境准备与前置条件本文示例代码使用 Python 3.10并依赖 requests、numpy。模型运行使用 Ollama它把 llama.cpp、transformers 等底层细节封装成简单 HTTP 接口很适合做本地原型。第一步安装并启动 Ollama。# Linux / macOS curl -fsSL https://ollama.com/install.sh | sh # Windows 可直接下载安装包然后打开 Ollama 应用 ollama serveOllama 默认监听127.0.0.1:11434不要直接暴露到公网。如果能确认 Ollama 在运行可以执行ollama list如果列表是空的先拉取所需模型ollama pull bge-m3 ollama pull qwen2.5:7b-instruct这里bge-m3负责生成向量qwen2.5:7b-instruct负责语义判断。实际拉取时请以 Ollama 官方模型库的标签为准如果本地网络或模型服务受限也可以选择其他多语言指令模型。Python 依赖安装pip install requests numpy然后准备一个演示用书目数据集data/demo_bib.json。为了避免把虚构记录误认为真实出版信息下面的演示数据是完全虚构的图书条目仅用于展示聚类逻辑。实际项目里请替换成自己经过授权和脱敏处理的真实数据。[ { id: demo_bib_001, title: 语义搜索系统设计, author: 张远清, translator: , language: chi, publisher: 示例学术出版社, year: 2019, isbn: [ISBN-DEMO-001], series: 信息检索前沿丛书 }, { id: demo_bib_002, title: 语义搜索系统设计第二版, author: 张远清, translator: , language: chi, publisher: 示例学术出版社, year: 2022, isbn: [ISBN-DEMO-002], series: 信息检索前沿丛书 }, { id: demo_bib_003, title: Designing Semantic Search Systems, author: Zhang Yuanqing, translator: Li Min, language: eng, publisher: Demo Academic Press, year: 2020, isbn: [ISBN-DEMO-003], series: }, { id: demo_bib_004, title: Knowledge Graphs for Semantic Search, author: Mei Lan, translator: , language: eng, publisher: Example Tech Press, year: 2021, isbn: [ISBN-DEMO-004], series: }, { id: demo_bib_005, title: 面向语义搜索的知识图谱理论、方法与工具, author: 梅兰, translator: , language: chi, publisher: 示例技术出版社, year: 2021, isbn: [ISBN-DEMO-005], series: }, { id: demo_bib_006, title: 语义搜索中的注意力机制Transformer 实践导引, author: 王路, translator: , language: chi, publisher: 另一家出版社, year: 2023, isbn: [ISBN-DEMO-006], series: } ]在这个演示集里我们希望脚本能够识别出Cluster Ademo_bib_001、demo_bib_002、demo_bib_003属于同一个 Superwork因为后者是前者的英译或另一版本。Cluster Bdemo_bib_004与demo_bib_005属于同一个 Superwork是同一作者同一种书的不同语言版本。demo_bib_006虽然题名含有“语义搜索”但作者、内容对象都不同不应并入其他人任何簇。6. 完整示例代码实现下面给出一个完整的 Python 脚本cluster_superwork.py。整个文件可以直接保存运行。# -*- coding: utf-8 -*- Bibliographic Superwork Clustering with Local LLMs 最小可运行
