• 提案名称：artifact_search_projections
• 起始日期：2026-09-30
• RFC PR：oceanbase/powercontext#1803
• 迁移依赖：统一版本化数据库迁移，#1771
• 修订 RFC：0014、0051、 0080、1417
• 相关 RFC：1396、1467、 1549、1652

摘要

本 RFC 针对 OceanBase 全文与向量检索中的索引问题，为可检索的 Artifact Family 提出共同的查询边界： 全文与向量召回语句禁止使用业务表 JOIN。匹配、资格过滤、候选排序与截断不能依赖关联权威历史、head、标签等 业务表完成。

OceanBase 必须遵守这一查询边界；是否对非 OceanBase 后端同样强制执行，列为待决问题。

推荐各 Family 使用检索宽表或独立的当前检索投影。Family 可以按检索通道或主题、片段等搜索粒度拆表，无需将全部 数据合并到一张物理表。候选确定后，允许按精确引用批量读取正文及展示信息。

权威版本与 head 保留身份、历史和当前版本职责；检索投影是与权威状态同步维护、可重建的派生数据。本规范覆盖 Memory、Topic Memory、Experience 和 Skill，各制品的改造独立推进。

动机

JOIN 影响检索索引与召回结果

当前各制品已经维护部分检索投影，但搜索仍有跨表关联：

OceanBase 中，距离排序的向量扫描参与 merge join 会导致近邻丢失；全文检索与其他业务表的 JOIN 组合也会导致 全文索引路径退化。Topic Memory 已通过先截断 ANN 候选、再关联内容的方式绕过向量 merge join 问题，说明候选 选择与内容读取可以分开组织。

各 Family 需要明确的召回边界，避免正文、当前状态或标签等业务关联进入全文与向量的检索计划。

不同检索数据有不同维护成本

全文、向量和多值标签的索引方式不同；Topic 与片段的搜索粒度也不同。强制放进一张物理表，会把内容冗余、向量配置、 标签更新及索引生命周期绑定在一起。仅把字段放到同一张表，也不能保证多值标签与向量过滤可以高效组合。

宽表适合直接返回完整结果，独立投影适合按检索能力和数据粒度分别维护。公共契约应允许各 Family 选择合适的布局。

资格过滤与正文补齐需要不同边界

正文可以在候选确定后批量读取。Scope、标签、生命周期和访问资格则会影响哪些对象应当成为候选，不能在取完全局 前若干条之后才过滤。否则不合格对象会占用候选名额，符合条件的相关对象可能无法进入结果。

因此，允许分表必须同时约束候选资格、精确引用和读取一致性。

使用说明

使用宽表或独立投影

Family 可以将检索字段与返回内容放在自己的宽表中，直接返回完整结果；也可以分别维护全文、向量等当前投影， 召回时返回精确引用、命中位置和分数，再批量读取内容。

Topic Memory 可以保留主题与片段的独立搜索粒度。片段命中仍引用所属 Topic 的确切版本，保持原有的候选预算、 结果折叠及评分语义。Experience、Skill 只支持全文时，无需建立向量投影。

这些布局都由对应 Family 负责，不要求所有制品共用一张检索表。

返回完整且一致的结果

搜索接口继续返回契约承诺的正文、元数据及精确版本引用。采用独立投影时，由服务完成批量内容读取，调用方无需 逐条请求详情。补齐内容使用候选确定的版本，不能再次读取 latest 后替换候选的内容。

制品发布、停用或修改标签后，搜索基于一致的当前状态选择候选；历史引用继续按访问控制规则读取。 指定历史版本的查询不受检索投影布局影响。

保持标签过滤语义

标签管理可以继续使用独立的权威关联记录。搜索通过同步维护的标签投影，或召回前已经完整确定的有界过滤条件， 在选择候选时执行既有的全部满足、任意满足语义。

不能先随意截断符合标签的对象集合再计算相关性，也不能召回之后才关联标签筛选。没有 embedding 的部署仍保留 已有的全文搜索能力；支持哪些过滤与检索模式组合，由后端能力边界明确规定。

参考级说明

核心契约

以下查询组织与投影维护要求适用于纳入本规范的后端。非 OceanBase 后端是否纳入，见“未解决问题”；所有后端 均须保持既有的权限、过滤、当前版本和返回内容语义。

1. 召回语句不含业务 JOIN。 全文与向量候选选择不得关联权威历史、head、标签或其他业务表；相关子查询也不能 将这些关联带回召回路径。
2. 允许多张当前投影。 推荐 Family 拥有的宽表或独立投影；物理表数量、全文与向量是否共表、搜索单元粒度由 Family 和后端共同确定。
3. 资格参与候选选择。 Scope、标签、生命周期及访问控制保持既有语义，不能以截断后的过滤替代合格候选的召回。
4. 内容补齐独立执行。 候选产生后，允许通过独立的批量读取补齐内容；不得在包含全文或向量召回的同一语句中 再关联业务表。补齐阶段不重新决定候选资格、当前版本或相关性排序。
5. 当前状态一致。 权威变更与受影响投影原子更新；同一次搜索的各召回通道和内容补齐共享一致的已提交状态。
6. 历史与预算保持。 重建不改变权威身份、历史内容、精确引用或 Source 处理位置。候选、过滤条件传递、内容 补齐和融合遵守预算，不使用逐命中查询或无界对象清单连接各阶段。

职责与适用范围

pc_artifacts 与 pc_artifact_heads 保留现有职责。当前性由 Family 写入时维护的投影保证，召回不再 JOIN head 判断最新版本。候选必须携带足以确定原文及命中位置的精确身份。

内容补齐可以读取对应的当前内容投影，也可以读取权威的精确版本记录。它不能静默采用其他版本、遗漏缺失内容， 或把不一致解释为空结果。返回给用户的内容与评分所依据的候选必须对应。

标签及其他资格信息的独立变化也要同步反映到所有受影响投影；不要求所有元数据变化都生成内容 revision。 当前的 Scope 级授权可以在进入搜索前完成，无需因存储改造改变授权模型。

适用本规范的后端可以使用原生索引或辅助索引表达检索能力。数据库内部的索引访问不属于本 RFC 禁止的业务表 JOIN； 应用查询仍需遵守召回与内容读取的边界。统一规范允许各后端保留不同的 DDL 和索引实现。

本 RFC 覆盖现有及新增的可检索 Family，只定义公共检索规范。各制品的改造分别设计、独立推进，不要求同时完成。 内容生成、证据含义和语义合并由各自领域契约定义，公开的返回内容、过滤和评分契约继续保持。

升级与兼容

数据库结构变更和检索投影重建遵守 RFC #1771：统一版本化数据库迁移， 通过其统一维护入口完成停服升级。

检索投影从权威数据重建，不生成新的内容 revision，不重新抽取已经处理的 Source。已有精确引用与访问控制保留， 历史正文读取不依赖历史向量。

缺点

• 增加投影维护成本。 宽表可能重复保存正文；分离投影仍需重复保存部分过滤属性，并同步维护多份当前状态。
• 增加读取协调。 批量补齐多一次内容读取，需要保证它与召回使用相同的版本及一致状态。
• 索引组合仍有边界。 多值标签与向量检索的组合能力取决于后端，移除 JOIN 不会消除其过滤和扫描成本。
• 升级需要停服。 投影迁移与索引重建需要额外空间和维护窗口，也不会消除权威历史本身的增长。

设计理由与替代方案

约束召回，允许选择投影布局

宽表可减少结果补齐和副本协调，适合返回字段与检索单元较为一致的 Family。独立投影可以分别维护全文、向量及 主题、片段，减少大字段复制并独立管理索引。本提案推荐两种方式，统一其查询边界和一致性责任。

强制每个 Family 只有一张宽表

可以简化直接返回结果的路径，但会限制不同搜索粒度、向量配置和后端索引的独立演进。它也不能替代多值标签的索引 设计，因此不作为所有 Family 必须遵守的物理要求。

在 OceanBase 召回中保留业务关联

能减少部分数据冗余，但会继续带来 OceanBase 向量近邻丢失及全文索引路径退化。将关联写成相关子查询，或者在同一 召回语句外层补内容，仍将业务表与检索计划组合在一起。独立批量内容读取可以明确隔开这两个阶段。

先例

RFC 1417 的 Topic/Chunk 当前投影、分通道召回与原子发布，为独立投影提供基础。 RFC 0051 定义 Experience/Skill 内容与准入； RFC 1467 和 RFC 1396 定义需要保留的标签与授权语义。

未解决问题

1. 确定 OceanBase 最低支持版本。
2. 非 OceanBase 是否也必须遵循本规范。

第二项有以下两种方案，适用范围尚待确定：

SQLite 和 seekDB 当前主要用于嵌入式、本地场景，预期数据规模较小。基于这一使用定位，倾向于优先采用统一检索 设计、减少维护分支；是否对所有后端强制执行仍待确定。

统一遵守规范不要求各后端使用完全相同的 DDL 和索引；不强制遵守的后端也可以主动复用同一套模型与检索实现。

如果不同后端采用不同存储模型，如何通过统一业务模型和存储适配隔离差异，作为遗留问题单独讨论。本提案不设计 这套架构，也不将其建设作为索引改造的前置条件。

后续可能性

可以在各 Family 的检索结果之上提供统一搜索，例如一次搜索同时返回 Memory、Experience 和 Skill，再合并排序。 这需要另外确定不同制品之间的评分和排序规则，不作为本提案的交付要求。