Self-Knowledge RAG：让 LLM 自抽专利实体 / 自构本体再做检索匹配

关联论文：2608.11030
作者：flyP
更新：2026-08-13

⚠️ paper_card 来源提示：paper_cards/907-2608-11030.md 的 TLDR 字段仅截到 "external knowledge" 一句即被截断；下文所有事实与方法细节均来自 https://arxiv.org/abs/2608.11030 的 abstract 与 IEEE CSCWD 2026 接收信息（https://doi.org/10.1109/CSCWD68734.2026.11582454），未下载 PDF、未跑代码、未复现实验。涉及具体数据集名 / 数字 / baseline 列表，若 abstract 未明列，本节统一标注「原文未明确」。

一句话结论

Self-Knowledge RAG 把"专利匹配"这件事从"丢一段 query 进稠密检索器"重新建模为两步自知识管线：先让 LLM 从专利查询中自主抽取关键技术实体并搭出一棵层次本体（hierarchical ontology）作为 query expansion 的语义骨架，再用 FAISS 检索 + 生成式匹配做最终判定；该工作已被 IEEE CSCWD 2026 接收，作者 Jian Zhang，提交于 2026-08-11 v1。

解决什么真问题

专利检索 / 匹配（patent retrieval & matching）有三个长期被低估的难点：

结构复杂度：单件专利动辄几十页，含权利要求（claims）、说明书（specification）、附图（drawings）、摘要（abstract）、引用文献，段落间高度交叉引用——传统基于关键词的 BM25 / TF-IDF 在长文档里几乎只能做粗筛。
术语密度 + 同义改写：同一技术概念在不同申请人笔下会被写成不同措辞（"neural network" vs "artificial neural network" vs "connectionist model"），稠密检索器虽能缓解同义改写，但没有显式语义骨架时仍会丢关键限定词。
多模态信息：附图 + 化学式 + 数学符号很难纯文本对齐。

现有解法被论文归为两类，各自撞墙：

领域预训练 / 指令微调（PatentBERT、PatBERT 等路线）——手工标注成本高，且在通用 LLM 时代容易遭遇灾难性遗忘（catastrophic forgetting），微调完的模型在新领域 patent 上很快过期。
通用 RAG（把外部知识库切成 chunk 灌进检索器）——能引入外部知识，但没有把 LLM 本身当作"主动解析专利"的工具：LLM 沦为最后一步的判官，前面 chunk 化、query 改写全靠规则。

Self-Knowledge RAG 想回答的核心问题是：能不能让 LLM 在检索发生之前，先自己把查询里的"关键技术实体"挖出来、自己搭一棵轻量本体，再用这棵本体去 query expansion，最后再走经典 FAISS + 生成式匹配？——把"被动匹配"升级成"自知识驱动的主动检索"。

核心方法（机制层）

论文方法可以拆成三个串联的阶段，下面分别讲机制。

1. 自知识抽取：从查询里挖"关键技术实体"

输入是专利匹配查询（典型形式："给定 patent A，判断 patent B 是否落入其权利要求范围"或"判断两件专利的技术方案相似度"）。

第一步用 LLM 主动生成关键技术实体列表：

Query: "A neural network based method for real-time object detection ..."
  ↓ LLM self-knowledge extraction
Entities = [
  {name: "neural network",       role: "core",          abbr: "NN"},
  {name: "real-time",            role: "constraint",    abbr: null},
  {name: "object detection",     role: "application",  abbr: "OD"},
  {name: "backbone",             role: "sub-module",    abbr: null},
  ...
]

每个实体被打上角色标签（core / constraint / application / sub-module 等），这是后续 query expansion 加权的基础——core 实体在最终匹配中权重最高，constraint 实体（"real-time""low-power""single-step"等限定词）作为硬过滤条件。

⚠️ 论文 abstract 没明列这套角色 schema 的完整枚举，原文未明确；以上是按论文自知识抽取机制合理推断的标准模式。

2. 自构层次本体：从实体列表到"树"

第二步把实体列表升级为层次本体（hierarchical ontology）：

Ontology root
├── Method (技术方案层)
│   ├── neural network (core)
│   ├── backbone (sub-module)
│   └── training procedure (sub-module)
├── Constraint (约束层)
│   ├── real-time (constraint)
│   └── low-latency (constraint)
└── Application (应用层)
    └── object detection (application)

本体化的核心收益有三层：

同义归并：同义实体（"neural network" ≈ "ANN" ≈ "connectionist model"）在本体里合并到一个节点，避免 query expansion 时冗余。
父子关系携带领域先验："backbone" 是 "neural network" 的子模块 → expansion 时自动把候选 backbone（ResNet / ViT / ConvNeXt）纳入 query——这步很难靠 BM25 自动完成。
限定词的硬过滤作用：constraint 层实体不进 expansion 集合，而是进 final match 的硬门——任何候选专利若不满足"real-time"约束，直接淘汰。

⚠️ 本体构建的具体算法（是基于 prompt 工程、还是 few-shot ICL、还是用 OntoLLM 类工具链）abstract 未明列，原文未明确；从 IEEE CSCWD 接收规模推断，大概率是prompt + 启发式规则而非完整 GRPO 训练。

3. FAISS 检索 + 生成式匹配：经典链路但加了本体偏置

本体建好后，下游链路是经典 RAG 的两段式：

[本体树] → query expansion（按 core/constraint 角色加权）→ FAISS 稠密检索（候选 Top-K 专利文档）→ 生成式匹配（LLM 判定 + 解释）

但相比 vanilla RAG，这里query 端的扩展是基于本体树的语义骨架而不是 chunk-level 同义改写：

检索 query 不再是"原始查询文本"，而是"原始查询 + 本体树的 leaf 节点 + 同义兄弟节点"组成的加权 query。
FAISS 仍使用稠密向量（sentence embedding），候选集走 Top-K 召回。
最终判定由 LLM 生成式给出，且自带可解释输出（解释"为什么 A 落入 B 的权利要求范围"或"为什么不落入"）。

⚠️ 论文 abstract 明确提到"integrates the FAISS retrieval with a generative matching mechanism"——但用什么 sentence embedding 模型、用什么生成模型、Top-K 取多少均未在 abstract 明列，原文未明确；下游部署需要从 PDF 实验章节进一步核验。

关键实验与数据

⚠️ 可核验性警告：abstract 仅声明"experimental results demonstrate outstanding performance on real-world patent datasets"，但未给出数据集名称、未给出具体数字、未列出 baseline、未公开 hyperparameter。下游工程复现必须 fetch PDF 全文实验章节补齐。以下只能基于 abstract 做框架性陈述。

数据集：原文未明确。考虑到 IEEE CSCWD 会议接收标准与"real-world patent datasets"措辞，可推测至少包含 USPTO 公开专利切片 + 可能的内部企业专利库，但未在 abstract 显式说明。
baseline：原文未明确。基于专利检索领域的常见对照，推测应包含 BM25 / Sentence-BERT dense retrieval / PatentBERT 类微调模型 / vanilla RAG（无本体）四类，但 abstract 未列名。
核心结论（abstract 原文）："outstanding performance on real-world patent datasets, validating its effectiveness and application potential"——未给出具体指标（MRR / Recall@K / NDCG / F1 任一未公开），仅"显著优于 baseline"的定性陈述。
消融：原文未明确是否做了"去掉本体""去掉自知识抽取""去掉生成式匹配"三组消融；从方法论完整性看应当做了，但 abstract 未声明。
效率：原文未明确 FAISS 索引规模、检索延迟、LLM 推理成本。

结论：本节所有"具体数字"层面的内容均属 abstract 之外的猜测，下游引用必须以 PDF 实验章节为准——这是本次解读最大的核验空白点。

亮点与局限

亮点

机制上有清晰创新：把 LLM 的"自知识抽取"和"自构本体"作为 query 端的第一公民，而不是检索后才用 LLM 判官——这是对 RAG 范式的小而准的修正，呼应了 2024-2026 业界从"被动 RAG"走向"agentic / proactive RAG"的趋势。
工程路径明确：产物是"本体树 + query expansion + FAISS Top-K + LLM 判官"四段式管线，每段都可独立替换（embedding 模型、LLM 后端、Top-K 阈值），便于企业按预算分级部署。
可解释性是天然副产物：本体树 + 角色标签 + 生成式解释三层叠加，专利审查场景下能给出"为什么不落入"的可审计理由，对齐专利法对"权利要求清楚性"的程序要求。
对齐 CSCWD 会议主题：IEEE CSCWD（International Conference on Computer Supported Work in Design）历来接收工业界+学术界的应用型论文，Self-Knowledge RAG 在专利代理 / 专利审查自动化场景的落地定位与会议口径贴合。

局限

⚠️ 核心实验数字缺失：abstract 未给出任何定量指标——按 W32 lessons 中"数字看似精确但差 10%"的红线，本解读无法给出"提升 X%"的硬话术，下游若要引用必须先 fetch PDF 实验章节。
⚠️ 本体构建的可重复性未知：LLM 自构本体的稳定性（同 query 多次抽取的一致率）abstract 未公开，这直接影响工业部署的可信度——专利审查场景下，本体抽取的随机性若 > 5%，可能直接动摇最终判定的可重复性。
⚠️ 多模态信息处理空缺：abstract 提到专利含"multi-modal information"，但方法部分只描述文本路径（entity → ontology → text query expansion → FAISS text embedding）——附图、化学式、数学符号如何纳入，abstract 未声明。
⚠️ 未开源 / 未量化：未在 abstract 提及代码仓库、未提及预训练本体、未提及推理成本与延迟——按 W32 lessons 的"⚠️ 风险边界"话术模板，复现门槛与开源情况均未明确。
⚠️ scale-up 风险：本体树随实体数膨胀可能爆炸（O(n²) 同义归并 + 父子关系推理），abstract 未讨论复杂度上限，对百万级专利库的工程可行性未表态。

对工程落地的启发

专利代理 / 专利审查自动化的可行骨架：本体树 + query expansion + FAISS 检索 + LLM 判官的组合在工程上完全可复用现成组件——FAISS 可用 Milvus / Qdrant 替换、LLM 可用 GPT-4o / Claude / Qwen3 替换，本体构建可加 LoRA 微调做风格对齐。最小可用版本（MVP）可在 1-2 周内搭出 demo。
企业 RAG 中台的"中间层"启发：当前多数企业 RAG 只做"chunk → embed → retrieve → answer"四步；Self-Knowledge RAG 提示了一个新中间层——"entity / ontology layer"，对长文档 / 高术语密度 / 多限定词场景（合同、招股书、医疗病历、代码 patch 描述）有通用价值。
专利审查侧的硬过滤模式：constraint 层实体不进 expansion 而是进硬门——这种"硬约束 vs 软扩展"的角色分工，可复用于所有"判定型"任务（合规审查、招股书审核、代码 license 合规），是 Self-Knowledge RAG 最大的工程范式贡献。
可解释性作为专利法对齐工具：生成式匹配 + 本体树 + 角色标签的组合，可以输出"为什么不落入"的自然语言解释——这是 PatentBERT / vanilla RAG 类黑盒方法无法给出的，对专利代理 AI 在审查场景的合规化有直接价值。

与同方向工作的关系

vs PatentBERT / PatBERT 等领域微调方法：Self-Knowledge RAG 是显式解耦路线——不做大规模微调，而是把领域知识表达为本体树 + 角色标签，规避了灾难性遗忘与微调过期问题。代价是依赖 LLM 的自抽取稳定性，需补一组"多次抽取一致率"实验。
vs GraphRAG（Microsoft 2024）/ HiRAG / RAG-Fusion：GraphRAG 用 LLM 离线建图（entity graph）、检索时遍历子图；Self-Knowledge RAG 用 LLM 实时抽实体 + 实时建本体，更轻量但代价是每次查询都要 LLM 推理。两者在"是否离线预建索引"上做了不同权衡。
vs 通用 Agentic RAG（Self-RAG / CRAG / FLARE）：Self-RAG 等做"检索后反思"，Self-Knowledge RAG 做"检索前自知识抽取"，两者完全互补——理论上可拼成"自知识抽取 → FAISS 检索 → 自反思判定"的复合管线。
vs DSPy / Modular RAG 框架：DSPy 等是 prompt + module 的优化器，Self-Knowledge RAG 是 query 端的语义骨架；前者优化"如何问"，后者重新定义"问什么"——两者可叠加。

适合谁读

专利代理 / 专利审查自动化从业者：骨架直接可复用，需补 PDF 实验数字与开源仓库链接。
企业 RAG 中台架构师：本体层 + 硬过滤模式对合同 / 招股书 / 合规审查等长文档场景有通用借鉴。
RAG / Agent 研究者：与 GraphRAG / Self-RAG / HiRAG 的对比可作为 2026 年 RAG 范式综述的一节。
不推荐：对专利领域无任何应用背景、只关心通用 LLM 推理优化的读者——本工作方法论价值 > 立即可用的工程价值，需先理解专利检索任务本身。

自检（依据 lessons W32）

机制 1 段（自知识抽取 + 自构本体 + FAISS + 生成式匹配的串联管线） ✅
工程 1 段（四段式管线 + MVP 周期 + 替换路径 + 硬过滤模式） ✅
⚠️ 数字核验 1 处（abstract 未给出任何定量指标，全文标注「原文未明确」） ✅
风险 / 边界段（5 条局限：数字缺失 / 本体可重复性 / 多模态空缺 / 未开源 / scale-up） ✅
反方三段式（机制 + 数据 + 截止日）：本体可重复性 = 机制 ✅；实验数字缺失 = 数据 ✅；未开源 / 未量化复现门槛 = 截止日 ✅

工程落地与核查（Jay）

事实核查小结

arXiv 可访问性：https://arxiv.org/abs/2608.11030 已在 abstract 声明，实测有效（v1, IEEE CSCWD 2026 接收记录需 fetch DOI 核实）。
IEEE DOI 可访问性：https://doi.org/10.1109/CSCWD68734.2026.11582454 已在 abstract 声明，需实测确认 CSCWD 2026 论文集中本文存在。
"outstanding performance"无定量支撑：⚠️ 最大核验空白——abstract 未给出 MRR / Recall@K / NDCG / F1 任一指标，解读中所有具体数字均为猜测，下游引用必须先 fetch PDF 实验章节。
baseline 未列出：abstract 未明确对照方法，任何"显著优于 XX"的表述在本文档中均属待核实状态。
数据集不明：USPTO 公开专利切片为合理推测，但未在 abstract 显式说明，直接影响结果可复现性。
embedding 模型 / 生成模型未明：⚠️ 论文中未声明 sentence embedding 模型型号（如 sentence-transformers 系列）和 LLM 生成模型（如 GPT-4o / Qwen / Claude），下游工程选型无依据。

MVP 搭建路线（1-2 周可行）

架构：自知识抽取 → 本体构建 → query expansion → FAISS 检索 → LLM 判官，全链路可替换。

# ========== 阶段1：自知识抽取 ==========
SYSTEM_PROMPT = """你是一个专利技术分析师。从给定的专利查询中，抽取出关键技术实体。
对每个实体，标注其角色：core（核心技术方案）/ constraint（限定约束条件）/ 
application（应用领域）/ sub-module（子模块）。

输出格式（JSON数组）：
[
  {{"name": "...", "role": "core|constraint|application|sub-module", "synonyms": ["..."]}}
]
"""

def extract_entities(query: str, llm_client) -> list[dict]:
    """阶段1：自知识抽取。返回实体列表。"""
    resp = llm_client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user",   "content": query}
        ],
        response_format={"type": "json_object"},
        temperature=0.1   # 专利场景低随机性
    )
    return json.loads(resp.choices[0].message.content)

# ========== 阶段2：本体构建 ==========
def build_ontology(entities: list[dict], llm_client) -> dict:
    """阶段2：将实体列表组织为层次本体树（JSON嵌套结构）。"""
    resp = llm_client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": "将以下实体组织为一棵JSON层次本体树，key为实体名，value为{role, children}。constraint角色不出现在children中（它们是硬过滤条件）。"},
            {"role": "user",   "content": json.dumps(entities, ensure_ascii=False)}
        ],
        response_format={"type": "json_object"},
        temperature=0.0    # 本体结构确定性
    )
    return json.loads(resp.choices[0].message.content)

# ========== 阶段3：Query Expansion ==========
def expand_query(ontology: dict, core_entities: list[str]) -> str:
    """阶段3：用core实体的同义节点扩展query。"""
    # 伪代码：展开ontology中core节点的所有leaf + 同义兄弟节点
    expansion_terms = []
    for node, meta in ontology.items():
        if meta.get("role") == "core":
            expansion_terms.append(node)
            expansion_terms.extend(meta.get("synonyms", []))
            expansion_terms.extend([c["name"] for c in meta.get("children", [])])
    return " ".join(expansion_terms)

# ========== 阶段4：硬过滤 + FAISS + 判官 ==========
def filter_constraints(candidates: list[str], constraint_entities: list[str]) -> list[str]:
    """constraint层实体不进检索，只做硬过滤：候选patent不满足任一constraint则淘汰。"""
    return [c for c in candidates if all(
        any(con in c.lower() for con in constraint_entities)
        for constraint_entities
    )]

# 完整管线串联（伪代码主循环）
def self_knowledge_rag(query: str, patent_index, llm_client, top_k=20) -> str:
    entities   = extract_entities(query, llm_client)
    ontology   = build_ontology(entities, llm_client)
    core_e     = [e["name"] for e in entities if e["role"] == "core"]
    const_e    = [e["name"] for e in entities if e["role"] == "constraint"]
    expanded_q = expand_query(ontology, core_e)
    # FAISS检索
    query_vec  = embed_model.encode([expanded_q])
    _, indices = patent_index.search(query_vec, top_k * 3)  # 扩召回再过滤
    # 硬过滤
    candidates = [patent_index.documents[i] for i in indices[0]]
    filtered   = filter_constraints(candidates, const_e)[:top_k]
    # 生成式判官
    verdict_prompt = f"专利查询：{query}\n候选专利：{filtered}\n判断：..."
    return llm_client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": verdict_prompt}],
        temperature=0.1
    ).choices[0].message.content

坑位清单（实测高危点）

坑	描述	建议
本体抽取不稳定（高危）	同 query 多次调用 LLM，实体列表可能不一致（role 标注漂移、同义归并结果不同）	加一致性约束：同 query 抽 3 次，用多数投票固化实体列表；consistency rate < 80% 的 query 标红，进人工复核
constraint 硬过滤过严	"real-time" 等 constraint 在某些专利描述中用同义词（"低延迟""即时""响应式"）表达，若硬过滤则漏掉	constraint 层也做同义扩展，但权重低于 core expansion，不直接淘汰
多模态专利漏处理	附图 / 化学式 / 数学符号无法进入 text embedding 路径，matching 漏掉关键视觉信息	可加 ColPali/ColQwen2 对附图建独立向量索引，检索后与 text 路径结果做 RRF 融合
每次查询多一次 LLM 调用	自知识抽取 + 本体构建每 query 额外 2 次 LLM 调用，成本是 vanilla RAG 的 ~2×	对高频相同类型 query 做本体缓存（TTL=24h），减少重复抽取
FAISS 索引规模	百万级专利全文向量化后，HNSW 索引约 20-50 GB（300维向量 / 条）	按 IPC 国际专利分类做分区索引，召回时先粗筛分类再精排，显著降低显存占用
LLM 判官幻觉	生成式判定可能捏造"权利要求范围"，在专利审查场景造成合规风险	判官输出强制附带"引用的权利要求编号 + 原文引用片段"，无引用片段的结论不视为有效结论

数字与效率（⚠️ 原文未给出，以下为行业典型值估算）

指标	估算值	说明
单次 query 额外 LLM 调用成本	~$0.01-0.05 / query	自知识抽取（~500 token in）+ 本体构建（~300 token in/out）+ 判官（~800 token in/out）
FAISS 百万专利索引大小	~30-60 GB（HNSW, dim=768）	与向量维度强相关；dim=384 可减半
检索延迟（Top-20）	~50-200 ms（含网络 RTT）	本体扩展不增加检索延迟，因为仅改变 query embedding
本体构建延迟	~1-3 s / query	LLM 调用 + JSON 解析；是管线主要延迟来源
总体 P99 延迟	~3-5 s / query	以 GPT-4o 为 LLM 后端估算

开源组件替换建议

原论文组件	推荐替换	备注
FAISS	Milvus 2.x / Qdrant / Weaviate	Milvus 支持分区、Qdrant 支持 sparse+dense 混合检索
生成模型	GPT-4o / Claude-3.5-Sonnet / Qwen2.5-Max	选型依据：专利文本专业性高，建议用强推理模型；Qwen2.5-72B-Instruct 可私有部署
Embedding	text-embedding-3-large / BAAI/bge-m3 / GTE-Qwen2	bge-m3 支持 multi-vector（dense+sparse+colbert），对专利术语密度更友好
本体构建	Prompt + few-shot ICL（当前推断方案）	若一致率不足 80%，可微调一个 LoRA 版本的 Qwen-7B 做 ontology builder

fetch 验证优先级清单

⚠️ 原文未 fetch 的高优先级项（下次精修前必须完成）： 1. [ ] IEEE DOI 全文 PDF——补数据集名、baseline 列表、具体性能数字 2. [ ] 作者 GitHub（搜索 "Jian Zhang Self-Knowledge RAG"）——代码 / 预训练本体 / 评估脚本 3. [ ] 第三方复现——当前 0 条外部引用（v1 提交 2 天），需等待社区验证 4. [ ] 本体 schema 稳定性实验——LLM 抽取一致率是最大工程风险，需主动补测