Dropbox的工程师们详细说明了该公司是如何构建出Dropbox Dash背后的上下文处理系统的。这一技术体现了向基于索引的检索方式、利用知识图谱生成上下文信息，以及通过持续评估来支持大规模企业级人工智能知识检索系统的转变。这种设计模式在各种企业辅助工具中普遍存在：开发团队有意限制对实时工具的使用，转而更加依赖经过预处理的、符合权限管理要求的上下文数据，以此来降低响应延迟、提升查询质量，并减轻系统负担。
在最近举行的一次技术演讲中，Dropbox的工程副总裁Josh Clemm将他们的这项技术描述为对企业环境中那些分散在数十种不同SaaS应用中的数据进行处理的一种解决方案。这些应用各自拥有不同的API、权限设置和请求速率限制。尽管最新的语言模型已经具备了推理功能，但Clemm指出，这些模型仍然无法直接访问企业的数据以获取所需的上下文信息，因此必须构建额外的基础设施才能安全地检索这些敏感数据。
Dropbox Dash的核心架构依赖于对内容进行预处理，而非在运行时进行推理和检索。来自各种关联知识应用的数据会在被查询之前被标准化、丰富化并建立索引，然后通过词汇搜索与密集向量相结合的方式来进行查询处理。这种方式使得应用程序能够在不需要在查询时生成复杂的API调用网络的情况下返回结果。
虽然这种处理方式会导致系统复杂度增加和存储成本上升，但Dropbox认为，考虑到离线排序实验带来的好处、更准确的相关性评估结果，以及可预测的查询性能，这项投资是值得的。
Dropbox Dash应用程序的一个关键组成部分就是利用知识图谱来构建各种与业务相关的信息之间的关联模型——这些信息包括人员、文档、会议记录等等。不过，开发团队并没有在运行时直接查询知识图谱数据库，而是先提取出“知识包”，然后将其纳入上述的索引处理流程中。Clemm指出，早期对知识图谱数据库的测试发现，这种处理方式会导致延迟增加以及查询模式发生变化，因此团队最终决定将知识图谱信息作为上下文数据进行丰富处理，而不是将其作为另一个独立的查询对象。
团队还提到了通过MCP（模型上下文协议）将多种工具直接集成到语言模型中所带来的挑战。他们发现，当许多工具被异步使用时，会导致系统性能下降、查询速度变慢。为了解决这个问题，团队将所有的检索功能整合到了少数几个高级工具中，这些工具能够获取提示信息之外的上下文数据，并将更复杂的请求转发给功能范围较窄的辅助系统进行处理。
MCP的创建者们也表达了对使用多种工具时上下文窗口消耗问题的担忧。他们指出，每添加一个新的功能，都需要进行仔细的管理。
除了信息检索功能外，Dropbox还强调了大规模进行标签评估的重要性。由于查询结果是由语言模型而非人类来处理的，因此传统的基于点击的相关性评分机制并不适用。Dropbox利用语言模型作为评判标准，来衡量和评价信息检索的质量。这样一来，他们就能够优化提示语和排序逻辑，从而减少与人工标注人员之间的分歧。
Dash团队利用DSPy这一用于提示语优化的框架，实现了评估流程的自动化。Clemm表示，DSPy能够管理所有工作流程中超过30种不同的提示语，这使得模型切换变得更加快速，而无需手动重新编写每个模型的提示语。
Dash团队采用的方法与其他企业级知识助手所采用的策略非常相似。Microsoft 365 Copilot同样依赖于从Microsoft Graph中提取的预计算语义索引，从而实现高效的信息检索。
综上所述，这些设计都表明，在企业级人工智能系统中，将上下文视为一个核心组成部分越来越受到重视，而不是在推理过程中临时生成的。随着各团队在大型组织中不断扩展自身的搜索和智能助手功能，那些能够预先计算、对上下文进行约束并持续对其进行评估的架构，似乎正在成为一种越来越普遍的基础设计。