PDF搜索被视为不可或缺的一部分
标签、分类和导航的结合可以帮助最终用户利用企业搜索的强大功能。
瑞安·巴罗斯和吉姆·特拉维索，摩根士丹利
大多数公司必须利用其数据来获得竞争优势。知识工作者可用的数据量在过去几年中显著增长，虽然其中很大一部分存在于大型数据库中，但重要的子集仅以非结构化或半结构化数据的形式存在。如果没有合适的系统，这将导致信噪比持续恶化，为试图快速定位信息的繁忙用户制造障碍。以下三种类型的企业搜索解决方案有助于改进知识发现：
原始引擎。 这些是工具包，开发人员可以使用它们将高性能搜索嵌入到他们的应用程序中。一个流行的即将到来的实现是 Lucene，这是一个开源的 Apache 项目，提供 Java、.NET、Python、C++ 和其他语言版本。您需要自己实现爬取、解析和用户界面；但是，引擎处理布尔逻辑、模糊查询、词干提取和命中突出显示。商业产品，如 Verity（被 Autonomy 收购）、Fast 或 Coveo，提供与 Lucene 相同的核心功能，但可能会增加实体提取器、同义词库、自动分类和许多其他领先功能。
内网设备。 这些是低定制化的盒子，您只需将其插入到您的网络中，指向数据源，然后让其建立索引。用户界面、爬取和索引可以进行调整；但是，功能很少可以添加或更改。根据供应商使用的排名算法，每个实现提供的结果相关性差异很大。谷歌和 Thunderstone 都提供企业搜索设备，并获得了积极的评价。
桌面搜索。 大量的个人搜索引擎可用于索引电子邮件、本地文件、即时消息历史记录、Web 历史记录、联系人和更多内容。这些引擎在家庭计算机市场非常受欢迎。然而，企业必须解决安全和隐私问题，同时还要处理对桌面和邮件服务器的性能影响。大多数公司都努力将数据从本地机器上移除；然而，桌面似乎是将个人数据存储与更大的集中式存储库聚合的最佳场所。
所有这三种搜索解决方案都可能出现在面临海量信息管理挑战的企业中。在摩根士丹利，我们有一个团队从事内网搜索和原始搜索引擎的研究已有五年多，并且自 2004 年以来一直在试验桌面搜索。这个难题的第四部分尚未普及：结合标签、分类和导航来改善最终用户的整体体验。这一部分是必需的，因为仅靠机器相关性算法不足以产生高质量的内网搜索结果。在本文中，我们将讨论这样一个系统的外观，并特别强调解决企业级问题。
不断演进的搜索界面
摩根士丹利内部的许多团队已将搜索功能构建到他们的企业应用程序中。对于一些人来说，搜索用户界面是关键的分发机制，而对于另一些人来说，搜索只是一个小的附加功能。由于实际上有数千个不同的应用程序，因此很难概括我们如何使用搜索界面，但以下两个应用程序说明了搜索是如何演变的。
图 1 中显示的屏幕来自我们 2000 年最受欢迎的面向客户的应用程序之一。它允许客户使用高级搜索界面获取关于数百家上市公司的详细研究报告。每份报告都标有足够的元数据，以实现极其集中的搜索。
2004 年，我们一个小组构建了一个 Web 应用程序，以允许多方面浏览培训材料，如图 2 所示。用户的反馈非常积极；他们的反应表明，他们很快找到了他们正在寻找的项目；发现了未寻求但感兴趣的项目；即使难以表达所寻求的内容，也成功地搜索到了项目；从未遇到死胡同，不知道如何继续；并且当他们的搜索完成时，他们对找到了所有符合他们感兴趣的特征的对象感到满意。
这与其他研究项目的结果非常一致，例如 2002 年在 Communications of the (http://www.sims.berkeley.edu/~hearst/papers/cacm02.pdf) 中进行的一项调查。
然而，此应用程序中明显缺少的一个功能是全文搜索。用户希望运行全文搜索，然后按方面浏览结果，或者浏览到一组文档，然后从那里运行全文搜索。
尽管高级搜索界面比方面浏览提供更深层次的功能，但用户发现它难以使用。如果他们第一次无法选择正确的过滤器集，许多人不愿意继续尝试不同的参数。对于最终用户而言，工具的价值随着每次没有帮助他们实现目标的点击而下降。对于许多用例，方面导航成为可用性的一个受欢迎的改进。事实上，许多人随后希望将此系统应用于公司内的其他应用程序。
构建企业元数据目录
在帮助许多团队遵循相同的步骤（在不同的数据领域中）之后，我们意识到我们面前存在一个重要的优化机会。我们查看了所有这些项目，并将共同的工作提取到以下步骤：
- 定义元数据模式。 我的应用程序可能关心文档的日期、作者、主题和关键字。如果这些是关于上市公司的研究报告，我们可能还需要股票代码和行业。
- 索引一组文档。 这不仅包括提取所有文本以进行常规搜索，还包括将元数据提取到自定义字段中。
- 编写用于查询和显示结果的用户界面。 这通常涉及硬编码输入字段，以允许按此领域的相关元数据进行排序和过滤。
作为一个基础设施团队，我们正在努力创建一个低成本平台，使业务用户能够解决过去“IT 部门要求”的问题。在评估市场上的相关产品后，我们决定组装整体解决方案，利用多个第三方组件。
本体管理
为了支持数百个可能从元数据目录中受益的不同业务应用程序，每个团队必须能够创建和维护自己的本体——一个表示特定领域元数据的字典。本体中的特定类别或字段是一个方面。它可能有一个或多个值，并且是强类型的，例如日期、数字或布尔值。
尽管程序员传统上会做这项工作，但允许业务用户自己做这项工作具有巨大的价值。这不仅会降低每个项目的成本，而且还会加快交付速度并降低启动新计划的门槛。正确构建此本体管理器意味着处理许多棘手的情况：
- 存在不同类型的元数据（日期、字符串、数字等）。这会影响用户界面，以及搜索的可比性。
- 不同的用户可能希望为同一元数据类别（例如，主题）分配不同的值。
- 某些元数据项需要允许多个值（例如，关键字）。
- 团队可能希望拥有某些元数据，这需要对任何更改进行审批流程。
- 由于每个团队都希望看到一组不同的方面，因此您的元数据用户界面本身也必须是元数据驱动的。
- 元数据的类别可能需要限制为树中的选择；这被称为分类法。分类法值的示例是部门 —> 技术 —> 企业基础设施 —> 搜索。
- 不同的元数据需要不同的验证（例如，六个字符的字母数字或任何有效的股票代码）。
提取元数据
除了关于作者的信息外，我们还可以从文档中获取许多其他元数据：
- 实体提取使我们能够从定义明确的领域中提取元数据。例如，我们可以轻松地从文档中提取公司名称和股票代码列表。
- AD 或 LDAP 目录可以告诉我们您的经理是谁，您在哪些邮件组中，您所在的地区等等。当我们稍后想要将兴趣相似的人匹配时，所有这些都可能很有用。
- 自定义数据库信息可以重新利用。例如，我们有一个数据库，其中保存着关于数千个多媒体文件的元数据。每个演示文稿都标有语言、系列、业务部门、日期、演讲者等。一个 XML 文件配置我们的数据库爬虫，以将表中的列映射到本体中的值。
- 当所有其他方法都失败时，始终可以进行屏幕抓取。虽然主要的 ISV 无法为客户可能使用的每个自定义应用程序构建这些脚本，但我们可以。此外，我们可以根据为任何特定系统提取元数据的附加值来确定工作的优先级。
- 许多供应商应用程序，例如微软的 SharePoint，已经从用户那里捕获了大量的元数据。我们可以通过将自己插入“更新管道”来比爬虫集成更进一步，以便我们可以实时将更改发送到我们的元数据目录。
用户界面
元数据提取永远不是完美的，即使它是完美的，用户仍然希望修改找到的元数据。为了使系统在现实世界中工作，它需要允许最终用户添加自己的元数据，这个过程很快就会变得复杂。可用性对于浏览结果也非常重要。挑战包括：
- 全文搜索必须能够与方面浏览相结合，并按相关顺序排列。
- 每个结果页面都必须提供不同的 URL，以便通过电子邮件、IM 或在博客上发布进行共享。
- 元数据更新必须尽可能容易——至少要像 Netflix 那样的 AJAX 评分。理想情况下，最好是并排预览和元数据编辑。
- 在企业中，批量更新的频率远高于消费者，因此必须支持在不进行过多点击的情况下允许这样做。
- 必须通过 RSS 或电子邮件警报通知已保存搜索中的更改。
无论界面多么易用，团队都保证想要自己的更改。我们正在通过提供“非常好”的开箱即用用户界面来解决最后一个问题，但允许任何团队自定义自己的版本。我们可以使用模板引擎来实现这一点。这允许每个团队有选择地覆盖用户界面的不同方面：浏览顶部方面和搜索结果。
虽然用户需要具备 HTML 知识，但这种选择将使我们能够超越使用 CSS（层叠样式表）对同一用户界面进行外观修改，达到可以在页面中添加新内容和集成，而无需平台团队进行任何工作的程度。如果这仍然不够，我们还将支持 SOAP API，以便所有数据都可以被另一个 IT 团队重新利用。
需要注意的事项
在构建此元数据目录时，我们遇到了一些挑战。
可扩展性。 我们的初步目标是平台能够索引 100 万份文档，每份文档都包含各个类别中的元数据。这足以显示系统的价值，但甚至无法接近捕获我们想要捕获的文档数量。
安全性。 数据安全是金融服务行业非常关注的问题。对于这个系统，我们面临两个不同的问题：
- 谁有权更新一条元数据？由于每个业务部门都能够创建自己的分类法，因此它有合理的期望能够控制谁可以更新其字段以及任何特定的人可以分配什么值。例如，我们的培训部门为公司发布“技术技巧”文档。但是，每个业务部门都有指定的技巧批准人，他们认为这些技巧是相关的。然后，它将其业务部门添加到元数据类别“目标业务部门”。
- 谁有权查看关于文档的特定元数据（或知道文档的存在）？虽然之前的安全问题提出了一些政策问题，但这一个问题提出了一些技术限制。决定谁有权查看特定文档已经足够困难了，但是如果您允许这种类型的访问控制按方面存在，则问题会立即按一个很大的因子放大，具体取决于系统中的方面数量。
查询优化。 到目前为止，我们方便地忽略了大多数成功的搜索项目中发生的一个重要步骤：查询优化。用户和管理员都想知道为什么文档在特定查询中排名不高，或者为什么看似不相关的文档被返回。这些一次性问题可以通过调整索引、同义词库或排名算法来解决。尽管任何特定请求都不需要很长时间来处理，但时间投入会很快累积起来。此外，积极主动的系统所有者应定期查看查询日志，以了解用户正在搜索什么、什么产生零个或少量结果以及哪些项目被点击次数最多。对于单个应用程序来说，这已经足够困难了，但弄清楚如何将其扩展到同一核心平台上的数百个应用程序，不用说，这是一个相当大的挑战。
未来工作
审计跟踪。 金融业受到严格的监管控制。必须知道谁在何时访问或修改了什么内容。任何新应用程序都必须在设计时考虑到这些约束，需要完整的审计跟踪。以下是人们希望包含的一些报告：
- 对于此特定文档，向我显示与其关联的每条元数据，谁添加了它以及何时添加的。
- 对于此特定类别的元数据，向我显示哪些文档已被标记，给出了哪些值，由谁给出以及何时给出。
- 对于此特定用户，向我显示在这些日期内使用这些关键字访问的所有文档。
协作元数据标记（大众分类法）。 在过去几年中，我们构建了一些备受瞩目的元数据目录。然而，每个目录都需要专人来最终确定和批准所有更新。虽然这对于这些项目来说效果很好，但它为可能没有那么多资金或明确结构的项目的进入设置了很高的门槛。
评分。 社区评分已被证明在 Digg、亚马逊和 Netflix 等网站上非常成功；然而，在企业应用程序中，很少有实现。虽然互联网提供了一定程度的匿名性，但这在公司中很少见。即使受到公开对话和建设性反馈的鼓励，许多人仍然可以理解地对公开和公共评分系统的潜在不利影响感到不安。
假设这个问题得到解决，我们的第一个实现很可能是一个简单的从一到五的“平均评分”。每次添加新的评分时，我们将重新计算平均值，并将该值粘贴到一个方面中。这允许用户像所有其他方面一样浏览和缩小范围。
尽管平均评分应该有所帮助，但实用性方面的更大飞跃将来自第二阶段。这将是我们考虑个人资料数据以提供每个用户独有的自定义排名的时候。例如，同一部门内用户的评分应比公司其他部门的评分权重更高。该系统将使我们在知识发现的复杂性方面更进一步，从“这是我认为该文档与您相关的程度”到“这里有一些您可能会感兴趣的文档”。
审批工作流程。 每个团队都希望对其自己独特的审批工作流程用于向文档添加元数据。减轻平台团队的这项工作可以更快地交付自定义需求。为了允许充分的灵活性，我们将与完整的工作流程引擎集成，以抽象出每个本体的审批。
每当有人尝试更新特定本体中的元数据时，我们都可以启动审批工作流程。对于最简单的实现，电子邮件将发送给审批组，他们只需单击“批准”或“拒绝”按钮即可。更复杂的示例包括诸如“如果有人试图用黄金标签标记客户，则需要该组中的任何官员批准。如果有人想用白金标签标记客户，则需要一位董事总经理批准，然后向邮件组发送通知电子邮件。”之类的逻辑。当处理复杂的金融信息时，业务规则可能会变得非常复杂。
一致的警报。 当系统中添加了他们可能感兴趣的项目时，用户希望被主动通知。但是，订阅搜索结果对于大多数业务用户来说仍然相对较新。尽管 RSS 似乎是显而易见的解决方案，但许多传统用户并不经常使用聚合器。这意味着我们需要支持多种方式来提醒用户。我们已经构建或计划构建 RSS 模块；内网门户上的警报框；电子邮件（实时和每日摘要）；以及 IM 弹出窗口。
合适的时机
虽然搜索在过去几十年中一直是一个重要的话题，但直到最近它才成为每个企业应用程序不可或缺的一部分。过去几年中发生了一些重大事件，包括：
数据爆炸。 随着电子邮件、即时消息、RSS 和不断增长的内网，现在有如此多的数据，以至于许多用户感到他们遭受了信息过载。
普及的桌面搜索。 谷歌、微软和其他主要厂商提供免费的桌面搜索解决方案，大大提高了知识工作者的生产力。它们还允许编写插件，IBM 等公司已经使用这些插件连接到后端系统。
Lucene。 这是一个开源搜索包，越来越多的第三方应用程序（包括 Eclipse、Lookout 和 CNET.com）正在使用它。总共有 187 个团队正在使用 Java 版本。Perl、Python、C++、.NET 和 Ruby 中也提供了端口。
Autonomy。 Autonomy 最近收购了 Verity，创建了一套组合的企业搜索功能，看起来非常有前途。这些功能包括分类、聚类，甚至自动本体创建。
微格式。 这种草根努力正在将结构引入 Web 上的 HTML 文档。随着越来越多的数据生产者提供这些线索，实体提取工具可以轻松地提高其相关性。
OWL（Web 本体语言）。 语义网基于 RDF（资源描述框架），但这并不能解决任何特定领域的问题。为此，创建了本体，通常使用 OWL (http://www.w3.org/TR/owl-features/)。
知识工作者需要更好的工具来处理他们每天处理的急剧增加的数据。尽管市场已取得很大进展，但仍需要创新来解决大型企业的挑战。标签和分类的可用性以及搜索结果的质量将是成功的关键因素。如果做得正确，这将提高那些必须将数据海洋转化为可操作信息的人员的生产力。
瑞安·巴罗斯是摩根士丹利机构证券技术部门的副主管。
吉姆·特拉维索是摩根士丹利机构证券技术部门的执行董事。
应用
Del.icio.us / Dog Ear
1. 元数据模式
URL 单行文本
标签 多值，单行文本
2. 添加数据
将数据导入系统的最佳工具是：
• 书签小程序
[javascript:location.href=’http://server/add?url=’+location.href+’&tags=’+document.title]
• 桌面导入器，用于爬取用户的书签。它还可以为文件夹名称添加标签。
3. 浏览结果
• 虽然标准用户界面可以使用，但我们可能希望添加一行，为每个结果中的每个标签创建一个链接。此模板脚本看起来像：
[ foreach $tag in $Tags: <a href=’browse?tags=$tag’>$tag</a> ]
股票研究报告
1. 元数据模式
URL 单行文本
分析师 单行文本
行业 单行文本
公司 多值，单行文本
股票代码 多值，单行文本
地区 多值，单行文本
报告日期 日期
2. 添加数据
由于研究报告可能已存在于另一个系统中，因此将它们引入另一个目录的最佳方法是编写数据库爬虫并使用 SOAP API。
3. 浏览结果
对于此应用程序，开箱即用的方面浏览效果很好。
最初发表于 Queue 第 4 卷，第 4 期—
在 数字图书馆 中评论本文
更多相关文章
拉坦亚·斯威尼 - 在线广告投放中的歧视
当搜索带有黑人听起来的名字时，是否比搜索带有白人听起来的名字更频繁地出现暗示逮捕记录的在线广告？ 什么是黑人听起来的名字或白人听起来的名字？ 广告必须不利地影响一个种族群体多少次才能被认为是歧视？ 在线活动是否如此普遍，以至于计算机科学家必须考虑技术设计中的结构性种族主义等社会后果？ 如果是这样，这种技术应该如何构建？ 让我们深入研究在线广告投放，以寻找答案。
拉马纳·拉奥 - 从信息检索到搜索，以及更远
自从范内瓦·布什的开创性文章《诚如所思》描绘了一位学者借助机器的形象，“一种个人在其中存储所有书籍、记录和通信的设备，并且该设备是机械化的，因此可以以极快的速度和灵活性进行查阅”，至今已近 60 年。
迈克·卡法雷拉，道格·卡廷 - 构建 Nutch：开源搜索
搜索引擎与网络基础设施的任何其他部分一样，对于互联网的使用至关重要，但它们与其他组件在两个重要方面有所不同。 首先，它们的内部运作是秘密的，不像 DNS（域名系统）的运作那样。 其次，它们掌握着政治和文化权力，因为用户越来越依赖它们来浏览在线内容。
安娜·帕特森 - 为什么编写自己的搜索引擎很难
一定有 4,000 名程序员在他们的地下室里不停地敲代码，试图构建下一个“世界上最具可扩展性”的搜索引擎。 它只完成了几次。 从未由一个大型团队完成过； 总是由一到四个人完成核心工作，然后大型团队才开始构建精细化和生产基础设施。 为什么这么难？ 我们将深入研究编写搜索引擎时需要考虑的各种问题。 本文旨在为那些正在考虑为其网站或内网进行这项工作的个人或小型团队而写。
© 保留所有权利。