AI 时代,知识库几乎成了每个企业的标配。表格存储(Tablestore)在 AI 领域已服务通义千问、钉钉、夸克、1688、ECS AI 助手等众多产品,并先后对接了 LangChain、LlamaIndex、Dify、PAI-RAG 等主流开源框架,为不同技术栈的开发者提供了灵活的接入选择。
为什么要关注这些?
在与客户合作的过程中,我们关注到三个普遍存在的痛点:
- 数据自持需求:很多企业(尤其是金融、政务、医疗行业)要求知识库中的原始文档和向量数据必须留在自己的云账户内,不能经过第三方中转。
- 运维成本高:自建 RAG 系统需要持续维护 ES、Redis、MinIO 等一系列基础组件,对中小团队来说存在负担。
- 多租户数据隔离难:企业级知识库的隔离粒度往往比想象中更细——不只是“一个企业一个知识库”,而是每个员工、每个部门甚至每个项目都需要独立的知识空间。例如法务部的合同文档不应被其他部门检索到,员工的个人知识库也需要与团队空间严格隔离。传统做法要么为每个租户创建独立的知识库实例,导致资源浪费和管理复杂度线性增长;要么在应用层自行实现过滤逻辑,容易出现权限漏洞,且检索性能随租户数增长而下降。
基于这三个出发点,我们推出了 Tablestore 知识库服务(以下简称“知识库服务”)——基于表格存储原生提供的全托管 RAG 知识库解决方案。所有数据存储在客户自己的 OSS 和 Tablestore 账户内,服务本身不碰任何客户数据;同时采用 Serverless 架构,通过 API 即开即用,文档上传后系统自动完成解析、切块、向量化、索引构建的全部流程,开发者无需操心底层基础设施的运维。服务还内置了 Subspace 多租户隔离机制,在同一个知识库内即可为不同租户划分独立的数据空间,无需额外开发隔离逻辑。
Tablestore 知识库服务到底是什么?
Tablestore 知识库服务是基于阿里云表格存储构建的全托管 RAG 知识库服务。它为企业和开发者提供了从文档导入、智能解析、自动切片、向量化到混合检索的一站式能力,帮助用户快速构建高质量的知识检索系统,为大语言模型提供精准的上下文信息。
整套服务采用 Serverless 架构,用户通过 API 调用即可创建知识库、上传文档、执行检索,无需购买和部署物理服务器。存储与计算分离,按量付费,零用量零费用。更重要的是,整个流程中的原始数据、中间数据和结果数据均存储在客户自己的 OSS 和 Tablestore 账户内,服务本身不持有任何客户数据。
在典型的 AI 应用链路中,知识库服务处于核心的“知识管理与检索”环节——用户的文档经过解析、切片、向量化后存入知识库,LLM 在推理时通过检索接口获取相关上下文,从而基于文档内容给出准确回答。
先搞清楚它的框架:数据模型长什么样
知识库服务的核心实体包括 Instance(实例)、KnowledgeBase(知识库)、Document(文档)和 Chunk(文档切片),可以把它们理解成一套完整的文档管理梯队,它们之间的逻辑关系如下:
实体 |
说明 |
Instance |
Tablestore实例,一个实例下支持多个知识库 KnowledgeBase,可复用 Tablestore 通用 API 实例 |
KnowledgeBase |
知识库逻辑概念,每个知识库对应一张 Document 表、一张 Chunk 表和一张索引表。 |
Document |
文档记录,关联 OSS 文件,记录文档状态、元数据等信息。 |
Chunk |
文档切片,存储分片、向量数据、标题等信息。是检索的最小单元。 |
此外 Tablestore 知识库在 KnowledgeBase 中支持 Subspace 子空间,允许通过 Subspace 控制文档访问范围。简单来说,就是可以通过 Subspace 来控制不同人能看到哪些文档,实现精细化的访问管理。
六大核心能力,一次说清
- 全托管文档处理流水线 — 文档上传后,系统自动完成解析、智能切块、Embedding 向量化、索引构建等全部处理流程。当前支持 PDF、Word(doc/docx)、Excel(xls/xlsx)、PowerPoint(ppt/pptx)、纯文本(txt)、Markdown(md)等主流格式,HTML、CSV、JSON、XML、图片和视频也即将支持。开发者无需自行搭建文档处理 Pipeline,无需管理 Embedding 模型的部署和运维。
- 混合检索,精准召回 — 同时支持向量检索和全文检索两种模式,并提供 RRF、加权融合、模型 Rerank 三种排序策略。向量检索捕捉语义相似性,全文检索保障关键词精确匹配,两者融合后检索质量显著提升。
- 海量规模,弹性无上限 — 单个知识库最大支持 1 亿级文档,单实例下最大支持 256 个知识库。底层基于表格存储的分布式架构,本身就支持水平扩展,业务增长不用担心容量瓶颈。
- Subspace 多租户隔离 — 在同一个知识库内为不同租户(用户、部门、客户)隔离数据。每个租户只能检索到自己 Subspace 下的文档,开箱即用的数据隔离,无需为每个租户创建独立的知识库。
- 数据自持,完全可控 — 所有数据都存储在客户自己的 OSS 和 Tablestore 账户内,服务不持有或转存任何客户数据。满足金融、政务、医疗等对数据合规性要求极高的行业需求。
- 灵活可控,开放定制 — 从 Embedding 模型选择、检索策略配置、元数据过滤条件,到 Chunk 级别的内容修改和状态管理,全链路 API 可配可调。
跟自建方案比,它到底强在哪?
与自建 RAGFlow 对比:RAGFlow 是一款功能丰富的开源 RAG 引擎,提供文档解析、可视化切块、多模型接入等能力。但作为自建方案,客户需要自行部署和运维 Elasticsearch、MySQL、Redis、MinIO 等多个基础组件,海的持续关注容量规划、性能调优和服务可用性。
Tablestore 知识库底层依赖的 OSS 和 Tablestore 均为阿里云 Serverless 服务,容量自动弹性扩展,服务可用性由云平台保障。
对比维度 |
Tablestore 知识库 |
自建 RAGFlow |
部署方式 |
Serverless,API 即开即用 |
Docker Compose 部署,要求 CPU ≥ 4核、内存 ≥ 16GB、磁盘 ≥ 50GB |
依赖组件 |
无需关心,底层全托管 |
需自行运维 Elasticsearch、MySQL、Redis、MinIO 等 |
计费模式 |
按量付费,零用量零费用 |
开源免费,但需承担服务器、存储和带宽成本 |
文档处理 |
全自动,API 一步完成 |
需手动配置解析模板和切块策略 |
最大规模 |
单知识库 1 亿文档 |
受限于 ES 集群规模,需自行扩容 |
数据安全 |
数据在客户自己的 OSS/Tablestore 账户,不出域 |
取决于运维能力 |
多租户 |
Subspace 原生支持 |
需自行设计 |
运维成本 |
零运维 |
高(ES、MySQL、Redis、MinIO 的升级、监控、故障恢复) |
核心差别就一句话:自建方案需要负责基础设施的部署和运维,Tablestore 知识库只需调用 API,无需运维,数据在全流程在用户账号内。
这几种场景,用了都说好
- 企业知识问答系统 — 将产品文档、技术手册、FAQ、规章制度等导入知识库,结合 LLM 构建智能问答系统。员工或客户提问时,系统从知识库中检索最相关的内容片段,交由 LLM 生成基于文档的回答。客服、HR、法务、IT 运维等场景都能直接用。
- 文档智能搜索与摘要 — 替代传统关键词搜索,利用向量检索理解用户的搜索意图,返回语义最相关的文档片段。配合元数据过滤(按时间、分类、作者等维度),实现精准的文档检索体验。
- 多租户 SaaS 知识库 — 利用 Subspace 机制在同一个知识库内为不同租户隔离数据,无需额外设计隔离方案,管理复杂度和成本都大幅降低。
- RAG Pipeline 集成 — 作为 RAG 架构中的检索层,与 LangChain、LlamaIndex 等主流 AI 框架集成。文档灌入知识库后,推理阶段调用 Retrieve 接口获取相关上下文,拼接到 Prompt 中送入 LLM。
- 合规文档管理 — 金融、医疗、政务等行业的合规场景。所有数据存储在客户自己的云账户内,满足数据不出域的合规要求。通过元数据标注文档分类、版本、有效期,结合 Metadata Filter 精准检索。
以上就是 Tablestore 知识库服务的核心概念与能力全景。如果你已经心动,想知道具体怎么接入、API 怎么用、实际效果到底怎么样,欢迎继续阅读《知识库接入还能这么玩?Tablestore 四种方式实战揭秘》,手把手带你从 0 到 1 跑通全流程。