数据库模型

AI 技术栈在哪里以什么样的结构存放数据的梳理文档。存储共有四个，各自职责不同。运维流程请参见数据库管理。

大部分并非 AI 独自拥有

PostgreSQL·Aster TSDB 是 PlantPulse Platform 安装实例共用的。AI 技术栈不会自行启动自己的 DB。因此「AI 备份」与「Platform 备份」会有重叠 — 若不先理清哪一方负责备份什么，就会出现两边都漏掉的区间。

存储	所有者	存放内容
PostgreSQL `pi` · 模式 `co`	AI（Platform PG 内的独立 DB）	对话·事件·设置·MCP（Copilot）
PostgreSQL `pi` · 模式 `dt`	AI（同上）	外部系统连接器注册表·绑定·行为记录（数字线程）
PostgreSQL `lightrag`	AI（同上）	LightRAG 的文档处理状态（`PGDocStatusStorage`）
PostgreSQL `rag_ingest`	AI（同上）	文档采集管道（rag-api）的状态 — 见下文「PostgreSQL rag_ingest」
PostgreSQL `litellm`	AI（同上）	LiteLLM 网关的密钥·使用量
Aster TSDB `pi`	AI	特征存储·异常检测产出物
Aster TSDB `pp`	Platform（只读）	原始传感器·报警·OEE
Neo4j `plantpulse-neo4j`	AI	LightRAG 知识图谱
Neo4j `plantpulse-digital-thread-neo4j`	AI	数字线程的工厂图谱镜像 — 仅供参照
Qdrant	AI	文档嵌入向量
`lightrag-storage` 卷	AI	LightRAG 的 KV 缓存 — 本地 JSON 文件
`lightrag-inputs` 卷	AI	上传的原始文档

Platform PG 内有«四个» AI 的 DB

AI 不会启动自己的 PostgreSQL，而是使用Platform 的 PostgreSQL。在其中创建 pi · lightrag · rag_ingest · litellm 四个 DB（由 provision-platform-db.sh 以幂等方式创建）使用。pi 是 AI 各应用共用的 DB，每个应用拥有一个模式（co Copilot · dt 数字线程）。2026.09 及以下版本的 DB ch 在启动时会迁移至 pi.co → 数据库管理 Aster TSDB · Valkey · RustFS · MQTT 代理（订阅设备报警）同样是挂载使用 Platform 的资源 — 核算 AI 服务器规模时，不要把这四项单独计入。

PostgreSQL `pi.co` — 对话与运行状态

Platform PostgreSQL 内独立数据库 pi 的模式 co （jdbc:postgresql://<platform-host>:5432/pi?currentSchema=co）。Copilot 仅连接这一个模式，因此未指定模式的表名全部归属于 co。

与 2026.09 及以下版本的 ch 是同一批表

以前位于 DB ch 的 public 中的表。名称和结构不变，只是位置迁移到了 pi.co。

分组	表
对话	`chats` · `chat_messages` · `prompts` · `prompt_history` — `chats.context` 是固定在对话中的上下文（2026.10 版重新发布）
聊天行为 · 回答质量（2026.10 版重新发布）	`chat_action`（聊天回答中携带的草拟建议一条 = 一行 — 谁·何时·为何批准）· `chat_turn_metric`（每个回答轮次的延迟·token·模型·引用数·依据类型·👍👎，以及结果标记 `outcome` — 为空表示正常回答，`no_answer` 表示重试后仍为空回答，`loop_cut` 表示中断了循环）· `chat_bench_run`（基准测试轮次得分）
用户	`users` · `user_roles` · `employees` · `web_push_subscription` — `employees.work_role` 是管理员设定的业务角色（审批权限），`employees.home_role` 是旧界面中用户自选的起始画面（2026.10 版重新发布 3 — 新界面已不再使用）→ 业务角色
事件（表名保持 `incident` 原样）	`incident` · `incident_event` · `assignees`
Watch（条件监视 — 已废弃的功能）	`watch` · `watch_run`。自界面替换版本起不再新建也不再使用。旧安装中存在的表会原样保留
异常检测运行	`anomaly_mute` · `hourly_anomaly` · `asset_tag_profile`
MCP · 工具	`agent_tool_call_log` — 若是经人工批准的操作，审批人会记录在 `approved_by` 中。旧表 `mcp_server` · `mcp_tool_pref` · `mcp_tool_call_log` 会在 2026.10 再发布（2026-10-20）中由启动过程删除 —— 服务器 · 启用/关闭 · 调用记录的正本是 MCP 网关 DB（`pi` 的 `gw` 模式）
公开 API	`api_key`
设置	`config` · `config_audit_log` · `metadata`

新表 · 新字段会在启动时自动生成

上述「2026.10 版重新发布」的表与字段，会在 Copilot 启动时通过 CREATE TABLE IF NOT EXISTS · ADD COLUMN IF NOT EXISTS 自动创建。不需要手动执行迁移（migration）。 chat_turn_metric 中不含问题·回答原文（原文在 chat_messages 中），chat_action 中不含语音·回答正文 — 只有工具参数和结果编号。

工具调用台账 agent_tool_call_log

AI 调用的工具无一遗漏全部记录于此 — 时间·用户·会话·工具名称· 来源 MCP 服务器·参数（敏感值用 *** 遮蔽）·结果（ok · error · denied）·耗时。 denied 是被审批关卡拦截的变更类工具调用 → MCP mcp_tool_call_log 只包含按注册 MCP 服务器统计的成功率·耗时数据，「谁做了什么」请查看此表。

公开 API 密钥 api_key

密钥不会以明文存储 — 仅保存哈希值（key_hash）与用于识别的前几位字符（key_prefix）。即使作废也不会删除该行，而是标记 revoked_at。若 last_used_at 为空则说明该密钥未被使用 → Copilot 管理控制台

聊天历史的权威来源只有这一处

2026-07 改版之前，Aster TSDB 中也保存有对话历史。现在是唯一来源 chat_messages。请不要按旧文档去 Aster TSDB 中查找。

PostgreSQL `pi.dt` — 数字线程注册表

数字线程 API 所拥有的模式。表由服务启动时创建。所有语句都限定在 dt. 范围内，不会触及其他模式。

分组	表
连接器	`dt_connector` · `dt_connector_tool`
绑定	`dt_binding` · `dt_binding_log`（运维人员设定的字段绑定及其变更记录 — 谁·何时·变更前后）
行为记录	`dt_action_log`（经审批后发送至外部系统的草稿·请求）
Episode	`dt_episode` · `dt_episode_label`
同一性声明	`dt_identity` · `dt_identity_log`（「在此现场中键 A 与键 B 为同一对象」这一运维人员声明及其变更记录 — 不会自动关联）

连接器凭据没有加密密钥无法解密

dt_connector 中的凭据是用 PI_DT_SECRET_KEY 密封存储的。若丢失该密钥，即使恢复数据库，存储的凭据也无法使用，必须为每个连接器重新录入。备份主机 env 文件时请一并保存 → 数字线程

PostgreSQL rag_ingest — 文档采集状态

rag-api 所拥有的 DB。表由 rag-api 启动时创建（幂等）。

分组	表	何时生成
同步	`rag_asset_doc_sync` · `rag_sync_run` · `rag_asset_card`	始终
图纸	`rag_drawing_doc` · `rag_drawing_chunk` · `rag_drawing_ident` · `rag_drawing_dim` · `rag_drawing_kg` · `rag_drawing_outbox`	仅当 `DRAWING_INGEST_ENABLED=true` 时
视频 · 音频	`rag_media_job` · `rag_media_segment` · `rag_media_sidecar`	仅在开启视频·音频的安装（`PI_MEDIA_ENABLED=true` — 在 rag-api 内部称为 `MEDIA_INGEST_ENABLED=true`）中

rag_drawing_doc.source 记录图纸的来源 — 从管理控制台上传的（MANUAL），以及从 Platform 资产文档同步导入的（PLATFORM，2026.10 版重新发布 3）。后者以 Platform 为权威来源，因此不会在控制台中被覆盖或删除。
rag_drawing_dim 存放每行尺寸的上·下限（upper_limit · lower_limit）及其依据（limits_basis — 是图纸上标注的值，还是通过配合公式计算得出的«公式推算»值）。
rag_media_job 中一条视频·音频文件 = 一行（来源 source · 处理状态 · 重试次数 · 缩略图数量等）。管理控制台的 RAG › 索引 › 视频画面会展示该内容 → 视频 · 音频搜索

图纸原件的结构·预览图与视频文字记录不以表形式存放，而是放在对象存储桶 plantpulse-rag 中 → 数据库管理

Aster TSDB `pi` — 特征存储

时序洞察服务所拥有并创建的 12 个表。前缀为 tsi_。

分组	表
特征	`tsi_tag_feature_hourly` · `tsi_tag_feature_daily` · `tsi_asset_feature_hourly` · `tsi_asset_feature_daily`
上下文·档案	`tsi_asset_context_daily` · `tsi_asset_profile`
异常·故障	`tsi_anomaly_embedding` · `tsi_failure_signature` · `tsi_precursor_alert`
管道	`tsi_pipeline_status` · `tsi_pipeline_history` · `tsi_backfill_status`

表由服务在启动时幂等创建。但键空间 pi 本身并非由应用创建 — 而是归属于安装脚本（provision-platform-db.sh）。

特征为空时分析界面整体会显示为空

管理控制台的异常检测·预测界面全部读取这些表。若结果为空，请先检查管道而非模型 → 管理控制台的 Pipeline Status Run History（AI 管理控制台）。

Copilot 的表也位于同一键空间

Copilot 也会在 pi 中存放自己的表（晨间简报卡片等）。2026.10 版重新发布中新增了存放结构化报告处置勾选状态的 PI_NAVIGATOR_ACTION_CHECK，由 Copilot 在启动时创建。

旧版 pp.ti_* 已不存在

2026-07-30 已从 pp 键空间迁移到 pi，旧表已被 DROP。用旧名称查询将不会得到结果。

Aster TSDB `pp` — Platform 原始数据（只读）

AI 仅读取 Platform 采集的数据。不会向此处写入。

表	用途
`tm_asset_data_based_second` / `_minute` / `_hour`	设备传感器时序数据
`tm_tag_point`	标签点位
`tm_asset_alarm`	报警
`tm_kpi_oee_history`	OEE
`tm_kpi_ram_history` · `tm_kpi_ems_history`	RAM · EMS
`tm_monitor_platform_status`	系统资源（CPU·内存·磁盘）

分区键按分辨率不同而不同

second : PRIMARY KEY ((asset_id, date, hour), timestamp)
minute : PRIMARY KEY ((asset_id, date), timestamp)
hour   : PRIMARY KEY (asset_id, timestamp)
kpi    : PRIMARY KEY ((asset_id, day), timestamp)   -- tm_kpi_*_history

KPI 历史（tm_kpi_*_history）中的 day 是 UTC 日期（yyyymmdd）。本地一天会跨越两个 UTC 分桶，因此需将时间段展开为 UTC 日期列表，逐个分桶读取。单行记录的是截至该时刻的订单累计值，因此不能对行求和。 详细规则见 KPI 表。

若查询速度慢，先检查分辨率

秒级数据的分区键会细化到设备·日期·时刻。若以秒级粒度扫描较长时段，会触及数千个分区。较长时段请用 _hour，仅较短时段再用 _second 查看。

Platform 一侧的完整模式见 Platform 数据库模型。

Neo4j · Qdrant — 知识图谱与向量

存储	存放内容
Neo4j（`plantpulse-neo4j`）	LightRAG 的知识图谱 — 从文档中提取的实体·关系
Qdrant	文档分块的嵌入向量

数字线程的工厂图谱镜像位于另一个 Neo4j 实例（plantpulse-digital-thread-neo4j）中。并非 LightRAG 的存储，因此不计入下文的「四个」之中。

RAG 引擎（LightRAG）的存储分为四处。 若只了解其中两个，恢复时就会出错。

内容	位置	配置
向量	Qdrant	`LIGHTRAG_VECTOR_STORAGE=QdrantVectorDBStorage`
图谱	Neo4j	`LIGHTRAG_GRAPH_STORAGE=Neo4JStorage`
KV 缓存	`lightrag-storage` 卷中的本地 JSON	`LIGHTRAG_KV_STORAGE` 未配置 — LightRAG 默认值（`JsonKVStorage`）
文档处理状态	Platform PG 的 `lightrag` DB	`LIGHTRAG_DOC_STATUS_STORAGE=PGDocStatusStorage`

KV 为本地 JSON 是有意为之的设计 — 对单台实例而言已足够，也无需依赖 Platform 的 Valkey。扩展到多台时，需切换为 LIGHTRAG_KV_STORAGE=RedisKVStorage + REDIS_URI。

若对四处«各自」恢复，索引会出现错位

只有文档处理状态保存在 PostgreSQL 中。若只恢复 PG 而 Qdrant·Neo4j 为空， LightRAG 会认为该文档「已经导入过」而不再重新导入 — 搜索会持续空手而归。反之，若只恢复图谱·向量，状态不一致也会导致重复导入。

还原时请将四处对齐到同一时间点，或将四处全部清空后从原始文件重新导入。 原始文件保存在 lightrag-inputs 卷中 — 此卷实际上就是备份的核心，若连这个也丢失，就没有办法重新生成索引。

本体概念请参见理解本体。

备份范围梳理

存储	由谁负责备份	若缺失则
PostgreSQL `pi`（`co` · `dt`）	需由 AI 方负责	对话·事件·设置、连接器注册表会丢失
PostgreSQL `lightrag` · `rag_ingest`	需由 AI 方负责	文档处理状态会丢失 — 参见上文 danger 提示
PostgreSQL `litellm`	AI	网关密钥·使用量历史会丢失
Aster TSDB `pi`	需由 AI 方负责	特征数据丢失导致分析界面显示为空（可重新计算，但耗时较长）
Aster TSDB `pp`	Platform 备份	—
Neo4j · Qdrant	AI	文档索引会丢失（可从原始文件重新生成）
数字线程 Neo4j	AI（`bin/backup.sh` 整卷备份）	镜像会丢失（可从源头重建）
`lightrag-storage` 卷	AI	KV 缓存会丢失（可重新生成）
`lightrag-inputs` 卷	AI — 最为重要	原始文档会丢失，索引将无法重新生成

操作流程请参见数据库管理。

PostgreSQL pi.co — 对话与运行状态​

PostgreSQL pi.dt — 数字线程注册表​

PostgreSQL rag_ingest — 文档采集状态​

Aster TSDB pi — 特征存储​

Aster TSDB pp — Platform 原始数据（只读）​

分区键按分辨率不同而不同​

Neo4j · Qdrant — 知识图谱与向量​

备份范围梳理​

相关文档​