找数据,不是查数据 — 信息需求、偶得与「真相的感觉」
这一章讲三件事: 「找」与「查」为什么是两门手艺、各用什么语言; 图书馆员的一门老手艺(信息需求)怎么决定你的搜法;以及两个新词—— 偶得与提示主义——为什么在 AI 时代突然变得要紧。 组织篇到此收官:从这里起,全书转入「怎么搜」。
1. 先看现象:两个长得几乎一样的问题
- 问题一:「上周六晚上,多少人看了我们的网站?」——这是一个有答案的数:1340 人。
- 问题二:「哪里有关于网站流量的数据?」——答案不是数,是一个位置:哪张表、在哪个系统、谁负责。
两个问题都叫「搜索」,但它们是两种劳动。书里把第一种叫在数据里搜(searching in data), 第二种叫为数据而搜(searching for data),并且把它定为「与目录打交道时唯一必须想明白的事」1。 更扎心的是顺序问题:数据发现始于发现「有这么一份数据」,而不是它内容是什么2—— 找不到源,再好的分析手艺都无处施展。
日常里「为数据而搜」的真实形态往往很难看:找人打听、翻聊天记录、靠脑子里的印象碰运气。 书里管这叫顺手的、不成体系的搜法,与之相对的才是结构化的、在专门工具(目录)里进行的搜法3。
2. 主走查:两个问题,两条完整的路
把两个问题各走到底,看得更清楚。
问题一的路(在数据里查):
「上周六晚多少人看了网站?」
↓ 翻译成查询语句(SQL——结构化查询语言,对数据库发问的通用语言)
↓ 在数据库管理系统里执行
1340(答案是一个值,劳动结束)
这条路用的语言叫 DQL(数据库查询语言):你能组合出极复杂的语句、对海量数据做精细计算—— 数据科学这门行当,就是从「在数据里搜」里长出来的4。
问题二的路(为数据而找):
「哪里有关于网站流量的数据?」
↓ 信息需求:「几个好东西」(不是全部,也不是唯一)
↓ 第一次尝试:「网站」→ 命中太多,多数与流量无关(查全率高、查准率低)
↓ 收窄:「网站 流量 分析」→ 命中变少,开始有对的东西
↓ 借助词表:挂过「流量分析」术语的资产浮上来
答案是一个位置:某张访问日志表 · 在数据平台 · 负责人王明
↓ (从这里开始,才轮到问题一那条路:进数据里查)
第二步以后的具体搜索式是我们为演示编的,不是原书例句;但「搜了改、改了搜的多步长过程」 是书里的原话主张,第 4 节展开5。
两条路的差别可以压成一张表:
| 在数据里查 | 为数据而找 | |
|---|---|---|
| 你要的答案 | 一个值 | 一个位置 |
| 用的语言 | DQL(如 SQL) | IRQL(信息检索查询语言) |
| 作用的对象 | 源数据库(装着数据) | 参考数据库(装着数据的描述) |
| 谁研究透了它 | 计算机科学、数据科学 | 图书馆与信息科学 |
3. 两套语言与四种参考数据库
数据管理文献的一个尴尬
「在数据里查」的语言汗牛充栋;「为数据而找」呢?书里做了一次挖苦式核查: 数据管理的权威手册 DAMA-DMBOK 里,关于「数据目录怎么支持搜索」 全书只有一句话——「元数据库必须有支持检索功能的前端应用」6。 一句话,没有功能,没有技术。这就是本书要用一整章(乃至第三章全书)补空白的原因。
信息科学早就把答案备好了
图书馆与信息科学(LIS)研究「怎么找到资料」有几百年。它给出一对书里的关键概念7:
- 源数据库:装数据本身——查它,答案直接到手,不必去别处;
- 参考数据库:装数据的描述,它的任务是把你领到源——书里引信息检索教科书的话: 「参考数据库引领用户到信息源;源数据库无需用户另找别处即给出答案」8。
LIS 传统上有三种参考数据库:书目数据库(某主题有哪些书)、馆藏数据库(图书馆收藏了哪些书)、 引荐数据库(某主题有哪些人、公司、技术)9