如何构建上下文层和公司大脑

将公司分散的知识转化为法学硕士可以可靠使用的东西实际上需要什么——以及为什么演示占工作量的 5%。如何构建上下文层和公司大脑的帖子首先出现在走向数据科学上。

来源:走向数据科学

每家采用法学硕士的公司都会有同样的想法:“如果模型知道我们所知道的一切怎么办?”仓库模式、概念页面、实际做出决策的 Slack 线程、有关哪个表已弃用以及哪个列所在的部落知识。公司大脑。

演示版本是一个周末项目:分块文档,嵌入它们,检索余弦相似度的 top-k,粘贴到提示中。它在前十个问题上表现得非常好——然后在生产中悄然崩溃。本文讨论的是这种差距,基于为许多租户跨数十个源执行此操作的生产系统。

上下文层实际上是什么

不是矢量数据库。矢量数据库是其中的一个索引。

这是一个不断将源系统映射到规范化、类型化上下文项的系统;以多种专门方式对它们进行索引;在查询时将正确的子集组成令牌预算;从管理和使用中学习;并根据它所描述的来源采取行动——所有这些都以租赁、许可、新鲜度和成本作为一流的约束。每个动词都隐藏了演示从未遇到的分布式系统难题,因为演示只摄取一次,只有一个用户,并且从未被问到“为什么它不知道 X?”

第 1 部分:连续映射

摄取不是批处理作业;这是一个永远不会终止的协调循环。表被删除、频道被存档、页面被编辑、权限被撤销。陈旧一周的大脑比无用更糟糕,因为人们信任它。

循环是一个覆盖查询:给定层次结构和商店中有什么,缺少什么以及过时的是什么?每种类型都声明自己的刷新节奏,并且刷新需要自己的队列 - 与首次挖掘共享一个队列,积压的工作将使新连接的源数天饥饿。这需要一个持久的工作流编排器,不是因为调度很困难,而是因为重复数据删除触发器、限制扇出和避免崩溃很困难。

第 2 部分:索引

第 3 部分:检索是一个编排问题

结束建议