Knowledge

定义

Knowledge 是本文讨论的 AI Agent 存储体系中的“知识层”，与 Agent Memory 并列，主要承载知识库内容的原文、摘要以及其他可检索的文档内容。

它的核心能力不是简单保存文本，而是语义检索：让系统能够围绕文档内容执行向量检索、全文检索，并把召回结果进一步提供给大模型使用。

在文中，Knowledge 的典型应用包括：

• RAG 知识库
• 多模态搜索
• 面向文档内容的语义搜索与召回

换言之，Knowledge 关心的是“有哪些知识文档、怎么存、怎么按语义和文本高效找出来”，而不是“某个用户刚才说了什么、当前会话进行到哪一步”。

与 Agent Memory 的分工差异

本文明确把 Agent 的核心存储能力分成两类：Agent Memory 与 Knowledge。

• Agent Memory 偏“记忆”能力，主要处理情景记录、情景摘要、实时数据抽取、会话上下文管理、状态同步等问题。
• Knowledge 偏“知识”能力，主要处理知识库原文、摘要、文档内容的存储与检索，重点是语义搜索效果，以及围绕规模、性能、成本构建可用系统。

因此，两者虽然都服务于 Agent，但面向的数据形态和检索目标不同：

• Memory 更接近会话流、状态流、短到中期可回忆内容。
• Knowledge 更接近文档流、知识库内容、可长期维护和检索的资料集合。

如果用工程视角理解：

• 用户与模型连续聊天、系统要知道“再来一个”指的是什么，这是 Agent Memory 的问题。
• 用户上传资料后，系统要找出和某个问题最相关的片段并交给大模型，这是 Knowledge 的问题。

在本文档中的语境

本文并不是孤立讨论 Knowledge，而是把它放在一个基于 Tablestore 的轻量级 Agent 存储框架中，与 Agent Memory SDK 一起出现。

该框架的场景驱动设计当前主要支持两个方向：

• Memory 的实时记忆存储
• Knowledge 的长期语义检索

这里“长期语义检索”是理解本文 Knowledge 的关键。它强调的不只是能存文档，而是：

• 要支持全文检索与向量检索并存
• 要兼顾大规模场景下的性能与成本
• 要考虑多租户隔离与查询路径优化
• 要尽量减少开发者手工调优索引结构的负担

因此，Knowledge 在本文中不是一个抽象概念，而是一套面向 AI 检索场景的数据组织与索引设计。

表设计与主键规则

本文对 Knowledge 的表设计给出了非常明确的规则，这些规则直接服务于向量检索、全文检索和多租户场景下的性能稳定性。

1. DocumentID 作为分区键

Knowledge 表中，DocumentID 被放在第一个主键位置，作为表的分区键。

这样设计的原因是：Knowledge 场景下常常同时保存全文字段和向量字段，单行数据会比较大。如果分区策略不合理，容易导致热点分区、读写压力不均或局部抖动。

把 DocumentID 作为分区键后，可以把不同文档离散到多个分区中，从而：

• 打散文档写入压力
• 平衡全文 + 向量大行带来的分区负载
• 让各分区的读写压力更均衡

这不是单纯的主键命名习惯，而是为了应对 Knowledge 场景下“大文档 + 多索引”的工程约束。

2. DocumentID 与 TenantID 组合作为唯一主键

本文进一步规定：DocumentID 与 TenantID 两个主键字段组合起来，作为唯一主键。

这意味着：

• 单看 DocumentID，它承担的是分区打散作用
• 结合 TenantID 后，才能唯一标识一条文档记录

如果业务不是多租户场景，文中给出的处理方式也很直接：TenantID 填默认值即可。

这条规则的意义在于，Knowledge 的主键模型从一开始就兼容：

• 单租户部署
• 多租户部署
• 相同文档编号在不同租户下分别存在的场景

多租户设计

Knowledge 的多租户设计是本文强调的重点之一，因为知识库类业务很容易出现“每个客户、每个组织、每个空间拥有独立文档集合”的需求。

文中的做法是：当用户开启多租户特性后，将 TenantID 设置为多元索引的路由键。

这样做的直接效果是：同一个租户的数据可以尽量落到指定分区范围中，查询时不需要访问所有分区。

由此带来的收益包括：

• 降低查询消耗
• 减少跨分区扫描
• 降低查询毛刺
• 提高多租户场景下的稳定性与可预测性

这里的“毛刺”可以理解为查询延时抖动或资源消耗突增。对于知识检索系统来说，如果每次检索都需要扫全局分区，租户越多，查询成本和不稳定性通常越高。

因此，本文里的多租户设计不是简单加一个 TenantID 字段做过滤，而是把它纳入索引路由层，让查询路径从源头上更收敛。

全文检索机制

Knowledge 同时依赖全文检索与向量检索。对于全文检索，文中给出的机制是：text 文本字段会在多元索引中自动创建最大语义分词。

这意味着在默认配置下，知识文档的主要文本内容可以直接进入可检索状态，不需要开发者先手工做一整套分词配置才能开始使用。

同时，本文也说明了边界：如果默认的最大语义分词方式不适合业务需求，分词方式可以随时调整或修改。

因此，全文检索的特点是：

• 默认可用，自动建索引
• 默认分词方式是最大语义分词
• 后续可按业务需要修改分词策略

这对于 RAG、企业知识库、文档搜索等场景很重要，因为不同业务对术语切分、召回精度、查询容错的要求并不相同。

向量检索机制

Knowledge 的另一条核心能力是向量检索。文中规定：embedding 向量字段会自动创建向量索引。

更关键的是，底层会自动选择合适的索引结构进行索引，用户无需自行调优和优化。

这说明本文中的 Knowledge 设计追求的是“让开发者关注文档和检索逻辑，而不是先去研究底层向量索引参数”。

其特点可以概括为：

• 文档写入时可直接带上 embedding
• 系统自动为向量字段建立检索能力
• 底层索引结构自动选择
• 用户不必手工做复杂索引调参

这对于很多 AI 应用团队很关键，因为他们真正关心的是：

• 查询向量如何生成
• 召回多少条结果
• 是否按租户过滤