Dropbox 是怎么搭建可扩展的企业知识搜索上下文引擎的？这事儿我来给你唠唠。其实就是Matt Foster，还有Josh Clemm这两位工程师，在最近一次演讲里详细讲了他们是怎么弄出来的Dropbox Dash。这东西背后有啥玄机？主要就是让企业用AI搜索的时候能更快、更稳，少依赖实时工具。Dropbox现在的这套设计挺有意思，他们不光是把数据拿过来直接搜，而是先预处理、加权限，弄成索引。这么一来就能大大减轻延迟和Token消耗的压力。 Josh Clemm把这事儿归结为企业工作分散在几十个SaaS应用里。这些应用各有各的API和权限规则，所以最新的大模型虽然懂推理，但没法直接拿企业数据做上下文。为了安全获取这些敏感信息，Dropbox就得搞点额外的基础设施。Dash的核心就是把内容预处理好，不用在用户提问的时候再跑去调用一堆复杂的API网络了。虽然这多花点复杂度和钱，但考虑到离线排序、优化相关性信号还有性能更稳定，这钱花得值。 这个Dash应用的核心组件之一是知识图谱。团队把人和文件这些常见对象的关系都弄成图，但不是直接查图数据库。他们先把图谱变成“知识包”，然后塞进之前说的索引流程里。因为早期试过直接查图发现太卡不稳当。 另外还得说一下MCP的事。Dropbox在使用模型上下文协议时遇到了不少问题。把太多工具给语言模型用很容易把上下文窗口占满，导致智能体变慢、查询也慢。为了解决这个问题，他们把检索能力合并到少数高阶工具里去了。这些工具可以主动拿上下文，再把复杂请求转发给专门的智能体处理。 除了检索，大规模标注评估也很重要。因为查询结果是给语言模型看的不是给人看的，所以传统的点击数据不管用了。Dropbox用另一个语言模型当评判者来打分，优化提示词和排序逻辑，让机器打分跟人工标注更接近点。他们用DSPy这个框架把整个评估流程工程化了。Clemm说DSPy能管30多个提示词的工作流，换模型也方便不用重写提示词了。 这种方案其实跟别的企业助手思路挺像的。Microsoft 365 Copilot也是从Microsoft Graph弄语义索引来做上下文检索的。这说明一个趋势：在企业AI里，上下文得当成一等公民来对待，不能到了推理的时候才去临时拼凑。随着团队在大组织里扩大搜索和智能体能力，预先计算、权限约束和持续评估上下文的架构正变得越来越主流了。