架构与技术选型

系统架构

表格存储知识库服务采用全托管的 Serverless 架构，用户通过 API 与服务交互，底层资源由平台自动管理。

数据流转过程：

1. 调用 AddDocuments 接口，指定 OSS 文件路径（或通过 SDK 上传本地文件）。

2. 系统从 OSS 读取文件，自动完成文档解析和智能切片。

3. 对每个切片调用 Embedding 模型生成向量，写入 Tablestore 的 Chunk 表。

4. 自动构建向量索引和全文索引。

5. 调用 Retrieve 接口时，系统执行混合检索并返回相关Chunk结果。

所有数据（原始文档、解析结果、向量数据）均存储在用户账号的 OSS 和 Tablestore 内。服务本身不持有任何客户数据。存储与计算分离，独立计费。

数据模型

知识库的数据按五层实体组织：

系统自动在 Tablestore 中创建对应的数据表：

• Document 表：使用{知识库名}_{知识库 id}

• Chunk 表：使用 {知识库名}_{知识库 id}_chunk

• Index 表：使用 {知识库名}_{知识库 id}_index

数据源

知识库的数据源为阿里云对象存储（OSS）。不论通过哪种方式上传，文档的原始数据都存储在自己的 OSS Bucket 内。

知识库需要对 OSS Bucket 进行读写操作：读取原始文档进行解析和切片，将解析过程的中间结果写回 OSS。

支持以下三种方式将文档导入知识库：

• 上传本地文件：指定本地文件或目录，SDK 自动上传到 OSS 后添加到知识库。如果是目录，会递归遍历所有文件。

• 添加 OSS 文件：文件已在 OSS 上时，直接指定 OSS 路径添加到知识库，省去上传步骤。

• OSS 目录批量导入：指定 OSS 目录路径，系统自动递归扫描目录下所有文件。支持通过 inclusionFilters 和 exclusionFilters 按文件名模式过滤。

每种方式的详细用法参见文档管理。

Embedding 配置

Embedding 配置决定了文档切片如何被向量化，在创建知识库时指定。

不传 embeddingConfiguration 时，系统默认使用百炼 text-embedding-v4 模型（1024 维），适用于大多数场景。

选型建议：

• 通用中英文场景：推荐 text-embedding-v4（1024 维），在语义理解和性能之间取得较好平衡。

• 已有自研或第三方 Embedding 服务：使用 custom 模式接入，保持技术栈统一。

• 维度越高语义表达越丰富，但存储和计算成本也越高。1024 维是大多数场景的推荐选择。

检索策略概述

调用 Retrieve 接口时，检索配置（retrievalConfiguration）按以下优先级确定：

Subspace 多租户

Subspace 是知识库内的数据隔离分区，适用于在同一知识库内按用户、部门或租户隔离数据的场景。创建知识库时设置 "subspace": true 开启。

核心规则：

• 开启 Subspace 后，所有文档操作（添加/查询/删除/列出）和检索都必须指定 subspace 字段，否则报错。

• Retrieve 支持同时查询多个 Subspace（传入列表），最多 32 个。

• Subspace 名称最大长度 128 字符。

• Subspace 开关创建后不可修改。

在企业环境中，同一部门的每位员工有各自的文档。部门管理员创建一个知识库并开启 Subspace，为每位员工分配一个独立的 Subspace（如 employee_zhangsan、employee_lisi）。每位员工的文档互不可见，管理员统一管控知识库配置。当需要跨员工检索时，在 Retrieve 时传入多个 Subspace 即可联合检索。

配额与限制

适用性评估

推荐使用的场景：

• 为 LLM 应用构建 RAG 检索能力

• 需要向量检索 + 全文检索的混合检索

• 需要多租户数据隔离

• 文档规模从几百到百亿级

• 对数据安全有严格要求（数据不出自己的账户）

• 希望按量付费、零运维

需要评估的场景：

• 对文档索引实时性要求极高（文档上传到可检索是异步过程，存在处理延迟）

• 需要自定义切片策略（当前为系统自动切片）

不推荐的场景：

• 纯结构化数据查询（建议使用表格存储宽表模型或关系型数据库）

• 需要实时流式数据索引（建议直接使用Tablestore多元索引）