直接将原始语料输入给LLM进行知识图谱构建的话，还是会因为幻觉产生不准确的实体，以及模糊或者错误关系。《LLMs for Knowledge Graph Construction and Reasoning: Recent Capabilities and Future Opportunities》中指出LLM更适合作为推理工具而不是少样本信息抽取器。

借鉴《Automated Construction of Theme-specific Knowledge Graphs》的思路，可以先定义好参数的顶层骨架，或者说是实体的类型层，比如：

  • InnoDBParameter
  • OptimizerParameter
  • BinlogParameter
  • MemoryParameter
  • IOParameter
  • ThreadParameter
    上面这些是参数的子类别，接下来将资源，硬件，指标等也进行实体定义
  • Metric
  • WorkloadPattern
  • Resource
  • StorageEngine
  • Version
  • Symptom
  • TuningGoal
  • Risk

将实体类别定义好之后，再让模型从文本中抽取出这些实体。
对于实体之间关系的抽取，这篇论文中同样也有一个值得借鉴的思路：
实体实例之间可能成立的关系，是它们所属类别之间可能关系的子集

比如：(Parameter, Metric)参数与指标之间可以有以下关系：
improves / degrades / increases / reduces / stabilizes / destabilizes / has_limited_effect_on

(Parameter, Parameter)参数与参数之间也可以有以下关系：
depends_on / interacts_with / overlaps_with / conflicts_with / only_effective_when / jointly_affects

这样后面做具体抽取时，模型面对
(innodb_flush_log_at_trx_commit=1, ?, durability)
它只能在 favors / improves / trades_off_with … 这类集合里选，而不会乱产出 is、has 这种废关系。

关系还可以有一些属性，比如关系的置信度，或者关系的来源（是从哪个文本中抽取的），关系的生效条件，把这些也建模出来，升级成六元组（head, relation, tail, confidence, source, condition）而不是三元组（head, relation, tail），这样就能更好地评估和利用这些关系了。

对于如何将原始语料输入给模型进行抽取，我认为主要是解决上下文长度问题，不可能将所有文本一次性输入给模型。
《Tree-KG: An Expandable Knowledge Graph Construction Framework for Knowledge-intensive Domains》中提到可以利用文档本身的目录结构进行树级别的提取，那么这个思路就和Dbot中提到的基于摘要树的知识提取很像了，后面可以深入了解一下Dbot源码,看看它是怎么实现的。

Dbot中的知识抽取最终是转化成知识块，通过构建带摘要的目录树，

这取决于使用的原始语料，Dbot本来使用的语料文档就侧重于数据库异常诊断 / 根因分析，甚至更偏向索引、SQL、执行计划，而不是参数

1774265767056