大语言模型在文本生成和推理上的表现有目共睹，但对于从非结构化文本构建可靠知识图谱这件事，依然是个老大难。这个问题的根源在于：语言模型的运作机制与结构化知识提取的需求之间存在本质性的错位。

本文会介绍自动化知识图谱生成的核心难题：生成式模型为什么搞不定结构化提取，判别式方案能提供什么样的替代选择，生产级知识图谱的质量标准又是什么。

语言模型在知识图谱提取上栽跟头的原因

即使是当前最顶尖的模型，在结构化提取上也会翻车。这事儿不只是幻觉问题，而是语言模型生成文本的方式和知识图谱的需求之间存在根本性冲突。

生成式模型构建知识图谱时会有一连串的麻烦：实体消歧首当其冲，同一个实体换个说法出现，模型就可能认不出来，遗漏共指关系直接导致图谱碎片化；组合实体也很麻烦"墨西哥城"这种术语涉及嵌套概念（城市和国家），需要层级化表示；规模一大幻觉问题就压不住了，概率生成会编造出看着挺像那么回事但纯属虚构的实体和关系，在需要分段处理的长文本里这个问题尤其突出；还有上下文依赖，很多实体之间的关联只有看到完整文档才说得通，但把整个文档丢进去又会放大幻觉率。

吧i如说法律文档分析中，单个段落里模型把"甲方"识别成一个实体，转头又把"前述当事人"当成另一个实体——它们分明是同一个组织。这种段落级别的碎片化让生成的图谱噪声满满，导致后处理的工作量相当可观。

有人尝试切小文本块来压制幻觉，但是会出现关系丢失和实体重复。段落级别就已经有问题了——重要的实体关联可能跨越多个句子，激进地切到句子级别会把这些依赖关系彻底打碎。推理成本还会上去因为模型得跑好几遍才能处理完同样的内容。

上下文丢失随着窗口缩小而加剧。段落级别已经有麻烦，句子级别只会更糟

生成式架构的这些局限性引出一个问题：有没有更适合结构化提取的模型类型？

判别式模型 vs 生成式模型

判别式语言模型——基于掩码语言建模训练的双向注意力模型——在知识图谱提取上提供了一条不同的路径。

优势从何而来？判别式模型天生擅长 Token 和序列分类。命名实体识别可以直接建模为输入序列上的 Token 级分类任务，生成步骤压根不需要。

命名实体检测作为 Token 分类处理，根本不走生成流程

架构上的契合让判别式模型不仅在结构化提取上更准，效率也足够支撑边缘部署——一个 BERT 模型在普通硬件上就能跑，DeepSeek 可不行。

但是判别式模型需要在领域数据上做针对性微调，效果比生成式模型的用法强；生成式模型靠 Prompt 和少样本示例就能适应新任务，不用额外训练。

不管选那种方法成功的提取都得从扎实的基础开始。学术上管这个叫"断言知识图谱"（asserted knowledge graphs），它代表源文本的基准真值。需要迭代优化的时候，这个基础的价值就体现出来了。

断言知识图谱：可验证的基础

断言知识图谱只表示源文本里明确说了的东西——不做推理，不引入外部知识，有什么记什么。源就是文本本身，这个图谱就是该文档的可验证基准。

构建断言知识图谱涉及三个核心任务：实体识别负责找出人名、组织、日期、领域术语等关键片段并归类；关系提取要发现实体之间明确表达的连接；共指消解则是把指向同一实体的不同说法归并到一个节点上。

这些任务恰好落在判别式模型擅长的 Token 和序列分类范畴内，所以基于 BERT 的专用系统通常会分开处理它们。

但这种顺畅的流水线方法有个要命的问题：

这些任务通常串行执行：先提取实体，再检测关系，最后做共指消解。多阶段流水线的问题在于每一步都会积累误差。

实体识别 90% 准确率，关系提取 90% 准确率，乘起来只剩 81%，误差传播是现代方法转向端到端模型的直接原因

单个语言模型一次性生成完整图谱结构，可以规避链式专用模型的复合失败。哪怕每个专用组件在各自的子任务上表现更好，端到端方案的整体效果往往更优。

断言知识图谱是可验证的基线。下游任务需要额外信息，比如隐式关系、外部知识库连接、领域特定增强的时候，扩展是在可信基础上进行，不用质疑整个图谱的有效性。

生产系统里这一点至关重要。可解释性和调试都依赖于一个前提：知道哪些信息直接来自源文本，哪些来自推理或增强。

不过，光有这个可验证基础对很多实际应用来说还不够，还需要增强策略。

断言知识图谱的增强

断言知识图谱本身往往撑不起实际应用。从法律文档提取基准真相之后，反复碰到三个根本性限制：图谱里经常有孤立的实体簇，没有连接路径，遍历性很差；真实文档假设了一堆没明说的共享上下文，这部分隐式知识缺失严重；实体需要规范化到更广的知识库才能做下游集成，外部对齐需求绕不开。

这些缺口需要有针对性的增强策略来补。

下游任务经常能从一些易于自动生成的直观关系中获益，比如说"是一个"、"位于"、"属于"之类的词语。

层级关系的价值是非常大的，添加分类学连接可以把实体组织成本体论结构，比如建立 [雇佣合同, 是一个, 法律合同] 或 [甲方, 是一个, 公司]，扁平的实体列表就变成了可导航的层级。

生成式语言模型在受限于预定义关系词汇表时可以胜任这种增强。放开限制的话幻觉风险会上升，而且模型容易退化成通用常识里那套标准层级关系丢失领域特异性。

基于规则的增强

逻辑规则是另一条路，从已有模式推断新事实，利用简单规则比如"如果实体 A 雇佣实体 B那么实体 A 是一个组织"可以把领域知识显式编码进去。

多跳规则能支撑更复杂的推理："案件 A 违反了第 5 条，第 5 条属于法规 R，那么案件 A 也违反了法规 R。"链式推理可以大幅提升图谱连通性揭示隐式关系。

但是代价是基于规则的增强需要领域专家来定义有效的推理模式

规则不会泛化到专家编码之外的地方，但也不会编造出无效关系。正确性压倒一切的场景里这份可靠性非常靠谱的。

链接预测与知识库对齐

另外一种思路是在现有实体集里识别缺失关系，不加新节点就能提升图谱连通性。实现方式是在领域特定知识库上训练链接预测模型。

模型在 [实体 A — 关系 — 实体 B] 三元组上训练，学会判断任意两个实体之间是否存在关系，存在的话是什么类型

生成式语言模型也能通过 Prompt 预测缺失关系，不过幻觉风险更高，需要严格界定有效关系子集。

保留源上下文

还有一种增强方式是保留原始源结构。

创建代表文本片段的节点，句子、段落或整篇文档。实现方式有两种：把这些节点连接到相关实体上以提升整体连通性，或者构建嵌套层级，让高层文本节点包含从其内容中提取的子图

这种增强不会引入事实错误，因为表示的是源里实际存在的东西不是推断出来的新知识。

实体在多个上下文里出现时，来源节点能揭示单个实体连接里看不到的使用模式和语义关系。任何实体或关系都可以追溯到精确的源位置，不仅知道提取了什么还知道它来自哪里、出现在什么语境下。

更简单的实现可以在图谱构建期间直接在实体和关系节点上存源元数据（文档 ID、句子位置），省掉额外结构节点的开销。选择用元数据还是显式节点，取决于下游任务是否需要把文本片段本身当作可查询的图谱实体来处理。

主题聚类提升连通性

孤立组件对图谱遍历和全局查询始终是个问题，基于主题的聚类通过创建桥接节点来连接相关实体。

直接的做法是用预定义类别：在领域特定主题上训练分类模型（法律文档的话就是"劳动法"、"知识产权"、"合同纠纷"之类），然后创建主题节点，把每个类别下文档里的所有实体连起来。

这种方法可解释性好，对分类体系稳定的领域很适用

GraphRAG 这类更复杂的方案用层级社区检测算法在多个粒度上自动发现实体簇，计算开销会大一些。

用预定义分类还是自动发现，需要看领域是有成熟类别体系还是更适合新兴模式检测。

增强策略的选择

这里有一个最简单和直接的方案：用同一个生成式模型从基准真相图谱和原始文本中推断隐式实体和关系。

这种增强策略限定在预定义关系类型范围内，产生的知识图谱有效捕获了下游 GNN 分类任务所需的语义结构。

最优增强策略完全取决于下游应用。需要跨孤立组件做复杂推理的任务，聚类技术提供必要的连通性

分类或以实体为中心的任务，选择性推断隐式知识可能就够了。正确性优先于覆盖率的高风险领域，基于规则的方法保证可靠性。

增强前：

"甲方"（实体）

"雇佣合同"（实体）

添加分类学关系后：

"甲方" → [是一个] → "公司" → [是一个] → "法律实体"

"雇佣合同" → [是一个] → "法律合同" → [是一个] → "文档"

反复试下来会发现，最有效的方案往往不是直觉上那个：从断言基础开始，迭代增强，直到图谱能服务于预期目的。

总结

知识图谱提取的核心矛盾在于：语言模型擅长生成流畅文本，却不擅长输出结构化、一致、可验证的知识表示。理解这一点，才能做出正确的技术选型。

判别式模型在精度和效率上占优，但需要领域微调；生成式模型灵活性强，却要承担幻觉和碎片化的代价。两者并非非此即彼，关键是明确下游任务的需求。

断言知识图谱作为可验证基础的价值不可替代。在此之上叠加增强策略——分类学扩展、规则推理、链接预测、源上下文保留、主题聚类——根据应用场景组合使用，才能构建出真正可用的生产级知识图谱。

https://avoid.overfit.cn/post/767c139e559b44d0b467a925d5384841

作者：Fabio Yáñez Romero

前言

最近在做一个 Java 项目的时候，遇到了一个让人头疼的问题：在 Windows 上开发的时候，中文字符显示正常，但部署到 Linux 服务器上就变成乱码了。刚开始以为是数据库的问题，检查了数据库字符集也没问题。后来才发现，原来是不同系统的默认编码不一致导致的。

相信很多开发者都遇到过类似的问题：代码里写的中文，在不同环境下显示不一样；从数据库读取的数据，有时候是乱码；日志文件里的中文显示不正常。这些问题虽然看起来简单，但如果不了解字符编码的原理，可能会折腾很久。今天我们就来聊聊字符编码问题的原因和解决方案。

问题背景

字符编码问题是一个很常见但又容易被忽视的问题。不同的系统、不同的环境，默认的字符编码可能不一样，这就导致了各种乱码问题。

为什么会出现编码问题

现在的计算机系统，底层都是使用二进制来存储数据的。但我们在屏幕上看到的文字，比如中文、英文、日文等，都是字符。要把字符转换成二进制存储，就需要用到字符编码。

常见的字符编码：

• ASCII：最早的字符编码，只能表示 128 个字符，主要是英文字母、数字和一些符号
• GBK/GB2312：中文编码，Windows 系统默认使用
• UTF-8：现在最流行的编码，可以表示世界上所有的字符，跨平台兼容性好

问题根源：

不同系统默认的字符编码不一样：

• Windows 系统默认使用 GBK 或 GB2312
• Linux 系统默认使用 UTF-8
• Mac 系统默认使用 UTF-8

如果你的代码在 Windows 上开发（默认 GBK），但部署到 Linux 服务器上（默认 UTF-8），就可能出现乱码问题。

常见的乱码场景

在实际开发中，我们经常会遇到这些乱码场景：

场景一：文件读取乱码

从文件读取数据时，如果文件的编码和读取时使用的编码不一致，就会出现乱码。比如文件是 UTF-8 编码的，但用 GBK 编码去读取，中文就会变成乱码。

场景二：数据库存储乱码

数据库的字符集设置不对，或者连接数据库时没有指定正确的字符集，存储和读取的数据就可能出现乱码。

场景三：日志输出乱码

程序输出的日志，如果控制台的编码设置不对，或者日志文件的编码不对，中文日志就会显示成乱码。

场景四：网络传输乱码

不同系统之间通过网络传输数据时，如果编码不一致，接收到的数据可能就是乱码。

解决方案一：统一使用 UTF-8

解决字符编码问题最根本的方法，就是统一使用 UTF-8 编码。UTF-8 是目前最流行的字符编码，几乎所有的现代系统都支持，而且可以表示世界上所有的字符。

为什么选择 UTF-8

UTF-8 有很多优点：

1. 兼容性好：几乎所有的系统、浏览器、数据库都支持 UTF-8
2. 国际化支持：可以表示世界上所有的字符，包括中文、日文、韩文、阿拉伯文等
3. 向后兼容：对于 ASCII 字符，UTF-8 编码和 ASCII 编码完全一样
4. 变长编码：英文字符只占 1 个字节，中文字符占 3 个字节，比较节省空间

如何在项目中统一使用 UTF-8

代码文件编码：

确保所有的源代码文件都使用 UTF-8 编码保存。在 IDE 中，可以设置默认的文件编码：

• IntelliJ IDEA：File → Settings → Editor → File Encodings，将 Project Encoding 和 Default encoding for properties files 都设置为 UTF-8
• Eclipse：Window → Preferences → General → Workspace，将 Text file encoding 设置为 UTF-8
• VS Code：在设置中搜索 "files.encoding"，设置为 UTF-8

配置文件编码：

配置文件（如 properties、xml、json 等）也要使用 UTF-8 编码。特别是 properties 文件，如果包含中文，必须使用 UTF-8 编码，否则会出现乱码。

资源文件编码：

资源文件（如国际化文件、模板文件等）也要使用 UTF-8 编码。

解决方案二：设置 JVM 参数

在 Java 项目中，JVM 的默认字符编码可能会影响程序的运行。如果 JVM 的默认编码不是 UTF-8，可能会导致文件读写、网络传输等操作出现乱码。

设置 JVM 参数

在启动 Java 程序时，可以通过 JVM 参数来设置字符编码：

java -Dfile.encoding=UTF-8 -jar your-app.jar

这个参数会告诉 JVM，文件系统的默认编码是 UTF-8。

在 IDE 中设置

如果你在 IDE 中运行程序，也需要设置 JVM 参数：

IntelliJ IDEA：

1. 点击 Run → Edit Configurations
2. 选择你的运行配置
3. 在 VM options 中输入：-Dfile.encoding=UTF-8
4. 点击 Apply 和 OK

Eclipse：

1. 右键项目 → Run As → Run Configurations
2. 选择你的运行配置
3. 在 Arguments 标签页的 VM arguments 中输入：-Dfile.encoding=UTF-8
4. 点击 Apply 和 Run

在代码中设置

除了 JVM 参数，也可以在代码中设置系统属性：

System.setProperty("file.encoding", "UTF-8");

但这种方式不推荐，因为有些代码可能在设置之前就已经读取了系统属性。

验证编码设置

可以通过代码来验证当前的编码设置：

System.out.println("默认字符编码: " + System.getProperty("file.encoding"));
System.out.println("控制台编码: " + System.getProperty("console.encoding"));

如果输出不是 UTF-8，说明设置没有生效。

解决方案三：数据库字符集设置

数据库的字符集设置也很重要，如果数据库的字符集不对，存储和读取的数据就可能出现乱码。

MySQL 字符集设置

创建数据库时设置字符集：

CREATE DATABASE mydb 
DEFAULT CHARACTER SET utf8mb4 
DEFAULT COLLATE utf8mb4_unicode_ci;

utf8mb4 是 MySQL 中真正的 UTF-8 编码，可以存储所有的 Unicode 字符，包括 emoji 表情。而 MySQL 的 utf8 实际上只支持最多 3 字节的字符，不支持 emoji。

创建表时设置字符集：

CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

修改现有数据库字符集：

如果数据库已经创建，可以修改字符集：

ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

连接数据库时设置字符集

在连接数据库时，也要指定字符集：

JDBC 连接字符串：

String url = "jdbc:mysql://localhost:3306/mydb?useUnicode=true&characterEncoding=utf8&useSSL=false";

或者使用更完整的参数：

String url = "jdbc:mysql://localhost:3306/mydb?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=UTC";

Spring Boot 配置：

在 application.properties 或 application.yml 中配置：

spring.datasource.url=jdbc:mysql://localhost:3306/mydb?useUnicode=true&characterEncoding=utf8mb4&useSSL=false
spring.datasource.username=root
spring.datasource.password=password

或者：

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/mydb?useUnicode=true&characterEncoding=utf8mb4&useSSL=false
    username: root
    password: password

其他数据库的字符集设置

PostgreSQL：

PostgreSQL 默认使用 UTF-8 编码，创建数据库时：

CREATE DATABASE mydb WITH ENCODING 'UTF8';

Oracle：

Oracle 数据库的字符集在创建数据库时设置，之后很难修改。建议在创建数据库时就选择 UTF-8 相关的字符集，如 AL32UTF8。

实际应用场景

让我们看看几个实际应用场景，了解如何在实际项目中应用这些解决方案：

场景一：Web 应用开发

在 Web 应用中，需要处理前端的请求和响应：

设置请求和响应编码：

在 Spring MVC 中，可以配置字符编码过滤器：

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Bean
    public CharacterEncodingFilter characterEncodingFilter() {
        CharacterEncodingFilter filter = new CharacterEncodingFilter();
        filter.setEncoding("UTF-8");
        filter.setForceEncoding(true);
        return filter;
    }
}

或者在 web.xml 中配置：

<filter>
    <filter-name>characterEncodingFilter</filter-name>
    <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
    <init-param>
        <param-name>encoding</param-name>
        <param-value>UTF-8</param-value>
    </init-param>
    <init-param>
        <param-name>forceEncoding</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>

场景二：文件读写

在读写文件时，要明确指定编码：

读取文件：

// 使用 UTF-8 编码读取文件
try (BufferedReader reader = new BufferedReader(
        new InputStreamReader(new FileInputStream("file.txt"), StandardCharsets.UTF_8))) {
    String line;
    while ((line = reader.readLine()) != null) {
        System.out.println(line);
    }
}

写入文件：

// 使用 UTF-8 编码写入文件
try (BufferedWriter writer = new BufferedWriter(
        new OutputStreamWriter(new FileOutputStream("file.txt"), StandardCharsets.UTF_8))) {
    writer.write("中文内容");
}

场景三：日志输出

在输出日志时，要确保日志文件的编码正确：

Logback 配置：

<configuration>
    <appender name="FILE" class="ch.qos.logback.core.FileAppender">
        <file>app.log</file>
        <encoder>
            <charset>UTF-8</charset>
            <pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>
</configuration>

Log4j2 配置：

<Configuration>
    <Appenders>
        <File name="File" fileName="app.log">
            <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss} [%t] %-5level %logger{36} - %msg%n" charset="UTF-8"/>
        </File>
    </Appenders>
</Configuration>

最佳实践建议

在实际项目中，为了避免字符编码问题，建议遵循以下最佳实践：

统一编码规范

1. 所有代码文件使用 UTF-8 编码：包括 Java 源文件、配置文件、资源文件等
2. 所有数据库使用 UTF-8 字符集：MySQL 使用 utf8mb4，PostgreSQL 使用 UTF8
3. 所有网络传输使用 UTF-8 编码：HTTP 请求和响应、消息队列等
4. 所有日志文件使用 UTF-8 编码：确保日志中的中文能正常显示

明确指定编码

在代码中，凡是涉及字符编码的地方，都要明确指定 UTF-8，不要依赖系统默认编码：

// 好的做法：明确指定编码
String content = new String(bytes, StandardCharsets.UTF_8);

// 不好的做法：依赖默认编码
String content = new String(bytes);  // 可能在不同环境下表现不一致

验证编码设置

在项目启动时，可以输出当前的编码设置，方便排查问题：

@PostConstruct
public void checkEncoding() {
    System.out.println("file.encoding: " + System.getProperty("file.encoding"));
    System.out.println("Default Charset: " + Charset.defaultCharset());
}

测试不同环境

在部署到不同环境之前，要测试字符编码是否正常：

1. 在 Windows 开发环境测试
2. 在 Linux 测试环境测试
3. 在 Linux 生产环境测试

确保在所有环境下，中文字符都能正常显示。

总结

字符编码问题虽然看起来简单，但在实际项目中却经常遇到。解决这类问题的关键是统一使用 UTF-8 编码，并在所有可能涉及编码的地方明确指定。

关键点总结：

1. 统一使用 UTF-8：所有文件、数据库、网络传输都使用 UTF-8 编码
2. 设置 JVM 参数：通过 -Dfile.encoding=UTF-8 设置 JVM 默认编码
3. 数据库字符集：数据库和表都使用 UTF-8 字符集，连接时也要指定字符集
4. 明确指定编码：在代码中，凡是涉及编码的地方都要明确指定，不要依赖默认值
5. 验证和测试：在不同环境下测试，确保编码设置正确

最佳实践：

1. 项目开始时就统一编码规范
2. 在 IDE 中设置默认编码为 UTF-8
3. 在构建脚本中设置 JVM 参数
4. 数据库创建时就使用 UTF-8 字符集
5. 代码中明确指定编码，不要依赖默认值