人工智能AI AgentAgent 框架大模型工具调用RAG提示工程强化学习【免费下载链接】agent-coreopenJiuwen agent-core可提供AI Agent开发、运行、调优与演进相关的全套SDK能力项目地址https://gitcode.com/openJiuwen/agent-core点击查看免费下载本篇文章聚焦 openJiuwen agent-core 检索模块中的Extractor抽象基类位于openjiuwen.core.retrieval.indexing.processor.extractor包它定义了索引管线中从文本块抽取信息如 RDF 三元组的统一接口。通过阅读本文你将掌握Extractor的类继承关系、extract抽象方法签名与语义、上下游关键数据类型TextChunk/Triple并能基于仓库内TripleExtractor、OntologyTripleExtractor两个生产级实现理解如何编写并接入自己的抽取器为知识图谱检索与图存储索引提供三元组数据源。Extractor 在检索索引管线中的定位openJiuwen agent-core 的检索模块以文档 → 文本块 → 结构化信息的流水线方式为向量库与图存储准备数据。在 processor/base.py 中定义了所有处理器的统一抽象Processor其模块注释明确指出Base class for all processors (Parser, Chunker, Extractor).即检索索引阶段的三类核心处理器——Parser文档解析、Chunker文本切块、Extractor信息抽取——都继承自同一个Processor抽象基类。Extractor正是其中负责语义结构化的一环它把Chunker产生的纯文本块TextChunk转换成可供知识图谱存储与图检索使用的三元组Triple列表是openjiuwen.core.retrieval.indexing.processor.extractor包对外暴露的抽象根接口。Extractor 抽象基类核心 API类定义与继承关系依据 base.md 与对应源码 base.pyExtractor的完整定义为class Extractor(Processor): Extractor abstract base class (inherits from Processor, used for extracting triples, etc.)继承自Processor因此所有Extractor子类天然具备process方法契约可以统一被索引管线调用。抽象基类本身不能实例化只定义接口骨架具体抽取逻辑由子类实现。职责定位抽取三元组triples及其他信息是知识图谱数据入口的统一抽象。抽象方法 extract这是Extractor对外唯一的抽象方法其签名来自 base.md 与 base.pyabstractmethod async def extract( self, chunks: List[TextChunk], **kwargs, ) - List[Triple]:参数说明参数类型说明chunksList[TextChunk]待抽取的文本块列表例如[TextChunk(...), TextChunk(...)]通常来自Chunker的输出kwargsAny可变关键字参数用于透传额外配置如抽取模式、上下文提示等子类按需消费返回值类型为List[Triple]即抽取结果列表例如[Triple(...), Triple(...)]。语义上每个Triple表示一条 RDF 风格的主语—谓语—宾语关系可直接落入图存储。process 方法的默认实现作为对Processor抽象方法的落实Extractor还在基类层面给出了process的默认实现base.pyasync def process(self, chunks: List[TextChunk], **kwargs) - List[Triple]: return await self.extract(chunks, **kwargs)也就是说process只是对extract的薄封装。索引管线既可以直接调用extract也可以通过统一的process入口触发抽取二者行为等价保证了Parser/Chunker/Extractor在流水线中的调用方式一致。上下游关键数据类型为了正确使用Extractor需要理解它的输入与输出类型二者均定义在检索模块的 common 目录下。输入类型 TextChunkTextChunk是 Pydantic 数据模型document.py字段如下字段类型含义id_str文本块唯一 IDtextstr文本块内容doc_idstr所属父文档 IDmetadataDict[str, Any]元数据如title标题抽取时会被当作上下文embeddinglist[float] \| None文本块向量默认为None同时提供类方法TextChunk.from_document(doc, chunk_text, id_)可直接从Document生成文本块未指定id_时自动生成 UUID。输出类型 TripleTriple同样是 Pydantic 数据模型triple.py字段如下字段类型含义subjectstr主语predicatestr谓语关系objectstr宾语metadataDict[str, Any]附加元数据默认空字典在仓库的具体实现中metadata通常携带doc_id与chunk_id用于追溯每条三元组的来源文本块是图检索与溯源的关键索引信息。生产级实现一TripleExtractor通用 OpenIE 三元组抽取TripleExtractortriple_extractor.py是Extractor最直接的落地实现通过 LLM 完成开放信息抽取OpenIE并支持可选的三元组二次校验。构造函数参数如下TripleExtractor( llm_client: Any, # LLM 客户端实例需提供 invoke(messages, temperature) 能力 model_name: str, # 模型名称 temperature: float 0.0, # 采样温度默认 0.0 保证输出稳定 max_concurrent: int 50, # 最大并发数内部通过 asyncio.Semaphore 控制 validate: bool False, # 是否启用 LLM 三元组校验 **kwargs, )核心执行流程extract方法并行抽取对每个TextChunk创建 asyncio 任务调用 LLM用asyncio.Semaphore(max_concurrent)限制并发避免打爆模型服务。提示词构造_build_prompt构造 OpenIE 提示词要求模型返回严格 JSON——顶层对象必须包含named_entities与triples两个键triples中每一项是恰好三个字符串的数组提示词内置了 Magic Johnson、Elden Ring 两个完整演示样例few-shot并明确要求消解代词、保持实体/谓词与源语言一致、去除重复三元组。容错解析_parse_triples先剥离可能的 markdown 代码围栏再用json_repair库修复模型输出的残缺 JSON结构化校验通过后组装为Triple对象并写入metadata{doc_id, chunk_id}无效三元组非数组、不足三元素、含嵌套结构或 None被记录并跳过。可选校验当validateTrue时调用_validate_internal按来源 chunk 分组用_build_validation_prompt构造校验提示词要求模型仅保留文本直接支持的三元组删除依赖外部知识、日期/数字/地点不匹配或并非必然为真的三元组允许修正谓词措辞——这相当于对抽取结果做一轮基于证据的降噪。值得注意的工程细节_gather_results统一处理并发任务的异常按 chunk 顺序抛出遇到的第一个错误BaseError原样重抛普通异常则包装为RETRIEVAL_KB_TRIPLE_EXTRACTION_PROCESS_ERROR保证调用方获得稳定的错误语义。生产级实现二OntologyTripleExtractor本体约束抽取OntologyTripleExtractorontology_triple_extractor.py是面向领域约束的抽取器允许预先加载本体文件让 LLM 只在本体定义的类与属性范围内抽取实体与关系。构造函数OntologyTripleExtractor( llm_client: Any, model_name: str, ontology_name: str, # 本体名称 ontology_path: str | None None, # 本体文件路径仅支持 .nt 或 .ttl constrain_ontology: bool False, # 是否强制抽取结果遵守本体约束 temperature: float 0.0, max_concurrent: int 50, **kwargs, )与通用抽取器的关键差异本体加载与校验_load_ontology使用pyoxigraph的 RDF Store 加载 N-Triples / Turtle 文件通过 SPARQL 查询收集本体中的rdfs:Class/owl:Class类、rdf:Property/owl:ObjectProperty/owl:DatatypeProperty属性并预计算subClassOf子类映射。文件后缀不合法抛RETRIEVAL_INDEXING_FORMAT_NOT_SUPPORT文件不存在抛RETRIEVAL_INDEXING_FILE_NOT_FOUND加载失败抛RETRIEVAL_KB_ONTOLOGY_INVALID。实体抽取先实体后关系_extract_entities用_build_entity_prompt让模型从文本中识别实体输出{uri, label, class}三元结构在constrain_ontologyTrue且提供本体时提示词会把允许的类及其subclassof、comment摘要注入上下文限制模型只能使用这些类。关系抽取与属性过滤_extract_relations调用_get_valid_properties基于已抽取实体的 class 与本体中属性的 domain/range 做兼容性推理_is_compatible检查类精确匹配或存在超类传递闭包关系动态筛出当前文本可用的属性集合注入提示词实现属性级约束数据属性range 含 XMLSchema/Literal与对象属性分别处理。两阶段异步流水每个 chunk 内部先抽取实体再抽取关系多个 chunk 之间以asyncio.Semaphore并发执行gather时同样按首个异常优先抛出。可见OntologyTripleExtractor把本体文件 LLM结合将抽取结果约束到领域模式之内适合对图谱模式一致性有强要求的业务场景而TripleExtractor无需任何前置本体开箱即用适合通用知识抽取。自定义 Extractor 的实战指南基于上述抽象与实现模式在 openJiuwen agent-core 中扩展一个自定义抽取器只需三步继承Extractor实现extract(chunks: List[TextChunk], **kwargs) - List[Triple]若希望被流水线以process统一调用可保持基类默认封装不变。复用Triple与TextChunk输出时务必为每个Triple携带metadata建议写入doc_id、chunk_id参考 triple_extractor.py 的做法保证图检索可溯源。对齐并发与容错约定多 chunk 场景建议使用asyncio.Semaphore限流并对解析失败统一抛出RETRIEVAL_KB_TRIPLE_EXTRACTION_PROCESS_ERROR参考_gather_results的错误聚合策略保持与既有实现一致的错误可观测性。例如一个最小实现骨架from typing import Any, List from openjiuwen.core.retrieval.common.document import TextChunk from openjiuwen.core.retrieval.common.triple import Triple from openjiuwen.core.retrieval.indexing.processor.extractor.base import Extractor class MyExtractor(Extractor): async def extract(self, chunks: List[TextChunk], **kwargs) - List[Triple]: triples: List[Triple] [] for chunk in chunks: # 在此接入你自己的抽取逻辑规则、模型或混合方案 triples.append( Triple( subjectsubject, predicatepredicate, objectobject, metadata{doc_id: chunk.doc_id, chunk_id: chunk.id_}, ) ) return triples小结Extractor抽象基类是 openJiuwen agent-core 检索模块中知识图谱数据生产的统一接口它向上继承Processor保持流水线调用一致向下以extract(chunks, **kwargs) - List[Triple]定义抽取契约。仓库中TripleExtractor与OntologyTripleExtractor分别展示了通用 OpenIE 可选校验与本体约束 两阶段抽取两种生产级范式涉及并发限流、JSON 容错解析、领域属性推理等工程细节。理解这一抽象层即可在 agent-core 的图检索与索引链路中按需接入自己的三元组抽取实现。赞分享人工智能AI AgentAgent 框架大模型工具调用RAG提示工程强化学习【免费下载链接】agent-coreopenJiuwen agent-core可提供AI Agent开发、运行、调优与演进相关的全套SDK能力项目地址https://gitcode.com/openJiuwen/agent-core点击查看免费下载相关推荐fast_align 词对齐加速指南OpenMP 并行 tcmalloc 编译优化百万句对处理提速 4 倍fast_align 词对齐加速指南OpenMP 并行 tcmalloc 编译优化百万句对处理提速 4 倍 上周有同事把一百万条英中句对语料扔给 fas人工智能大模型AI 应用AI 写作RAG桌面应用深入理解 openJiuwen agent-core 的 Processor 抽象基类检索索引处理管道的统一接口深入理解 openJiuwen agent core 的 Processor 抽象基类检索索引处理管道的统一接口 导读 本文以 openjiuwen.cor人工智能AI AgentAgent 框架大模型工具调用RAG提示工程强化学习Data-Juicer 知识图谱构建算子 extract_entity_relation_mapper 深度解析LLM 驱动的实体与关系抽取Data Juicer 知识图谱构建算子 extract_entity_relation_mapper 深度解析LLM 驱动的实体与关系抽取 本文围绕 Dat人工智能大模型数据工程数据清洗数据增强数据质检上一篇DownKyi创新应用方案重构B站视频管理体验的专业指南下一篇哔哩下载姬终极指南如何高效下载B站8K高清视频的5大技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 openJiuwen agent-core Extractor 抽象基类解析：LLM 驱动的 RDF 三元组抽取与知识图谱索引
人工智能AI AgentAgent 框架大模型工具调用RAG提示工程强化学习【免费下载链接】agent-coreopenJiuwen agent-core可提供AI Agent开发、运行、调优与演进相关的全套SDK能力项目地址https://gitcode.com/openJiuwen/agent-core点击查看免费下载本篇文章聚焦 openJiuwen agent-core 检索模块中的Extractor抽象基类位于openjiuwen.core.retrieval.indexing.processor.extractor包它定义了索引管线中从文本块抽取信息如 RDF 三元组的统一接口。通过阅读本文你将掌握Extractor的类继承关系、extract抽象方法签名与语义、上下游关键数据类型TextChunk/Triple并能基于仓库内TripleExtractor、OntologyTripleExtractor两个生产级实现理解如何编写并接入自己的抽取器为知识图谱检索与图存储索引提供三元组数据源。Extractor 在检索索引管线中的定位openJiuwen agent-core 的检索模块以文档 → 文本块 → 结构化信息的流水线方式为向量库与图存储准备数据。在 processor/base.py 中定义了所有处理器的统一抽象Processor其模块注释明确指出Base class for all processors (Parser, Chunker, Extractor).即检索索引阶段的三类核心处理器——Parser文档解析、Chunker文本切块、Extractor信息抽取——都继承自同一个Processor抽象基类。Extractor正是其中负责语义结构化的一环它把Chunker产生的纯文本块TextChunk转换成可供知识图谱存储与图检索使用的三元组Triple列表是openjiuwen.core.retrieval.indexing.processor.extractor包对外暴露的抽象根接口。Extractor 抽象基类核心 API类定义与继承关系依据 base.md 与对应源码 base.pyExtractor的完整定义为class Extractor(Processor): Extractor abstract base class (inherits from Processor, used for extracting triples, etc.)继承自Processor因此所有Extractor子类天然具备process方法契约可以统一被索引管线调用。抽象基类本身不能实例化只定义接口骨架具体抽取逻辑由子类实现。职责定位抽取三元组triples及其他信息是知识图谱数据入口的统一抽象。抽象方法 extract这是Extractor对外唯一的抽象方法其签名来自 base.md 与 base.pyabstractmethod async def extract( self, chunks: List[TextChunk], **kwargs, ) - List[Triple]:参数说明参数类型说明chunksList[TextChunk]待抽取的文本块列表例如[TextChunk(...), TextChunk(...)]通常来自Chunker的输出kwargsAny可变关键字参数用于透传额外配置如抽取模式、上下文提示等子类按需消费返回值类型为List[Triple]即抽取结果列表例如[Triple(...), Triple(...)]。语义上每个Triple表示一条 RDF 风格的主语—谓语—宾语关系可直接落入图存储。process 方法的默认实现作为对Processor抽象方法的落实Extractor还在基类层面给出了process的默认实现base.pyasync def process(self, chunks: List[TextChunk], **kwargs) - List[Triple]: return await self.extract(chunks, **kwargs)也就是说process只是对extract的薄封装。索引管线既可以直接调用extract也可以通过统一的process入口触发抽取二者行为等价保证了Parser/Chunker/Extractor在流水线中的调用方式一致。上下游关键数据类型为了正确使用Extractor需要理解它的输入与输出类型二者均定义在检索模块的 common 目录下。输入类型 TextChunkTextChunk是 Pydantic 数据模型document.py字段如下字段类型含义id_str文本块唯一 IDtextstr文本块内容doc_idstr所属父文档 IDmetadataDict[str, Any]元数据如title标题抽取时会被当作上下文embeddinglist[float] \| None文本块向量默认为None同时提供类方法TextChunk.from_document(doc, chunk_text, id_)可直接从Document生成文本块未指定id_时自动生成 UUID。输出类型 TripleTriple同样是 Pydantic 数据模型triple.py字段如下字段类型含义subjectstr主语predicatestr谓语关系objectstr宾语metadataDict[str, Any]附加元数据默认空字典在仓库的具体实现中metadata通常携带doc_id与chunk_id用于追溯每条三元组的来源文本块是图检索与溯源的关键索引信息。生产级实现一TripleExtractor通用 OpenIE 三元组抽取TripleExtractortriple_extractor.py是Extractor最直接的落地实现通过 LLM 完成开放信息抽取OpenIE并支持可选的三元组二次校验。构造函数参数如下TripleExtractor( llm_client: Any, # LLM 客户端实例需提供 invoke(messages, temperature) 能力 model_name: str, # 模型名称 temperature: float 0.0, # 采样温度默认 0.0 保证输出稳定 max_concurrent: int 50, # 最大并发数内部通过 asyncio.Semaphore 控制 validate: bool False, # 是否启用 LLM 三元组校验 **kwargs, )核心执行流程extract方法并行抽取对每个TextChunk创建 asyncio 任务调用 LLM用asyncio.Semaphore(max_concurrent)限制并发避免打爆模型服务。提示词构造_build_prompt构造 OpenIE 提示词要求模型返回严格 JSON——顶层对象必须包含named_entities与triples两个键triples中每一项是恰好三个字符串的数组提示词内置了 Magic Johnson、Elden Ring 两个完整演示样例few-shot并明确要求消解代词、保持实体/谓词与源语言一致、去除重复三元组。容错解析_parse_triples先剥离可能的 markdown 代码围栏再用json_repair库修复模型输出的残缺 JSON结构化校验通过后组装为Triple对象并写入metadata{doc_id, chunk_id}无效三元组非数组、不足三元素、含嵌套结构或 None被记录并跳过。可选校验当validateTrue时调用_validate_internal按来源 chunk 分组用_build_validation_prompt构造校验提示词要求模型仅保留文本直接支持的三元组删除依赖外部知识、日期/数字/地点不匹配或并非必然为真的三元组允许修正谓词措辞——这相当于对抽取结果做一轮基于证据的降噪。值得注意的工程细节_gather_results统一处理并发任务的异常按 chunk 顺序抛出遇到的第一个错误BaseError原样重抛普通异常则包装为RETRIEVAL_KB_TRIPLE_EXTRACTION_PROCESS_ERROR保证调用方获得稳定的错误语义。生产级实现二OntologyTripleExtractor本体约束抽取OntologyTripleExtractorontology_triple_extractor.py是面向领域约束的抽取器允许预先加载本体文件让 LLM 只在本体定义的类与属性范围内抽取实体与关系。构造函数OntologyTripleExtractor( llm_client: Any, model_name: str, ontology_name: str, # 本体名称 ontology_path: str | None None, # 本体文件路径仅支持 .nt 或 .ttl constrain_ontology: bool False, # 是否强制抽取结果遵守本体约束 temperature: float 0.0, max_concurrent: int 50, **kwargs, )与通用抽取器的关键差异本体加载与校验_load_ontology使用pyoxigraph的 RDF Store 加载 N-Triples / Turtle 文件通过 SPARQL 查询收集本体中的rdfs:Class/owl:Class类、rdf:Property/owl:ObjectProperty/owl:DatatypeProperty属性并预计算subClassOf子类映射。文件后缀不合法抛RETRIEVAL_INDEXING_FORMAT_NOT_SUPPORT文件不存在抛RETRIEVAL_INDEXING_FILE_NOT_FOUND加载失败抛RETRIEVAL_KB_ONTOLOGY_INVALID。实体抽取先实体后关系_extract_entities用_build_entity_prompt让模型从文本中识别实体输出{uri, label, class}三元结构在constrain_ontologyTrue且提供本体时提示词会把允许的类及其subclassof、comment摘要注入上下文限制模型只能使用这些类。关系抽取与属性过滤_extract_relations调用_get_valid_properties基于已抽取实体的 class 与本体中属性的 domain/range 做兼容性推理_is_compatible检查类精确匹配或存在超类传递闭包关系动态筛出当前文本可用的属性集合注入提示词实现属性级约束数据属性range 含 XMLSchema/Literal与对象属性分别处理。两阶段异步流水每个 chunk 内部先抽取实体再抽取关系多个 chunk 之间以asyncio.Semaphore并发执行gather时同样按首个异常优先抛出。可见OntologyTripleExtractor把本体文件 LLM结合将抽取结果约束到领域模式之内适合对图谱模式一致性有强要求的业务场景而TripleExtractor无需任何前置本体开箱即用适合通用知识抽取。自定义 Extractor 的实战指南基于上述抽象与实现模式在 openJiuwen agent-core 中扩展一个自定义抽取器只需三步继承Extractor实现extract(chunks: List[TextChunk], **kwargs) - List[Triple]若希望被流水线以process统一调用可保持基类默认封装不变。复用Triple与TextChunk输出时务必为每个Triple携带metadata建议写入doc_id、chunk_id参考 triple_extractor.py 的做法保证图检索可溯源。对齐并发与容错约定多 chunk 场景建议使用asyncio.Semaphore限流并对解析失败统一抛出RETRIEVAL_KB_TRIPLE_EXTRACTION_PROCESS_ERROR参考_gather_results的错误聚合策略保持与既有实现一致的错误可观测性。例如一个最小实现骨架from typing import Any, List from openjiuwen.core.retrieval.common.document import TextChunk from openjiuwen.core.retrieval.common.triple import Triple from openjiuwen.core.retrieval.indexing.processor.extractor.base import Extractor class MyExtractor(Extractor): async def extract(self, chunks: List[TextChunk], **kwargs) - List[Triple]: triples: List[Triple] [] for chunk in chunks: # 在此接入你自己的抽取逻辑规则、模型或混合方案 triples.append( Triple( subjectsubject, predicatepredicate, objectobject, metadata{doc_id: chunk.doc_id, chunk_id: chunk.id_}, ) ) return triples小结Extractor抽象基类是 openJiuwen agent-core 检索模块中知识图谱数据生产的统一接口它向上继承Processor保持流水线调用一致向下以extract(chunks, **kwargs) - List[Triple]定义抽取契约。仓库中TripleExtractor与OntologyTripleExtractor分别展示了通用 OpenIE 可选校验与本体约束 两阶段抽取两种生产级范式涉及并发限流、JSON 容错解析、领域属性推理等工程细节。理解这一抽象层即可在 agent-core 的图检索与索引链路中按需接入自己的三元组抽取实现。赞分享人工智能AI AgentAgent 框架大模型工具调用RAG提示工程强化学习【免费下载链接】agent-coreopenJiuwen agent-core可提供AI Agent开发、运行、调优与演进相关的全套SDK能力项目地址https://gitcode.com/openJiuwen/agent-core点击查看免费下载相关推荐fast_align 词对齐加速指南OpenMP 并行 tcmalloc 编译优化百万句对处理提速 4 倍fast_align 词对齐加速指南OpenMP 并行 tcmalloc 编译优化百万句对处理提速 4 倍 上周有同事把一百万条英中句对语料扔给 fas人工智能大模型AI 应用AI 写作RAG桌面应用深入理解 openJiuwen agent-core 的 Processor 抽象基类检索索引处理管道的统一接口深入理解 openJiuwen agent core 的 Processor 抽象基类检索索引处理管道的统一接口 导读 本文以 openjiuwen.cor人工智能AI AgentAgent 框架大模型工具调用RAG提示工程强化学习Data-Juicer 知识图谱构建算子 extract_entity_relation_mapper 深度解析LLM 驱动的实体与关系抽取Data Juicer 知识图谱构建算子 extract_entity_relation_mapper 深度解析LLM 驱动的实体与关系抽取 本文围绕 Dat人工智能大模型数据工程数据清洗数据增强数据质检上一篇DownKyi创新应用方案重构B站视频管理体验的专业指南下一篇哔哩下载姬终极指南如何高效下载B站8K高清视频的5大技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考