摘要

  • CiteSeer演示数据库约两成查询带作者首字母；面对常见姓氏，这个小线索很有用。
  • 1999年论文报告，带首字母查询的测试平均耗时，经缓存和位置查找优化从1.91秒降到0.26秒。

网页上的论文越堆越多，找人却可能卡在一个字母上。CiteSeer的读者输入m jordan，有时还会添一个i。姓氏太常见，名字又被参考文献缩写了，读者只能拿这些零件拼出搜索条件。搜索引擎倒先嫌零件费事。

Steve Lawrence、Kurt Bollacker和C. Lee Giles在1999年的项目论文里记录了这件小麻烦。含作者首字母的查询经常要花好几秒。对一台整理科学文献的机器来说，连一个字母都招待不起，多少有点失礼。

文献缩写了名字，索引得把它留下

搜索索引常会省略过于常见的词。CiteSeer选择保留，包括那些短得几乎看不出信息量的字母。理由藏在参考文献里：作者的名字常被压缩为首字母，姓氏前那一点点内容，正是读者缩小范围的抓手。短语检索和邻近检索还能要求字母与姓氏靠在一起，免得它们只是在同一篇长论文里各忙各的。

这套工具本来就在替学术写作收拾各种格式。1998年的论文介绍了从网上论文提取参考文献、将同一篇作品的不同引用写法归到一起，再沿引用关系连接文章的做法。原来印在文末、需要读者自己追踪的一串书目，开始可以在网上一路点下去。

文献进门时也没那么整齐。1999年6月的Computer论文描述了PostScript、PDF转成文本后，怎样寻找参考文献区，再靠编号、行距或缩进切分条目。有些PostScript文件页序倒着来，还得先翻正。数字图书馆的浪漫，落到机器上常常是整理一堆皱巴巴的书单。

作者首字母则把另一笔账送上门。一个字母会出现在大量引用里，机器要核对它与姓氏的位置关系，就可能沿着很长的记录表找下去。演示数据库约20%的查询带有作者首字母。这样的读者再被叫作边缘情况，边缘未免太宽了。

让字母拥有自己的抽屉

论文的测试数据库约有20万份文档，包含超过250万条引用。作者随机挑出两组查询，各25条：一组不带首字母，一组带。表里的平均耗时分别为0.28秒和1.91秒，正文将差距概括为约七倍。

CiteSeer把词语在文档中的位置列表缓存起来，并为每个首字母建立按文档标识查找的表。机器锁定某份候选文档后，可以直接取出那个字母在这份文档里的位置。邻近比较通常就不用再把整张文档列表翻一遍。字母没有被扫地出门，只是终于分到了合适的抽屉。

改完之后，带首字母那组的平均耗时降到了0.26秒，比另一组还略快。这张表记录的是当年那50条测试查询。它最耐读的地方，是把“为什么快了”也讲清楚：减少了找位置的绕路，读者提交的线索还在。

找到结果后，CiteSeer也留了查账的入口。Context展示引用所在的上下文，Check展示被归为同一篇论文的各条引用原文。读者既能看别人怎样使用这篇论文，也能检查机器为什么把若干条书目放在一起。一个字母帮人缩小范围，引用原文则让人有机会纠正目录的判断。