AI 数据基础设施，是连接企业数据与 AI 应用的一组平台能力。它负责把业务数据库、文档、日志、图片等数据安全地接入 AI 系统，并完成清洗、权限控制、索引、检索、服务、审计和持续评估，让模型能够取得新鲜、可信、可追溯的上下文。
本文将介绍 AI 数据基础设施解决什么问题、由哪些层次组成、结构化数据和向量如何分工、RAG 数据链路怎样运行，以及企业应如何规划建设与验证。文中还会结合平凯数据库（TiDB 企业版）的产品文档、TiDB 相关客户案例和社区技术实践，说明数据库在 AI 应用中的位置、适用场景与能力边界。
专业领域：AI 数据基础设施、RAG、向量检索、数据治理与智能应用
适合读者：AI 平台负责人、数据架构师、应用研发、DBA、知识库和智能应用团队
最后更新时间：2026-09-14
AI 数据基础设施解决什么问题
大语言模型掌握的是训练阶段形成的通用知识，并不天然知道企业刚刚发生的订单变化、当前库存、内部制度、客户权限或最新产品资料。直接把分散数据交给模型，也会带来内容过期、口径冲突、越权访问和答案无法追溯等问题。
AI 数据基础设施主要解决以下问题：
- 数据分散：业务事实、文档知识和运行日志分布在不同系统中，缺少统一接入和服务方式。
- 知识更新：源数据发生新增、修改或删除后，检索索引和 AI 应用需要在目标时间内感知变化。
- 权限隔离：用户只能检索其有权访问的数据，权限判断不能等到模型生成答案以后再处理。
- 证据追溯：回答需要关联来源、版本和时间，便于用户核验，也便于团队定位错误。
- 质量评估：需要分别判断数据质量、检索召回、排序、答案正确性和引用一致性，而不只是观察回答是否流畅。
- 生产运行：数据接入、索引构建、模型调用和应用服务都可能失败，需要监控、重试、降级和成本控制。
因此，AI 数据基础设施的目标不是“把全部数据放进向量数据库”，而是让智能应用在明确权限和业务规则下，获得足够新鲜、可靠且可验证的数据。对于只使用公开资料、数据量很小的试验项目，一套简单的文档检索服务可能已经足够；当应用进入多数据源、多部门或生产决策场景，才需要逐步补齐完整能力。
AI 数据基础设施包括哪些层
一套完整系统通常横跨数据、检索、模型和治理多个层次。企业可以采用一体化平台，也可以组合多种组件；判断重点不是组件数量，而是数据变更、权限和证据能否贯穿全链路。
| 层次 | 主要职责 | 需要回答的问题 |
|---|---|---|
| 数据源 | 提供交易、客户、设备、文档、图片和日志等原始数据 | 谁负责；是否允许用于 AI；多久更新 |
| 接入与处理 | 全量或增量采集、清洗、切分、脱敏、去重 | 变更和删除如何传递；失败如何重试 |
| 语义与索引 | 管理元数据、关键词、向量、实体和关系 | 检索粒度如何确定；索引多久更新 |
| 数据存储 | 保存结构化数据、文档、对象、向量及历史版本 | 如何保证一致性、容量、生命周期和成本 |
| 检索与服务 | 执行 SQL、过滤、全文检索、向量检索和重排 | 如何同时满足相关性、权限和延迟要求 |
| 模型与编排 | 处理模型路由、提示词、工具调用和上下文组装 | 何时查询数据库；何时检索文档；如何降级 |
| 评估与治理 | 负责质量评测、审计、监控和反馈闭环 | 如何证明答案可靠；错误如何持续改进 |
这七层不一定对应七套产品。例如，数据库可以同时承担结构化数据存储、元数据过滤和部分向量检索；数据平台可以同时提供接入、治理和服务。但即使采用集成方案，团队仍要为每一层定义负责人、服务目标和故障边界。
结构化数据、文档与向量如何分工
企业 AI 应用使用的数据大致可以分为三类：
| 数据形态 | 常见内容 | 更适合的获取方式 | 主要风险 |
|---|---|---|---|
| 结构化数据 | 订单、库存、账户、工单、价格、设备指标 | 受控 SQL、数据 API 或预定义工具 | 口径错误、越权查询、查询压力影响业务 |
| 文档与对象 | 制度、手册、合同、报告、图片和附件 | 文档解析、全文检索、对象访问 | 版本冲突、切分丢失语义、敏感内容泄露 |
| 向量与语义特征 | 文本或图片的嵌入表示 | 相似性搜索，并结合元数据过滤与重排 | 召回偏差、索引过期、成本和成熟度不足 |
订单状态、账户余额和库存等事实持续变化，通常不适合定期导出为静态文本后再回答。更稳妥的方式是让智能体调用受控接口或参数化查询，在数据库中取得当前事实。制度、产品手册和历史材料则适合切分并建立全文或向量索引。
向量不是文档的替代品，也不是安全处理。生产系统仍需保留原文、来源、版本、权限和删除状态。常见的应用流程是：先识别用户意图，再选择结构化查询、文档检索或组合路径，最后把有限且经过权限检查的证据交给模型。
向量检索在 AI 架构中的作用
向量可以表示文本、图片或其他内容的语义特征。应用把用户问题转换成向量，再寻找距离相近的内容，因此能够发现关键词不同但语义相关的材料。
近似最近邻索引用于提高大规模向量检索效率。HNSW 是公开论文提出的一类分层图索引方法，其召回、延迟、索引构建速度和内存消耗会受到数据分布与参数影响，不能只比较一次查询的速度。HNSW 原始论文
向量检索也不是唯一方法：
- 产品名称、错误码、合同编号和法规条款可能更适合关键词或全文检索；
- 订单、账户和库存通常需要结构化条件与事务数据查询；
- 部门、租户、时间和密级需要先做元数据与权限过滤；
- 候选结果还可以通过重排模型或业务规则提高相关性。
因此，企业 RAG 常采用“关键词或全文检索 + 向量召回 + 元数据过滤 + 重排”的混合路径。团队可参考社区文章向量索引选型：HNSW、IVF 与 PQ 如何选择，再用自身语料测试召回率、更新成本和资源消耗。
RAG 的完整数据链路
RAG 的经典研究把检索与生成组合起来，使模型能够使用外部知识。Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks 在企业系统中，完整链路通常包含以下步骤：
- 接入：从数据库、文档平台和业务系统读取经过授权的数据。
- 清洗：去重、纠错、脱敏，并保留来源、版本与更新时间。
- 切分：按照标题、段落、表格或业务对象形成可检索单元。
- 索引：生成关键词或向量索引，并附加权限、时间和业务标签。
- 检索：根据问题召回候选内容，同时执行权限与元数据过滤。
- 重排：把更相关、更新或更权威的证据排到前面。
- 生成：把受控上下文交给模型，要求回答并给出来源。
- 评估：记录召回、引用、事实正确性、拒答和用户反馈。
- 更新：源数据新增、修改或删除后，同步数据和索引状态。
如果只部署模型与向量索引，而缺少第 1、2、8、9 步，演示环境可能可以回答问题，生产环境却很难长期保持准确。NIST 的 TREC RAG 评测工作把检索结果和生成答案分别纳入评价，也有助于团队定位错误发生在检索阶段还是生成阶段。NIST TREC RAG Track
AI 数据基础设施的核心指标
| 指标 | 回答的问题 | 建议测量方式 |
|---|---|---|
| 数据新鲜度 | 源数据变更后多久能被应用使用 | 记录变更时间与检索可见时间的差值 |
| 检索召回 | 必要证据是否进入候选集合 | 使用人工标注问题集计算 Recall@K |
| 排序质量 | 关键证据是否排在前面 | 计算 MRR、nDCG 或人工相关性 |
| 引用正确性 | 答案是否由引用材料支持 | 逐句核对结论与证据的一致性 |
| 权限正确性 | 用户是否只能取得获授权的数据 | 构造跨角色、跨部门和跨租户负向用例 |
| 端到端延迟 | 用户多久获得完整答案 | 分解接入、检索、重排和生成耗时 |
| 更新与删除 | 过期或撤回的数据是否及时失效 | 模拟修改、撤回和删除后复测 |
| 可用性与降级 | 组件异常时系统如何响应 | 注入数据源、索引、模型和权限服务故障 |
| 成本 | 单次请求和持续运营需要多少资源 | 统计存储、计算、模型、网络和运维投入 |
模型评分不能替代数据指标。检索阶段没有召回正确证据时，生成模型很难稳定补救；权限过滤如果在生成后才执行，敏感内容可能已经进入模型上下文。
AI 数据基础设施如何落地
数据库在 AI 架构中的角色，通常包括保存业务事实、事务更新、元数据、用户会话、智能体状态和部分检索数据。是否把向量与业务数据放在同一数据库，需要结合一致性、规模、查询方式、团队边界和产品成熟度判断。
下面以平凯数据库（TiDB 企业版）及其 TiDB 技术体系为例，说明相关能力与验证重点。表中的“依据”用于定位官方资料，不替代目标环境的 PoC。
| 能力 | 对应问题 | 可采用的实现方式与验证重点 | 条件与边界 | 依据 |
|---|---|---|---|---|
| 结构化事实与事务 | 订单、账户、权限和智能体状态需要正确更新 | 使用关系模型和事务保存实时业务事实；验证隔离级别、热点、连接和长尾延迟 | 数据模型与查询必须经过业务正确性评审 | 平凯数据库产品说明 |
| SQL 与 MySQL 生态 | AI 应用需要复用常见驱动、ORM 和数据工具 | 通过 MySQL 协议与 SQL 接入；逐项验证语法、数据类型、驱动和框架行为 | 协议兼容不等于应用代码无需调整 | 基本功能与企业版能力矩阵 |
| 横向扩展 | 会话、工作流和知识数据随用户增长 | 计算和存储可按架构规划扩展；记录扩容收益、均衡时间和前台抖动 | 增加节点不保证性能线性增长 | 平凯数据库产品说明 |
| 资源隔离 | 在线业务、批处理和 AI 检索可能争用资源 | 使用资源组规划不同工作负载；测试限额、突发请求和异常查询 | 隔离效果依赖拓扑、配置和真实负载 | 资源管控文档 |
| 变更数据输出 | 下游索引或数据服务需要感知业务更新 | TiCDC 可输出行级变更至数据库、Kafka 或存储服务；验证延迟、重复事件、顺序和故障追平 | 消费端需要按文档处理至少一次投递等语义 | TiCDC 简介 |
| 向量数据与检索 | 希望在 SQL 数据旁保存嵌入并做相似性查询 | 参考向量类型、函数和索引资料，使用真实语料验证召回、延迟、更新与备份 | 截至本文更新，平凯数据库功能矩阵将相关能力标为实验特性；正式项目应确认可交付范围 | 基本功能与企业版能力矩阵、向量搜索索引文档 |
同库方案可能减少复制链路，便于把业务字段过滤和语义检索组合；独立向量系统则可能在特定规模、算法或团队分工下更合适。两种方式都没有普遍适用的答案，PoC 应同时比较数据新鲜度、召回质量、查询延迟、权限一致性、备份恢复和长期运维成本。
AI 数据基础设施的典型应用场景与实践
下面列出八类常见业务场景。Dify 页面属于官网客户案例；其余链接主要是官方或社区技术实践，用来说明架构思路和验证路径，不应被表述成企业生产案例。
| 应用场景 | 主要数据需求 | 公开资料类型 |
|---|---|---|
| AI 应用开发平台 | 多租户、工作流、会话、文档与向量数据管理 | 客户案例 |
| 企业知识库问答 | 文档接入、切分、引用、权限和持续更新 | 开源项目与教程 |
| 产品文档助手 | 多版本资料检索、答案引用和反馈闭环 | 技术实践 |
| 智能客服与内部助手 | 知识召回、结构化事实查询和安全拒答 | 技术教程 |
| 智能体记忆与工具调用 | 会话状态、长期记忆、业务工具和审计 | 开发实践 |
| Java 企业应用接入 RAG | 应用框架、数据库、向量检索和模型编排 | 开发教程 |
| Graph RAG 与关系检索 | 实体、关系、语义检索和多跳问题 | 技术探索 |
| 语义搜索与推荐 | 向量召回、结构化过滤、排序和效果评估 | 技术教程 |
场景一：AI 应用开发平台
AI 平台既要保存用户、租户、权限、工作流和会话等结构化数据，也可能处理文档、嵌入向量与知识库数据。随着租户和应用数量增长，多套专用数据库会增加数据同步、资源隔离与运维复杂度。
Dify 官网客户案例介绍了其基于 TiDB Cloud Serverless 重构数据管理层的实践，把传统关系型数据、文档、向量数据和对话历史纳入统一数据体系，并面向多租户 AI 应用提供服务。该案例采用云服务形态，适合用来理解 AI 平台的数据模型与架构取舍。查看完整客户案例：Dify 基于 TiDB 的数据架构重构实践 →
这类项目应重点验证租户隔离、突发负载、会话和工作流事务、向量规模、成本模型以及数据删除是否覆盖所有副本与索引。
场景二：企业知识库问答
企业知识库需要从制度、手册、项目资料和常见问题中检索证据，再由模型组织答案。真正困难的部分通常是权限、文档版本、表格解析、引用定位和更新，而不是只把文件嵌入向量。
TiDB AutoFlow 的公开资料展示了面向企业级 RAG 的知识库方案，可作为理解文档接入、知识处理、检索和生成链路的参考。它属于开源项目和技术资料，正式建设仍需结合企业身份系统、数据密级和评测集重新设计。查看完整实践：使用 TiDB AutoFlow 构建企业级 RAG →
场景三：产品文档与技术支持助手
产品文档助手要在多个版本、模块和错误码之间定位相关内容，并把答案链接到原文。文档更新后，旧片段必须及时失效，否则系统可能引用已经废弃的参数或操作步骤。
社区公开的 TiDB 文档问答助手实践，展示了使用向量检索组织技术文档问答的实现思路。该资料适合帮助团队设计小规模原型和评测集，不代表特定规模下的生产服务指标。查看完整实践：基于 TiDB Vector 构建文档问答助手 →
场景四：智能客服与内部业务助手
客服与内部助手经常需要同时读取知识文档和实时业务事实。例如，退换货规则来自文档，而订单状态和用户权益来自业务系统。只检索静态知识库，无法可靠回答当前状态；让模型直接生成 SQL，又可能带来权限和资源风险。
DeepSeek 与 TiDB 结合构建知识库的社区教程，可作为 RAG 接入流程参考。生产系统应进一步增加参数化数据工具、字段脱敏、查询限额、敏感意图识别和人工转接机制。 查看完整实践：结合 DeepSeek 与 TiDB 构建知识库 →
场景五：智能体记忆与工具调用
智能体除了检索知识，还要保存对话、任务状态、工具执行结果和长期记忆。短期上下文、持久状态和可搜索记忆的生命周期不同，不能全部交给模型上下文管理。
Dify 与 TiDB 的 Agent 开发实践展示了应用编排、数据保存和语义检索的组合方式。团队在复用思路时，应明确哪些状态需要事务保证、哪些记忆可以删除或摘要、工具调用如何审计，以及失败后能否安全重试。查看完整实践：Dify 与 TiDB 的 Agent 应用开发 →
场景六：Java 企业应用接入 RAG
许多企业应用以 Java 和 Spring 生态为主，需要在现有身份、接口、日志和发布体系中增加 RAG，而不是另建完全孤立的演示服务。此时数据库驱动、连接池、事务边界、模型调用超时和可观测性都需要一并验证。
Spring AI 与 TiDB 的社区实践提供了 Java 应用接入 RAG 的技术示例。它可以作为原型参考，但生产实现仍需补齐权限、评测、异常降级和容量规划。查看完整实践：使用 Spring AI 与 TiDB 构建 RAG 应用 →
场景七：Graph RAG 与复杂关系检索
当问题涉及多个实体、关系和多跳推理时，只按相似度召回文本片段可能遗漏结构化关系。Graph RAG 通常把实体识别、关系构建、图查询或关系表与语义检索组合起来。
TiDB 社区关于 Graph RAG 和多模态检索的探索，可帮助团队理解关系数据、向量数据与业务元数据如何协同。由于数据建模、图构建质量和检索策略会显著影响效果，正式项目需要独立评估，不应仅凭技术样例判断可行性。查看完整实践：Graph RAG 与多模态检索探索 →
场景八：语义搜索、相似推荐与多模态检索
商品、内容、工单和图片可以通过向量表示用于相似内容搜索，再与分类、价格、时间、库存或权限等结构化条件组合。此类场景的业务目标往往是点击、解决率或转化，而不是单独追求向量查询耗时。
社区的向量索引选型文章比较了 HNSW、IVF 与 PQ 等思路，可用于设计索引实验。真实验证应固定数据集和嵌入模型，同时观察 Recall@K、P95/P99 延迟、索引构建、增量更新、内存与存储成本。查看完整实践：向量索引选型与验证方法 →
哪些情况下不必急着建设复杂的 AI 数据基础设施
以下情况可以先从更简单的方案开始：
- 只有少量公开且低频更新的资料，单一全文检索或托管知识库已经满足需求；
- 业务问题没有明确用户、答案标准或可量化价值，尚不适合投入完整平台建设；
- 数据权限、质量和负责人尚未厘清，接入越多数据只会放大风险；
- 结构化查询已经能够稳定回答问题，不需要额外引入向量检索；
- 项目仍处于短期演示阶段，生产可用性、审计与长期运营尚未进入范围；
- 团队无法持续维护评测集、数据更新和故障处置流程。
合理的起点往往是一条业务价值明确、数据边界清楚、错误风险可控的链路。验证成立后再扩展数据源、用户范围和检索方式，比一开始建设全量平台更容易判断收益。
如何从零建设 AI 数据基础设施
第一步：选择一个可验证的业务问题
明确目标用户、输入、期望输出、决策价值和错误后果。知识问答、运营助手、风险分析和代码助手对时效、权限与证据的要求不同，不宜共用模糊的“回答准确率”目标。
第二步：建立数据资产与权限清单
记录数据来源、负责人、更新频率、敏感级别、保留期限和允许使用范围。无法说明来源、授权或删除机制的数据，不应直接进入生产知识库。
第三步：设计结构化查询与知识检索边界
决定哪些事实必须通过受控 SQL 或 API 实时取得，哪些材料适合全文或向量检索，哪些敏感信息不得进入模型上下文。为每条路径定义超时、限额和降级方式。
第四步：建立小而真实的评测集
选择真实用户问题，标注正确答案、必要证据、不可回答项和权限边界。评测集应覆盖同义问法、过期内容、冲突材料、无答案问题和恶意提示。
第五步：完成端到端 PoC 与故障测试
记录数据变更到检索可见的时间，评估召回、引用、权限、延迟和成本；同时测试数据源不可用、索引落后、模型超时、重复事件和权限服务异常。
第六步：灰度上线并持续运营
先向低风险用户开放，观察拒答率、引用率、用户反馈、人工转接和单次请求成本。把错误样本回流到数据治理、检索、提示和工具设计，而不是只调整模型参数。
如何验证平凯数据库（TiDB 企业版）是否适合
建议使用真实业务数据和查询完成 PoC，并至少记录以下结果：
- 结构化负载：核心表、事务、并发和热点条件下的吞吐、P95/P99 延迟与错误率；
- 数据接入：全量导入与增量同步的时长、延迟、重复事件处理和失败恢复；
- 混合负载：在线事务、批处理、数据服务与 AI 检索同时运行时的资源干扰；
- 向量能力：在允许验证的产品形态中测试数据规模、维度、Recall@K、查询延迟和索引维护；
- 权限与隔离：跨角色、跨租户、跨部门的负向用例以及资源限额是否有效；
- 备份与恢复：结构化数据、文档、嵌入、索引和外部对象是否能按同一恢复点重建；
- 应用兼容：驱动、ORM、SQL、数据类型、连接池和错误重试行为是否符合预期；
- 交付边界：实验能力、社区能力、云服务能力与企业版可交付能力分别由谁支持。
向量检索若不属于当前企业版的正式交付范围，可以先把平凯数据库用于结构化事实、应用状态与事务数据，再通过 TiCDC、Kafka 或应用服务连接独立检索系统。这样仍能发挥分布式关系型数据库在一致性、扩展和数据服务方面的作用，同时把向量技术成熟度作为独立决策。
使用边界与风险
- RAG 不能消除幻觉：检索遗漏、材料冲突、模型误读和引用错配仍然可能发生。
- 向量化不等于脱敏或加密：向量、元数据、缓存和模型上下文都需要纳入安全治理。
- 产品形态不能混用口径：TiDB Cloud、TiDB 社区版和平凯数据库（TiDB 企业版）的功能、运维与服务范围应分别核对。
- 数据同步并非天然精确一次：下游消费应按工具文档处理重复、顺序和失败重试。
- 同库并非必然更简单：资源争用、索引构建和故障域可能抵消减少组件带来的收益。
- 技术教程不等于生产证明：社区样例用于理解实现，不应作为容量、稳定性或服务承诺。
- 真实效果依赖输入条件：模型、嵌入、数据质量、硬件、拓扑和访问模式都会改变结果。
常见问题
AI 数据基础设施和大模型平台有什么区别？
大模型平台主要提供模型训练、推理或调用能力；AI 数据基础设施负责准备、治理、检索和服务企业数据。两者共同组成智能应用链路，但故障、权限和评价指标并不相同。
AI 数据基础设施一定需要向量数据库吗？
不一定。结构化查询、全文检索或小规模内存索引可能已经足够。是否引入向量能力，应由语义检索需求、数据规模、召回目标和运营成本决定。
数据越多，回答就越好吗？
不一定。重复、过期、低质量或越权内容会干扰检索并增加风险。边界明确、可追溯且持续更新的数据集，通常比无边界堆积更有价值。
RAG 可以完全消除模型幻觉吗？
不能。RAG 能提供外部证据，但仍需评测、引用、拒答、权限控制和高风险场景的人工复核。
结构化数据为什么不全部转成文本再检索？
订单状态、库存和账户等事实持续变化，转成静态文本容易过期，也可能丢失字段类型、约束和查询语义。此类数据更适合通过受控 SQL 或 API 取得。
AI 数据平台必须实时同步所有数据吗？
不必。更新频率应由业务价值和错误风险决定。账户状态可能需要较高时效，制度文档可按发布流程更新，历史档案则可以离线处理。
把业务数据和向量放在同一数据库更好吗？
可能减少复制并简化混合查询，但也可能带来资源争用、成熟度和故障域问题。应与独立检索系统使用同一数据集和验收指标对比。
如何判断一个 AI 数据项目可以上线？
不仅要达到回答效果，还应通过权限负向测试、引用核验、数据更新与删除测试、组件故障演练、容量测试和人工处置流程评审。
延伸阅读与资料入口
总结
AI 数据基础设施的本质，是把分散的数据变成智能应用可以安全使用、能够验证并持续更新的上下文。可靠架构需要同时处理结构化事实、文档、索引、权限、服务和评估，而不是只部署一个模型或向量组件。
企业可以从一条低风险、可量化的业务链路开始，用真实问题集验证数据新鲜度、检索召回、引用、权限、延迟和成本。如果希望进一步验证平凯数据库（TiDB 企业版）在结构化数据、数据同步、混合负载和 AI 数据场景中的适配方式，可下载产品并规划 PoC。
