拓冰网站定制 
有没有想过一个问题本体论有一半的篇幅在讨论如何定义标准数据和数据间的关系之所以要这么做就是需要为所有的分析和Action提供精准的上下文。所以这实质上是一个高纬度的RAG问题。只不过普通RAG搜索的目标大多包含大量的文本对象而Ontology操作的目标倾向于数据库对象。这就意味着我们可以参照为RAG设计的系统实现来设计Ontology的数据层面。比如这次介绍的SAG(Structured Aggregated Graph)就是一个很好的参考。在回答复杂问题时通过向量匹配搜索出来的chunk往往是不够的因为有很多隐含条件并没有体现在字面上所以我们需要relation来进行关联查找字面上没有的实体。SAG通过relation和向量结合的方式进行召回和rerank在多跳问答的数据集验证里取得了炸裂的成绩。核心是不维护重型知识图谱而是建立三种轻量索引chunk → event、event ↔ entities、chunk → entities用双存储协同 多跳扩展弥补单靠向量检索无法覆盖的多跳场景。索引方式SAG将一个chunk拆成了三个部分事件、实体和关系。事件是对chunk的摘要实体是从事件中提取出的主体关系则是事件与实体间建立的联系。对于每一个chunk让LLM提取事件和实体并且建立联系。这就类似于一个图两个事件之间如果存在相同的实体这两个事件便产生了关联。进行索引的是一个五步流程chunks → processor(LLM调用) → filter(过滤) → parser(解析) → saver(持久化)每个 chunk 经一次 LLM 调用融合成恰好一个自包含事件 若干实体。这与传统一句一三元组完全不同。对chunk的提取产生了两大种类的成果结构化数据和向量化数据。MySQL: 通过event和entity的id进行关联负责精确关系遍历用于Step3 通道1entity→event、Step5 多跳扩展、Step8 chunk 回溯ES: 存储event向量负责模糊语义召回 打分用于Step2 实体召回、Step3 通道2、Step6 粗排。结构化数据存储在MySQL中通过id记录了event/entity之间的关系可以通过entity_id进行精确的关联查询stmt select(EventEntity.event_id).where(EventEntity.entity_id.in_(entity_ids) # 精确 JOIN ).join(SourceEvent...).where(source_config_id.in_(...))向量化数据存储在ES中供向量搜索用ES 索引向量来源用途event_vectors事件标题、titlecontent分别 embed事件语义召回entity_vectorsentity.nameembed实体向量召回NER 命中后找相似实体event_entity_vectorsEventEntity.descriptionembed关联关系检索检索8 步pipline的逐层职责步骤职责存储关键参数Step1NERquery → 实体名LLMmulti/ BM25multi_es—Step2实体召回实体名 → entity_idsESentity_vectorstop_k20, 阈值 0.9Step3双通道召回召回初始事件MySQL JOIN ES kNNk20入口窄Step4事件详情取 content 关联 entitiesMySQL / ES—Step5多跳扩展沿实体图遍历补全桥梁 docMySQL JOIN / ES 反查max_hops1默认Step6粗排向量相似度去噪打分ES kNNmax_events1005倍冗余Step7LLM 精选多跳推理选 top_kLLMtop_k5/10不看分数Step8chunk 回溯event → 原始 chunkMySQLchunk_id 去重多跳扩展解决语义断裂问题多跳问答里答案 doc 与 query 可能语义不相关query 里没有答案实体的字面。纯向量检索召回不到这类 doc。Step5 多跳扩展沿 entity↔event 关系图遍历把图可达但语义远的 doc 拉进候选池。基于真实 MuSiQue 4 跳样本的验证hopgold doc 的 query 语义相关性召回方式hop1query 含实体高Step3 向量直接召回hop2中间桥梁极低主题域不交叉只能靠 Step5 图遍历hop3-4中-高向量 图遍历互补Step3k20与 Step6max100的 5 倍冗余Step3 入口窄k20严苛语义筛选 ↓ Step5 多跳注入绕过相似度图可达性注入 ↓ Step6 缓冲池宽max1005倍冗余给注入doc留存活空间 ↓ Step7 LLM 不看分数候选池内一律平等靠推理选其实相当于在做向量搜索时用K20限制了向量召回的数量把一部分空间留给了用MySQL做精确关联的event。然后再将双搜索召回的event放到一起做rerank。这里做rerank也很有意思用的LLM而非简单的reranker。Step7 用 LLM 而非 reranker是任务定义不同方面传统 rerankerSAG Step7任务query-doc 语义匹配度doc 对多跳推理链的贡献度能力相似度打分理解 “First find X, then find Y”成本毫秒级秒级万 token 量级Reranker 无法识别跟 query 不像但是推理链必经桥梁的 docLLM 能。简单的说就是把这100条召回的event依次再让LLM判断一遍哪个event对回答问题更有作用。当然也提供了fast 模式multi_es用数值公式替代 LLM用来节约时间和成本。在RAG上存在的问题文档格式强依赖SAG 的 Load 模块只接受 markdown且 heading_strict 切分强依赖 ATX 风格标题#定义 chunk 边界。无标题、非 markdown 格式PDF/Word/HTML会致命。甚至可以说SAG的Load就只能处理结构清晰的数据否则很容易GG。benchmark 数据集 corpus 是干净的title/text 齐全回避了生产场景的格式预处理问题。真实部署需要额外的格式转换层。图遍历与向量打分的固有张力多跳扩展靠图可达性召回Step6 靠向量相似度排序——这两者之间可能根本不相关。深跳3-4 跳的答案可能在向量上几乎不相关于是在 Step6 被 100 名截断淘汰的可能性也大。这是 SAG 架构的固有代价也是 MuSiQue48% 是 3-4 跳比 HotpotQA 更难的根本原因。只说三件事成本、成本还**是成本抽取和检索数据时都需要调用LLM产生的成本是普通RAG的数倍。阶段每次 input token 量级抽取每个 chunk ~500-2000 token system prompt few-shot检索NER 较小rerank 100 候选 × ~200 token ~20000 token基于SAG的语义层如果我们用图数据库来定义本体间关系常见的就是将两张表定义为两个本体然后用某种关系相连接。但是在两个本体间可能有多种关联关系。从数据上可能有外键进行关联从其它方面可能会有某些维度字段进行关联比如城市、商品类目。正常情况下使用图数据库建模都不建议在两个节点中直接定义多个关系要么通过造出中间节点进行处理要么通过专门的查询条件避免笛卡尔积。而参考SAG的构建方式每条数据我们认为是一个chunk/event关联字段是SAG中的实体那么就可以自然的建立多种关系。但是注意我们不能采用LLM来处理数仓中的每一行数据那样token的费用可能比整个数据团队的工资还高。经过取舍和测试我推荐一种结合wiki和cube的方式进行多层结构混合存储与检索描述如下为每张表建立一个wiki详细的描写表的内容、业务含义、适用场景、可能的关联关系等这个wiki作为一个chunk提取其event和entity入MySQL和ES按照cube的标准定义关联字段、视图等使用SAG的检索流程进行相关表检索综合表、wiki、cube定义生成一个/多个SQL语句进行查询和聚合并且生成答案。简答的是说就是用户 query ↓ 查询意图分类LLM ├── 明细查询 → SAG 检索召回行 ├── 聚合查询 → CubeSQL生成 SQL └── 混合查询 → SAG 召回 SQL 聚合但是在工程实践中还有很多落地的方面需要进行处理比如多个表的同义entity如何保证如果分解query需求解答用户或者其它系统问题时是否采用ReAct模型多步检索等等。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 本体论语义建设新思路，另类RAG来解决检索问题
有没有想过一个问题本体论有一半的篇幅在讨论如何定义标准数据和数据间的关系之所以要这么做就是需要为所有的分析和Action提供精准的上下文。所以这实质上是一个高纬度的RAG问题。只不过普通RAG搜索的目标大多包含大量的文本对象而Ontology操作的目标倾向于数据库对象。这就意味着我们可以参照为RAG设计的系统实现来设计Ontology的数据层面。比如这次介绍的SAG(Structured Aggregated Graph)就是一个很好的参考。在回答复杂问题时通过向量匹配搜索出来的chunk往往是不够的因为有很多隐含条件并没有体现在字面上所以我们需要relation来进行关联查找字面上没有的实体。SAG通过relation和向量结合的方式进行召回和rerank在多跳问答的数据集验证里取得了炸裂的成绩。核心是不维护重型知识图谱而是建立三种轻量索引chunk → event、event ↔ entities、chunk → entities用双存储协同 多跳扩展弥补单靠向量检索无法覆盖的多跳场景。索引方式SAG将一个chunk拆成了三个部分事件、实体和关系。事件是对chunk的摘要实体是从事件中提取出的主体关系则是事件与实体间建立的联系。对于每一个chunk让LLM提取事件和实体并且建立联系。这就类似于一个图两个事件之间如果存在相同的实体这两个事件便产生了关联。进行索引的是一个五步流程chunks → processor(LLM调用) → filter(过滤) → parser(解析) → saver(持久化)每个 chunk 经一次 LLM 调用融合成恰好一个自包含事件 若干实体。这与传统一句一三元组完全不同。对chunk的提取产生了两大种类的成果结构化数据和向量化数据。MySQL: 通过event和entity的id进行关联负责精确关系遍历用于Step3 通道1entity→event、Step5 多跳扩展、Step8 chunk 回溯ES: 存储event向量负责模糊语义召回 打分用于Step2 实体召回、Step3 通道2、Step6 粗排。结构化数据存储在MySQL中通过id记录了event/entity之间的关系可以通过entity_id进行精确的关联查询stmt select(EventEntity.event_id).where(EventEntity.entity_id.in_(entity_ids) # 精确 JOIN ).join(SourceEvent...).where(source_config_id.in_(...))向量化数据存储在ES中供向量搜索用ES 索引向量来源用途event_vectors事件标题、titlecontent分别 embed事件语义召回entity_vectorsentity.nameembed实体向量召回NER 命中后找相似实体event_entity_vectorsEventEntity.descriptionembed关联关系检索检索8 步pipline的逐层职责步骤职责存储关键参数Step1NERquery → 实体名LLMmulti/ BM25multi_es—Step2实体召回实体名 → entity_idsESentity_vectorstop_k20, 阈值 0.9Step3双通道召回召回初始事件MySQL JOIN ES kNNk20入口窄Step4事件详情取 content 关联 entitiesMySQL / ES—Step5多跳扩展沿实体图遍历补全桥梁 docMySQL JOIN / ES 反查max_hops1默认Step6粗排向量相似度去噪打分ES kNNmax_events1005倍冗余Step7LLM 精选多跳推理选 top_kLLMtop_k5/10不看分数Step8chunk 回溯event → 原始 chunkMySQLchunk_id 去重多跳扩展解决语义断裂问题多跳问答里答案 doc 与 query 可能语义不相关query 里没有答案实体的字面。纯向量检索召回不到这类 doc。Step5 多跳扩展沿 entity↔event 关系图遍历把图可达但语义远的 doc 拉进候选池。基于真实 MuSiQue 4 跳样本的验证hopgold doc 的 query 语义相关性召回方式hop1query 含实体高Step3 向量直接召回hop2中间桥梁极低主题域不交叉只能靠 Step5 图遍历hop3-4中-高向量 图遍历互补Step3k20与 Step6max100的 5 倍冗余Step3 入口窄k20严苛语义筛选 ↓ Step5 多跳注入绕过相似度图可达性注入 ↓ Step6 缓冲池宽max1005倍冗余给注入doc留存活空间 ↓ Step7 LLM 不看分数候选池内一律平等靠推理选其实相当于在做向量搜索时用K20限制了向量召回的数量把一部分空间留给了用MySQL做精确关联的event。然后再将双搜索召回的event放到一起做rerank。这里做rerank也很有意思用的LLM而非简单的reranker。Step7 用 LLM 而非 reranker是任务定义不同方面传统 rerankerSAG Step7任务query-doc 语义匹配度doc 对多跳推理链的贡献度能力相似度打分理解 “First find X, then find Y”成本毫秒级秒级万 token 量级Reranker 无法识别跟 query 不像但是推理链必经桥梁的 docLLM 能。简单的说就是把这100条召回的event依次再让LLM判断一遍哪个event对回答问题更有作用。当然也提供了fast 模式multi_es用数值公式替代 LLM用来节约时间和成本。在RAG上存在的问题文档格式强依赖SAG 的 Load 模块只接受 markdown且 heading_strict 切分强依赖 ATX 风格标题#定义 chunk 边界。无标题、非 markdown 格式PDF/Word/HTML会致命。甚至可以说SAG的Load就只能处理结构清晰的数据否则很容易GG。benchmark 数据集 corpus 是干净的title/text 齐全回避了生产场景的格式预处理问题。真实部署需要额外的格式转换层。图遍历与向量打分的固有张力多跳扩展靠图可达性召回Step6 靠向量相似度排序——这两者之间可能根本不相关。深跳3-4 跳的答案可能在向量上几乎不相关于是在 Step6 被 100 名截断淘汰的可能性也大。这是 SAG 架构的固有代价也是 MuSiQue48% 是 3-4 跳比 HotpotQA 更难的根本原因。只说三件事成本、成本还**是成本抽取和检索数据时都需要调用LLM产生的成本是普通RAG的数倍。阶段每次 input token 量级抽取每个 chunk ~500-2000 token system prompt few-shot检索NER 较小rerank 100 候选 × ~200 token ~20000 token基于SAG的语义层如果我们用图数据库来定义本体间关系常见的就是将两张表定义为两个本体然后用某种关系相连接。但是在两个本体间可能有多种关联关系。从数据上可能有外键进行关联从其它方面可能会有某些维度字段进行关联比如城市、商品类目。正常情况下使用图数据库建模都不建议在两个节点中直接定义多个关系要么通过造出中间节点进行处理要么通过专门的查询条件避免笛卡尔积。而参考SAG的构建方式每条数据我们认为是一个chunk/event关联字段是SAG中的实体那么就可以自然的建立多种关系。但是注意我们不能采用LLM来处理数仓中的每一行数据那样token的费用可能比整个数据团队的工资还高。经过取舍和测试我推荐一种结合wiki和cube的方式进行多层结构混合存储与检索描述如下为每张表建立一个wiki详细的描写表的内容、业务含义、适用场景、可能的关联关系等这个wiki作为一个chunk提取其event和entity入MySQL和ES按照cube的标准定义关联字段、视图等使用SAG的检索流程进行相关表检索综合表、wiki、cube定义生成一个/多个SQL语句进行查询和聚合并且生成答案。简答的是说就是用户 query ↓ 查询意图分类LLM ├── 明细查询 → SAG 检索召回行 ├── 聚合查询 → CubeSQL生成 SQL └── 混合查询 → SAG 召回 SQL 聚合但是在工程实践中还有很多落地的方面需要进行处理比如多个表的同义entity如何保证如果分解query需求解答用户或者其它系统问题时是否采用ReAct模型多步检索等等。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】