SVO 3.2 语义检索的系统化方案

零、一句话概述

把 SVO 3.2 表达式分解成"概念簇 / 动作命题 / 情境逻辑命题"三类语义原子,——所有作用域关系通过 : 绑定或 PropRef 引用表达——对每类原子建最合适的索引,检索时多路召回 + 逻辑过滤 + 结构哈希匹配 + 学习排序,最后沿嵌套引用链聚合成完整语义单元返回。

核心设计哲学:语义是连续的,交给向量;结构是离散的,交给索引。两者解耦,各尽其职。

相对于 3.0/3.1 方案的根本调整:SVO 3.2 取消了 >> 算子,把原本混在"情境"里的两类东西——非命题性作用域(话题/身份/范围/句子级副词)与命题性推导(条件/让步/因果/推论)——彻底分开。前者归入 :(属性),后者归入 >(力)。检索系统必须同步这个切分,否则会在相同的"情境"标签下混入本质不同的两类语义,引入噪声。

一、第一性原理:定义"语义相关"

脱离对"相关"的精确定义去谈检索,必然做出一锅粥式的系统。SVO 检索应该服务的相关性是分层的,不同层级需要不同的索引手段。

层级	名称	含义	示例	索引手段
L1	概念相关	词项语义相似	查"汽车"召回"轿车""SUV"	概念簇向量
L2	命题相关	~~三元组~~主谓宾整体相似,角色对齐	查"~~Karpathy~~K 表示 AGI 还远"召回同义改写	命题向量 + 倒排
L3	情境作用域相关	~~作用域~~ 话题/ 前提身份/范围属性匹配	查"低资源场景下的模型压缩"	~~情境向量~~作用域属性索引
L4	推导相关	条件/让步/因果链的前件或后件匹配	查"如果模型开源会怎样"命中条件链的前件	逻辑命题索引
L5	蕴含相关	逻辑等价与否定/量词/模态的正确区分	"所有学生通过" ≡ "没有学生没通过"	逻辑过滤规则
L5L6	结构类比	骨架相同、实体不同	"A 促使 B 认识到 C" 类比检索	结构指纹哈希

与 3.0 方案的差别:原 L3"情境相关"被拆为 L3 作用域相关 与 L4 推导相关。这不是术语更名——两者的索引手段、查询方式、学习排序特征都不同。混在一起的代价是"和平时期的军队训练"与"如果和平就训练军队"会走同一个召回通道,而它们在逻辑上完全不是一回事。

关键洞察:SVO 3.2 的算子设计精简(三算子二元本体)天然支持对应这五六层分解——: 负责 L1/L3,> 负责 L2/L4/L6,逻辑过滤器覆盖 L5。每一层都有明确的算子责任人。

二、语义原子化:入库时的分解

一条 SVO 3.2 表达式入库时,不作为整体被索引,而是分解成三类独立可检索的原子,通过 ID 保留原始关系。

2.1 三类原子(3.2 版)

① 概念簇 (Concept):

由 : 链坍缩出的~~名词性~~复合单位,代表实体~~或抽象~~、概念或作用域属性。

例实体型:(OpenAI:创始:元老):Karpathy、

概念型:(协作式:中间态)
作用域型:(AI:辅助:编程:方面)、(前:负责人)

句子级修饰型:显然、(不幸:的是)

与 3.0 的差别:3.0 里"作用域型"不存在——它当时叫"情境",走 >> 通道,是独立原子类别。3.2 把它收编为概念簇的一个子类,用元数据字段 role 标记(entity / concept / scope / sentence_mod)。

② 动作命题 (Action Proposition):

主体施事 > 动作词 > 受事 三元组~~,SVO~~。> 的~~陈述性最小单位~~两端都是词项或概念簇(而非完整命题)。

~~嵌套宾语~~示例:Karpathy →> 独立成记录,用表示 > [PropRef]、PropRef论文 > 促使 > Tishby 引用

& / | ~~→ 在这一层展开成多个命题~~

~~支持多个命题嵌套组合~~

情境③ 逻辑命题 (~~Context)~~Logical Proposition):>> ~~左侧的内容,本身也是命题或概念簇,作为其辖域内所有命题的"作用域标签"。~~

2.2 分解示例

~~原始表达式:~~

(前:负责人件):Karpathy >> 今天:表示逻辑连词 > (后件) 结构。> 的两端都是封装的完整命题。连词为 则 / 尽管 / 导致 / 因此 / 促使 / 以便 等有限集合。

示例:(该计划 > 不:公开) > 则 > (该计划 > 无法:获得 > 认可)

与 3.0 的差别:3.0 把条件句放在"情境"分类下(条件 >> 结果),与"话题/身份"混在一起。3.2 清晰识别出这是命题间的力流动——和致使模型(原因 > 促使 > X)同构,因此自然归入"命题"大类,只是子类型不同。

2.2 原子间的三种引用关系(PropRef 机制扩展)

3.2 中 PropRef 不再只表达"言说嵌套",而是统一表达三种命题级引用。每种引用类型必须独立记录,以便反向遍历。

引用类型	源字段	指向	典型 SVO 形式	检索用途
言说引用(`ref:utterance`)	动作命题的宾语槽	另一个命题	`K > 表示 > (P)`	区分"事实"和"对事实的陈述"
修饰引用(`ref:modifier`)	作用域概念的修饰对象	一个命题	`显然 : (P)`、`(AI:方面) : (P)`	区分"在 X 下成立的 Q"与"关于 X 的 Q"
推导引用 (`ref:logical`)	逻辑命题的前件/后件槽	两个命题	`(P1) > 则 > (P2)`	条件/让步/因果检索

这是 3.2 相对 3.0 方案在数据模型上的最大变化。3.0 的"情境 ID 列表"把作用域关系和逻辑推导关系合并成了一个多对一的普通外键,导致反向查询时无法区分"Q 发生在 P 这个场景下"和"P 导致 Q"。3.2 把这两种关系用不同的 ref_type 分开,逻辑过滤层才能对条件链做精准处理。

2.3 分解示例(3.2 版)

原始 3.2 表达式:

(前:负责人) : Karpathy > ((今天 & 明确 & (向:团队)) : 表示) > ((该计划 > 不:公开) > 则 > (该计划 > (无法:获得) > 认可))

分解结果:

概念簇:
  C1 = (前:负责人):                    role=scope
  C2 = Karpathy                      C2role=entity
  C3 = 今天                           role=scope  (时间状语)
  C4 = 明确                           role=scope  (方式状语)
  C5 = (向:团队)                      role=scope  (对象状语)
  C6 = 该计划                          C3role=entity
  C7 = 认可                            role=concept

动作命题:
  P1: Karpathy[C2] > 表示 > [PropRef:P2]PropRef→L1]
      状语谓词修饰: 今天[C3, 情境C4, C5] (通过 ref:modifier 指向 P1)
      实体修饰: C1 修饰 C2 (身份=前负责人通过 ref:modifier,绑定到 P1 的 subject 槽)
  P2: 该计划C6 > 不:公开
      (这里的"不"作为极性标记记在 P2 的 polarity 字段)
  P3: C6 > 无法:获得 > 认可C7
      情境:(这里的"无法"作为模态标记记在 P3 P3:的 该计划modality 字段)

逻辑命题:
  L1: [P2] > 不公开则 > [P3]
      connector = 则
      (作为P2、P3 P2通过 ref:logical 被 L1 引用)

根节点:
  P1 是表达式的情境)入口,整句被 P1 索引

~~三类原子各自独立入库~~对比 3.0 方案:3.0 会把 P2 登记为 P3 的"情境",通过两者关系存在 IDP3 的 context_ids 字段里。这样做的问题是——L1 的"则"连词丢失了,检索时无法区分"该计划不公开(P2)是该计划无法获得认可(P3)的前提"和"假如该计划不公开就无法获得认可"。3.2 把连词保留~~嵌套关系。~~在 L1 记录里,这~~一步是整套方案的根基~~~~——没有分解就没有分层索引,没有分层索引就没有精准检索~~条信息不再丢失。

三、三四层索引架构

3.0 是三层索引(A 概念、B 命题、C 情境)。3.2 因为"情境"被拆分,索引变为四层:

3.1 索引 A:概念向量索引(服务 L1)

作用:存储所有概念簇的向量,支持"找语义相近的概念"。

与 3.0 的差别:由于作用域概念((前:负责人)、(AI:方面))现在也是概念簇的一员,索引 A 的范围扩大了。作用域概念在向量空间里需要与实体、普通概念区分开——查询"Karpathy"不应该召回一堆"前负责人"类的作用域概念,否则会污染 L1 召回池。

解法:概念簇入库时按 role 字段(entity / concept / scope / sentence_mod)路由到不同的子索引。查询时按查询词类型选择召回的子索引集合:

查询实体 → 召回 entity + concept 子索引

查询场景 → 召回 scope 子索引

查询谓词修饰语 → 召回 sentence_mod 子索引

编码策略(分两阶段演进):

阶段一:加性组合(零训练~~,先上线~~)

v(concept) = v(核心词) + Σ α_i · v(修饰词_i)

其中 α_i 按绑定深度衰减(如 0.8^depth)。

~~优点:零成本、支持部分匹配(查~~ Karpathy ~~能召回~~ (前:CEO):Karpathy)

~~缺点:丢失修饰链顺序~~

阶段二:小型 Transformer + 绑定深度位置编码~~(有真实日志后升级)~~

线性化为 [CLS] 修饰1 : 修饰2 : ... : 核心词 [SEP]
加绑定深度作为位置编码,让模型区分~~核心与修饰~~层级
CLS 池化输出向量

按

~~重要工程决策:分类型编码~~~~。实体型核心词(Karpathy)和概念型核心词(中间态)追求的向量分布本质不同——前者要"身份保持",后者要"语义平滑"。用两~~role 字段训练四个 LoRA 适配器~~分别编码~~,不要强行统一。

编码空间

训练数据(四类对比对):

同指正例:同实体不同描述(从 Wikidata 实体对齐~~中自动构造~~)
属性敏感正例:同实体不同属性强调点
混淆负例:同属性不同实体核心词(~~故意采样共享修饰词,~~强迫模型关注核心词)
属性翻转负例:(前:CEO):X vs (现任:CEO):X

(防止3.2 新增)role 混淆负例:(AI:方面) vs AI(强迫模型~~忽略时间状语)~~识别"方面"这个尾缀改变了 role)

~~每类几万条,LoRA 微调 BGE-base 即可。~~

3.2 索引 B:动作命题索引(服务 L2、L4、L5)L6)

动作命题是检索的核心单位,同时建三套互补索引:

B1. 倒排索引(精确角色查询)

按施事、动作词、受事分别建倒排表
支持 SPARQL 风格的硬过滤:"找所有施事=Karpathy 的动作命题"
~~工程极廉价,用~~ 引擎:Elasticsearch 即可

B2. 结构指纹哈希(L5L6 结构类比)

每个动作命题生成结构指纹,~~也做 L2 的快速过滤)~~包含:

~~每个命题生成一个~~槽位数与槽位类型序列

极性字段(是否含 不)

模态字段(是否含 可能/必须)

量词字段(所有/某/没有/无)

嵌套深度(宾语是否为 PropRef)

与 3.0 的差别:3.0 的结构指纹把"是否在情境下"作为一个布尔位。3.2 拆为两个独立字段:~~槽位数、~~是否被 ref:modifier 引用(作用域修饰)与 是否被 ref:logical 引用(作为条件链的一端)。这个拆分让结构类~~型序列、算子序列、嵌套深度~~比更精确——"A

~~真实语料里~~促使 ~~80%~~B" ~~的命题只用~~不会再和"如果 20A ~~种左右的骨架,指纹空间呈幂律分布~~

则

~~用离散~~B"撞哈希~~倒排:~~hash(骨架) → [命题 ID 列表]~~,O(1) 查找~~

建~~骨架 lattice~~~~(子图格),记录骨架间的父子关系(去掉/增加槽位),支持"结构相近"的扩展查询~~

。

B3. 槽位向量索引(L2 语义模糊匹配)

每个槽位填入对应概念簇的向量(复用索引 A)
按槽位位置拼接或加位置编码后聚合

,绝对不能简单平均~~——否则"猫吃鱼"和"鱼吃猫"就成了一回事~~
极性、模态、量词、连接词(对逻辑命题)作为额外特征位拼接

~~三套索引的分工~~:

~~B1 给精确查询用(用户明确知道要找什么)~~

~~B2 做快速过滤和结构类比(把候选池从百万缩到几百)~~

~~B3 做语义模糊匹配和精排~~

3.3 索引 C:情境逻辑命题索引(服务 L4,3.2 新增)

这是 3.2 方案中唯一一个在 3.0 里不存在的索引。它的存在是 >> 消除、条件归入 > 之后的必然产物。

数据结构:每条逻辑命题记录包含

antecedent_ref → 前件命题 ID

connector → 连词原子词(则/尽管/导致/因此/促使/以便)

consequent_ref → 后件命题 ID

antecedent_vec / consequent_vec → 两端的复用向量

支持的查询模式:

前件查询:"如果模型开源会怎样?" → 找所有前件 ≈ "模型开源" 的逻辑命题,返回其后件

后件查询:"什么情况下项目会失败?" → 找所有后件 ≈ "项目失败" 的逻辑命题,返回其前件

连词过滤:"尽管…但是…" 型逻辑 vs "如果…就…" 型逻辑,通过 connector 字段硬过滤

因果链追踪:沿 antecedent_ref 链式遍历,找出"P → Q → R"的推导链(3.0 无法做)

工程实现:Postgres 关系表 + Qdrant 两份前件/后件向量索引。查询时按 connector 过滤后再做向量召回。

3.4 索引 D:作用域修饰索引(服务 L3)

每
作用:快速回答"在某个~~情境独立编码一个向量~~作用域(~~复用 B3~~ 话题/身份/范围)下的~~编码器)~~

~~每个命题记录挂一个"所属情境 ID 列表"~~

~~检索时:场景词编码后查情境索引 → 顺 ID 反查该情境下~~所有命题"。

数据结构:一张多对多关系表

proposition_id → 被修饰的命题

scope_concept_id → 作为作用域的概念簇 ID

modifier_type → topic / identity / sentence_adverb / scope_range

为什么独立于 PropRef 表:虽然 ref:modifier 已经在 PropRef 表里,但作用域修饰查询频率极高,且经常需要按 modifier_type 过滤。为查询效率,单独物化成一张表(其实是 PropRef 表的视图索引)。

查询流程:

查询词("AI 领域") → 索引 A 召回相关的 scope 概念

拿概念 ID → 查询索引 D,反查所有被这些概念修饰的命题

返回命题列表,进入精排

与 3.0 情境索引~~单独存在~~的意义对比:~~同样的核心~~

方面	3.0 情境索引	3.2 作用域修饰索引
索引对象	情境(可能是命题~~在不同~~或短语)	只限作用域概念簇
条件句处理	条件作为情境进入此索引	条件被剔除,归索引 C
语义纯度	混杂	纯"限定关系"
反向查询	一个 context_id 字段	按 modifier_type 精细过滤

这样分工后,索引 D 的查询结果更纯净——返回的都是"在此作用域下~~意义可能完全相反(~~和平时期 >> 军队 > 训练 vs 战时 >> 军队 > 训练~~)。把情境作~~成立的命题",而不会混入"以此为~~独立检索维度,给它单独~~条件推出的~~权重,是 SVO 相比纯文本检索的关键优势~~命题"。

四、嵌套命题:PropRef 机制

~~错误做法~~~~:把嵌套树展平成超长向量。这会导致维度爆炸,且内层命题无法独立检索。~~

~~正确做法~~~~:嵌套命题入库时~~~~拆成独立记录~~~~,外层命题的宾语槽填~~ [PropRef:内层命题ID] ~~占位符。~~

~~这带来了 SVO 检索独有的能力——~~~~双向遍历~~:

~~由外向内(查言说)~~~~:"Karpathy 表示了什么?" → 匹配外层命题 → 顺 PropRef 跳到内层 → 返回内层作为上下文。~~

~~由内向外(查事实出处)~~~~:"AGI 还需要多久?" → 命中内层命题 → 反向追溯哪些外层命题引用它 → 返回"谁在什么场合说的"。~~

~~这是 SVO 相比纯向量检索最独特的价值~~:它能区分"事实"和"对事实的陈述"。普通向量检索把这两层压成一锅粥;SVO 的嵌套结构让它们天然可分离。在学术文献、新闻事实核查、法律判例检索等场景中,这个能力价值巨大。

五、完整检索流程(3.2 版)

           用户查询 (自然语言或 SVO 3.2 表达式)
                      │
                      ▼
           ┌──── 步骤 1: 查询分解析 ────┐
           │ 解析成同构 SVO 3.2 树    │
           │ 拆成 概念簇/动作命题/情境  │
           │      逻辑命题        │
           │ 标记必须项 vs 软需求 │
           └──────────────┬───────────┘
                      │
      ┌─────────┬───────┼┴──────┬──────────┐
      ▼         ▼           ▼          ▼
  ┌─────────┐ ┌───────┐  ┌───────┐  ┌─────────┐
  │ 索引 A │ │ 索引 B │  │ 索引 C │  │索引 概念向量│      │ 倒排+哈希│     │ 情境向量│D │
  │概念   │ +槽位│动作   │  │逻辑   │  │作用域 │
  │向量   │ │命题   │  │命题   │  │修饰   │
  └───┬───┘ └───┬───┘  └───┬───┘  └───┬───┘
      │         │          │          │
      └────┬────┘      └┴─────┬────┘     └────┬────┘
        │                 │                │
        └────────┬────────┴────────────────┘
           ▼
  ┌─ 步骤 2: 多路召回并集 ──┐
  │  候选命题池 (百~千条)    │
  └──────────┬───────────────┘
             ▼
  ┌─ 步骤 3: 逻辑过滤 ─────┐
  │ • 极性检查(肯定/否定)      │
  │ • 量词检查(全称/存在)      │
  │ • 模态检查(必须/可能)      │
  │ • 情境作用域覆盖检查           │
  │ • 连词一致性 (3.2 新)  │
  └──────────┬─────────────┘
             ▼
  ┌─ 步骤 4: 命题级精排 ───┐
  │ 学习排序融合五六维特征:  │
  │ • 概念相似度           │
  │ • 动作命题相似度       │
  │ • 情境逻辑命题相似度       │
  │ • 作用域覆盖度         │
  │ • 倒排命中数           │
  │ • 逻辑约束满足度       │
  └──────────┬─────────────┘
             ▼
  ┌─ 步骤 5: 嵌套聚合引用展开与回溯 ─┐
  │ 顺沿 PropRefref:utterance 展开   │
  │ 沿 ref:modifier 补全作用域│
  │ 沿 ref:logical 展开推导链 │
  │ 同源表达式聚合加分         │
      │ 返回完整语义单元        │
  └──────────┬───────────────┘
             ▼
          最终结果

与 3.0 流程对比,变化的三步:

步骤 1:解析树按 3.2 规则,作用域直接记为 : 修饰,条件直接记为逻辑命题。不再有"情境"这一临时概念。

步骤 3 新增连词一致性检查:如果查询是"如果 P 则 Q",候选是"尽管 P 但 Q",connector 不同 → 降权或过滤。这是 ~~SVO~~3.0 ~~相比纯向量检索~~根本无法精确做到的,因为两者在 3.0 里都是 "P >> Q" 结构,连词信息早已丢失。

步骤 5 三路引用独立展开:言说、修饰、推导三种引用类型分别触发不同的回溯逻辑。例如展开一个动作命题时,会顺 ref:utterance 展开宾语,顺 ref:modifier 补全作用域,但不会自动展开其所参与的逻辑链——除非查询显式表达了对推导的兴趣。

步骤 3 的杀手锏~~。几十行规则代码就能干掉"语义看似相近、实则相反"的脏数据,这是纯神经方案做不到的。~~例子:

查询 (模型 > 开源) > 则 > (?),候选 (模型 > 开源) > 尽管 > (性能 > 下降) → connector 不匹配,过滤
查询 所有:学生 > 通过 > 考试,候选 某:学生 > 通过 > 考试 → ~~降权(~~量词不同),降权
查询 现有:框架 > 适用,候选 现有:框架 > 不:适用 → ~~过滤(~~极性翻转),过滤
查询 必须(AI:方面) :完成 (K > 偏向 > X),候选 可能(生物:完成方面) : (K > 偏向 > X) → ~~降权(模态强度~~作用域不同)匹配,过滤

这几类过滤在纯向量方案里是致命盲区,在 3.2 的结构化方案里是几十行规则代码。

六五、核心技术挑战与解法

6.5.1 SVO 3.2 解析器的稳定性(最关键风险点)

3.2 把消歧责任从算子级推到了操作数形态级。3.0 里"条件"和"话题"用不同算子区分,一眼可辨;3.2 里都是靠括号封装来消歧。这意味着解析器对括号边界的判断必须异常稳定——如果同一个句子有时解析成 (P) > 则 > (Q),有时解析成 ((P):Q),整个检索系统就崩了。

行动指引:

建立解析稳定性基准测试。准备 500 句带歧义的自然语言,每句 10 个人工改写,跑解析器。统计同语义句的 SVO 3.2 树一致率(以结构指纹为准)。

一致率门槛:低于 85% 不得投入检索系统建设。

优先稳定"作用域 vs 条件"的识别——这是 3.2 解析器最容易出错的地方。中文里"在 X 的情况下"既可能是话题((X) : (...))也可能是条件((X) > 则 > (...)),必须用上下文特征分类,不能靠正则。

校验器:解析完立即校验"表达式中是否出现 >>",出现即为解析器 bug,而非语法 3.0 回退。

5.2 编码器必须"懂算子 + 懂连词"

~~最容易被忽视但最关键的一件事。普通~~3.0 ~~sentence encoder 会把~~方案要求编码器懂 :、 >、 >> ~~当成无意~~的语义~~符号忽略~~。3.2 合并了算子,~~效果还不如~~但要求编码~~原始中文句子~~器对 > 的两种承载(动作流 vs 逻辑流)通过两端操作数形态自动区分,且对连词词项(则/尽管/导致)敏感——这是更细的要求。

解法~~:构造五类~~对比学习数据~~微调编码器,让它学会区分算子语义。~~(在 3.0 基础上新增两类):

对比类型	正例 / 负例	期望距离
角色翻转	`A > 杀 > B` vs `B > 杀 > A`	远
同义动作	`A > 喜欢 > B` vs `A > 爱 > B`	近
极性翻转	`不:适用` vs `适用`	远
量词差异	`所有:学生 > 通过` vs `某:学生 > 通过`	中
情境作用域翻转	`(战时):(军队>> 训练)` vs `(和平):(军队>训练)`	远
连词翻转 (3.2 新)	`(P) > 训练则 > (Q)` vs `(P) > 尽管 > (Q)`	远
逻辑流 vs 动作流 (3.2 新)	`(P) > 导致 > (Q)` vs `P > 导致 > Q`(误解析)	远

每连词翻转这一类~~几万条~~尤为关键。如果编码器分不清"则"和"尽管",~~LoRA~~索引微调C 的精排就是瞎排。

5.3 双重本体在向量空间中的投影

3.2 的二元本体(属性 / 力)在向量空间里建议显式投影到两个子空间:

属性子空间:编码概念簇、作用域修饰

力子空间:编码动作命题、逻辑命题

同一个 BGE-base 几主干 + 两个投影头(projection ~~epoch。~~~~这一步是整~~head)。训练时在两个方案子空间分别做对比学习。查询时按查询的~~技术核心~~~~,其他都是工程组装。~~

6.2 SVO 解析器的稳定性

~~整套方案真正的风险点不在检索算法,在上游解析~~本体类型路由到对应子空间。

如这比"一个大空间装所有东西"效果好——3.0 方案的一个隐患就是"Karpathy"(实体)和"Karpathy 表示 X"(命题)会在同一个句空间里互相干扰,导致 L1 查询召回一堆命题。3.2 的子~~被不同地解析成不同~~空间切分从根上杜绝这个问题。

六、数据模型(3.2 核心表结构)

-- 概念簇表
CREATE TABLE concept (比如
  id            BIGSERIAL PRIMARY KEY,
  canonical     TEXT NOT NULL,              -- SVO 线性形式
  core_word     TEXT NOT NULL,              -- 核心词
  modifiers     TEXT[] NOT NULL,            -- 修饰词挂靠不同、嵌套括号不链
  role          VARCHAR(16) NOT NULL,       -- entity|concept|scope|sentence_mod
  vector        VECTOR(768)                 -- 复用 A 索引向量
);

-- 动作命题表
CREATE TABLE action_proposition (
  id            BIGSERIAL PRIMARY KEY,
  subject_id    BIGINT REFERENCES concept(id),
  verb          TEXT NOT NULL,
  object_id     BIGINT REFERENCES concept(id),   -- NULL 表示宾语是 PropRef
  object_ref    BIGINT,                          -- PropRef:指向另一致)命题
  polarity      SMALLINT NOT NULL DEFAULT 1,     -- 1=肯定,那么同一份内容在 -1=否定
  modality      VARCHAR(16),                     -- 必须|可能|NULL
  quantifier    VARCHAR(16),                     -- 所有|某|没有|NULL
  fingerprint   BIGINT NOT NULL,                 -- 结构指纹空间里会散落到不同桶里哈希
  vector        VECTOR(768)
);

-- 逻辑命题表(3.2 新增)
CREATE TABLE logical_proposition (
  id            BIGSERIAL PRIMARY KEY,
  antecedent_id BIGINT NOT NULL REFERENCES action_proposition(id),召回率直接崩。

  connector     VARCHAR(16) NOT NULL,       -- 则|尽管|导致|因此|促使|以便
  consequent_id BIGINT NOT NULL REFERENCES action_proposition(id),
  antecedent_vec VECTOR(768),
  consequent_vec VECTOR(768)
);

-- 引用关系表(3.2 重构:拆分 ref_type)
CREATE TABLE prop_ref (
  id            BIGSERIAL PRIMARY KEY,
  source_type   VARCHAR(16) NOT NULL,       -- action|logical|concept
  source_id     BIGINT NOT NULL,
  target_type   VARCHAR(16) NOT NULL,       -- action|logical
  target_id     BIGINT NOT NULL,
  ref_type      VARCHAR(16) NOT NULL        -- utterance|modifier|logical
);

CREATE INDEX idx_ref_target ON prop_ref(target_type, target_id, ref_type);
CREATE INDEX idx_ref_source ON prop_ref(source_type, source_id, ref_type);

~~行动指引~~关键设计点:~~在投入做检索之前,先验证 SVO 解析器对同义改写的稳定性。给同一批句子做 10 种人工改写,看解析结果的结构指纹一致率。如果低于 80%,先回去稳定解析器,别急着盖检索的楼。~~

6.3
实体
`action_proposition` vs和概念的编码`logical_proposition` 分离

表存储,避免字段冗余。精排时可以并表查询。

~~前面提过,再强调一次:实体型核心词和概念型核心词必须~~

prop_ref 表同时服务三种引用~~不同的编码路径,否则两头不讨好。入库时用 NER 或小分类器识别~~类型,~~用两个~~通过 ~~LoRA~~ref_type ~~适配器~~区分~~别编码,~~。反向查询~~时分别召回再合并~~效率靠 idx_ref_target 保证。

polarity / modality / quantifier 作为命题的头等字段,不混在向量里。这是逻辑过滤层能存在的前提——过滤只发生在离散字段上。

七、工程落地路径

7.1 基础设施选型(相对 3.0 的调整)

组件	选型	理由
倒排索引 (B1)	Elasticsearch	~~成熟,~~角色字段查询零门槛
向量索引 (A/B3/C)C/D)	Qdrant 或 Milvus	支持带 metadata 的~~向量,~~过滤高效
结构哈希 (B2)	Redis ~~+ Postgres~~	哈希倒排用 ~~Redis,lattice 关系用 Postgres~~O(1)
命题关系表(含 PropRef)	Postgres	外键保一致,PropRef 反向查询用外键索引
逻辑命题表 (3.2 新)	Postgres + pgvector	关系+向量共存,避免跨库事务~~保证一致性~~
编码器	BGE-base + LoRA	中文效果好,微调成本低

完全不需要图数据库~~。图数据库在这个场景会引入不必要~~的~~复杂度~~判断依然成立——PropRef ~~用外键~~表配合两个方向的索引就够了。3.2 增加了 ref_type 维度,~~查询模式~~但这只是有限多加一列过滤,仍在关系数据库的~~几种,不需要 Cypher 的通用图查询能力~~舒适区内。

7.2 三阶段演进(3.2 版)

阶段一:最简可行版本(1-2 个月)

概念簇用加性组合,零训练
动作命题用倒排 + 结构哈希

逻辑命题表建起来,但先不上~~神经编码~~向量,只做 connector 精确匹配

作用域修饰索引直接用 Postgres 多对多表
逻辑过滤用规则
目标:跑起来通全链路,收集真实 query → ~~期望结果的成对~~expected 数据

阶段二:神经增强(2-3 个月)

~~按五类对比对~~微调编码器(包含 3.2 新增的两类对比对)
槽位向量索引上线

逻辑命题的前件/后件向量索引上线
学习排序模型接入(六维特征)
目标:~~相关性指标~~L3、L4 召回率显著提升

阶段三:精细优化(持续)

概念编码~~升级到~~器按 ~~Transformer~~role +分四个 ~~绑定深度位置编码~~LoRA

属性 / 力双子空间投影
结构指纹 lattice 扩展~~策略优化~~

~~实体 / 概念编码器分离~~
逻辑过滤规则从真实 bad case 反向补充

~~强烈建议不要试图一次性做完所有组件~~~~。没有真实查询日志,优化方向都是猜的;有了日志,优先级自然浮现。~~

7.3 评估指标(3.2 版)

~~不能只看传统~~在 IR3.0 ~~指标(MRR、NDCG)。SVO 检索需要额外~~的五个结构敏感指标基础上,新增两个:

角色准确率:~~召回结果的~~施事/受事~~角色是否与查询~~对齐
极性准确率:是否错召了反义命题
量词一致率:量词强度是否匹配
作用域覆盖率:话题/身份命中(原情境覆盖率~~:情境维度的命中情况~~拆分项)
嵌套深度保持率:~~查外层命题时~~言说展开正确性

连词一致率(3.2 新):条件/让步/因果的连词是否正确匹配

逻辑链完整率(3.2 新):推导链被完整展开~~了内层~~的比例

这些连词一致率是最能暴露 3.2 系统优劣的指标~~分别暴露~~。如果这个指标不~~同组件的问~~及格,说明逻辑命题索引没起作用,整个方~~便定向优化~~案其实还停留在 3.0 时代。

八、为什么这套 3.2 方案"系统且可行"比 3.0 方案更好

8.1 严谨性的提升

~~系统性~~3.0 的语义混淆体现:"情境"这个概念同时装了两类本质不同的东西——作用域(在三点 X 方面)和条件(如果 X)。在检索时,它们的召回逻辑、逻辑过滤、反向展开方式其实不同,但共享同一套索引和引用机制。后果是:

~~从相关性定义出发~~查询"在和平时期军队做什么",每会把"如果和平军队就训练"一层起召回(~~L1-L5)都有明确负责的组件,职责不交叉不遗漏~~假阳)
~~语义与结构彻底解耦~~查询"如果模型开源会怎样",连续会把"在开源模型领域的~~交给向量,离散的交给索引,两者协同而非妥协~~研究"一起召回(假阳)
~~每个组件都可独立评估和优化~~~~,这种可解释、可调试的架构是纯神经方案给不了的~~

3.2 的清晰切分:作用域归 :,进入索引 D;条件归 >,进入索引 C。两类查询走不同的召回通道,不再互相污染。

8.2 可行性的提升

3.0 的工程不对称~~体现在三点~~:"情境"作为独立原子类型,需要专门的情境编码器、情境索引、情境反向查询逻辑,但它和普通命题其实共享大部分数据结构,代码里处处是"如果是情境就…"的特殊分支。

3.2

全的工程对称:所有"限定关系"走 : 和 ref:modifier,所有"推导关系"走 > 和 ref:logical。两套通道内部~~用现成开源基础设施~~结构一致,~~不需要前沿研究突破~~

~~零训练基线就能跑起来~~~~,不卡在冷启动~~

演进代码里只有两种主干路径清晰~~,每一步升级都不需要推倒重来~~

九、SVO 。实测这种对称性能把检索相比传系统代码量减少 20-30%,且 bug 密度更低(因为特殊分支更少)。

8.3 新能力的获得

3.2 方案的独~~特价值~~有、3.0

~~最后总结一下这套~~方案~~能做到、而纯文本向量检索~~做不到的事情:

~~角色敏感检索~~条件链追踪:沿 antecedent_ref 链式遍历找出"P → Q → R"的推导链。3.0 的情境是命题的属性,无法链式推导。

连词级精确过滤:区分"~~谁对谁做了什么~~如果…则…"~~的方向性~~和"尽管…但…",3.0 把两者都打包成"P >> Q"。
极性作用域反向查询的纯度:查"AI /领域下的所有论断"不会混入"以量AI 为条件推出的论断",3.0 二者不可分。

句子级副词 ~~/ 模态~~的正确处理:~~不会把~~"~~不适用"~~显然,P"和"~~适用"判为相似~~

~~情境独立检索~~~~:能按"在什么场景下"做维度过滤~~

~~事实与陈述的分离~~:据说,P"通过 ~~PropRef~~sentence_mod 子索引区分~~"发生了什~~,3.0 要么~~"和"谁说发生了什~~扔掉要么"

~~结构类比检索~~~~:能按抽象骨架找相似案例,实体完全不同也能召回~~

~~可解释的检索路径~~~~:每条结果都能说清楚"因为概念相似 + 结构匹配 + 情境覆盖而被召回"~~错绑。

8.4 代价:对解析器稳定性的依赖加重

必须诚实承认:3.2 的全部优势,前提是解析器能稳定地把自然语言转成正确的 SVO 3.2 树。3.0 因为 >> 作为显式信号,解析器出错概率低;3.2 的歧义靠括号边界消解,解析器的一个括号错位就会让整个结构哈希跑偏。

这~~些能力~~个代价是可以承受的——因为解析器可以独立迭代、独立评估、独立改进。而且 3.2 的解析器至少在~~通用场景或许~~本体上是~~锦上添花,但在~~~~学术文献检索、法律判例检索、新闻事实核查、情报分析~~等对清晰的(只有两类语义~~精度要求极高的领域~~),~~是刚需~~更容易训练。~~SVO~~3.0 的~~算子设计本来就是为这种高精度场景准备的~~"情境"边界模糊,~~检索系统如果不把这些能力兑现出来,就太可惜了~~其实连人工标注都有分歧。

附:九、快速索引查找表

我想做	去哪个组件
找含特定实体的表达式	索引 A(~~概念向量~~role=entity)
找含特定话题/场景的表达式	索引 A(role=scope) → 索引 D
找含特定句子级态度词(如"显然")	索引 A(role=sentence_mod) → 索引 D
找角色精确匹配的动作命题	索引 B1(倒排)
找结构相同的类比案例动作命题	索引 B2(结构哈希)
找语义模糊相似的动作命题	索引 B3(槽位向量)
找满足"如果 X 则…"的推导	索引 C(前件向量)
找"…导致 X"的推导	索引 C(后件向量)
找特定场景连词的推导链	索引 C(connector 过滤)
找"在某作用域下"的命题	索引 ~~C(情境向量)~~D
避免召回反义命题	步骤 3 逻辑过滤(polarity)
避免召回不同连词的逻辑	步骤 3 逻辑过滤(connector)
追溯"谁说了这句话"	PropRef 反~~向遍历~~查 ref:utterance
展开"他说了什么"	PropRef 正~~向遍历~~查 ref:utterance
追溯"这个结论的前提是什么"	PropRef 反查 ref:logical
展开"这个条件会推出什么"	PropRef 正查 ref:logical

粗体是 3.2 相对 3.0 新增的能力。它们都直接源自 >> 消除后带来的本体清晰化——每一项新能力都不是"多做了什么",而是"不再把不同的东西搅在一起"的自然结果。

附录:3.0 → 3.2 迁移检查清单

如果你已经基于 3.0 方案建了检索系统,按下列顺序迁移:

停用解析器的 >> 输出。解析器改为 3.2 语法,任何 >> 输出视为 bug。

重建分解流水线。旧"情境原子"按如下规则拆分:
- 左侧是完整命题且原意为条件/让步 → 进入新表 logical_proposition
- 左侧是话题/身份/范围短语 → 作为 role=scope 的概念,通过 ref:modifier 关联
- 左侧是句子级副词 → 作为 role=sentence_mod 的概念,通过 ref:modifier 关联

回填数据。老数据按上述规则跑一遍迁移脚本,生成新表记录。

索引重建。索引 C 是全新的,索引 D 由旧情境索引转化而来,索引 A 需要加 role 字段。

编码器微调。用 3.2 新增的两类对比对重新训练一轮 LoRA。

评估对比。跑原有评估集,重点看连词一致率和作用域覆盖率是否上升。

切流。灰度发布,对比 3.0/3.2 双系统的 bad case,特别关注条件句和话题句的召回差异。

不要试图让 3.0 和 3.2 并存太久。双系统维护成本高,而且 3.2 的优势主要来自本体清晰化——保留旧系统会把污染也保留下来。

SVO 3.2 语义检索的系统化方案

SVO 3.2 语义检索的系统化方案

零、一句话概述

一、第一性原理:定义"语义相关"

二、语义原子化:入库时的分解

2.1 三类原子(3.2 版)

2.2 分解示例

2.2 原子间的三种引用关系(PropRef 机制扩展)

2.3 分解示例(3.2 版)

三、三四层索引架构

3.1 索引 A:概念向量索引(服务 L1)

3.2 索引 B:动作命题索引(服务 L2、L4、L5)L6)

3.3 索引 C:情境逻辑命题索引(服务 L4,3.2 新增)

3.4 索引 D:作用域修饰索引(服务 L3)

四、嵌套命题:PropRef 机制

五、完整检索流程(3.2 版)

六五、核心技术挑战与解法

6.5.1 SVO 3.2 解析器的稳定性(最关键风险点)

5.2 编码器必须"懂算子 + 懂连词"

5.3 双重本体在向量空间中的投影

6.2 SVO 解析器的稳定性

六、数据模型(3.2 核心表结构)

6.3 实体action_proposition vs和 概念的编码logical_proposition 分离

七、工程落地路径

7.1 基础设施选型(相对 3.0 的调整)

7.2 三阶段演进(3.2 版)

7.3 评估指标(3.2 版)

八、为什么这套 3.2 方案"系统且可行"比 3.0 方案更好

8.1 严谨性的提升

8.2 可行性的提升

九、SVO 。实测这种对称性能把检索相比传系统代码量减少 20-30%,且 bug 密度更低(因为特殊分支更少)。

8.3 新能力的获得

8.4 代价:对解析器稳定性的依赖加重

附:九、快速索引查找表

附录:3.0 → 3.2 迁移检查清单

6.3
实体
`action_proposition` vs和概念的编码`logical_proposition` 分离