职称论文 关系抽取与RAG：RoRED数据集 LUKE Qwen低资源NLP解析

大语言模型越来越强以后，为什么自然语言处理领域仍然需要关系抽取？原因其实很直接：LLM可以生成流畅文本，但企业知识库、RAG和GraphRAG真正需要的不只是“理解一句话大概在说什么”，还要识别文本中有哪些实体，以及这些实体之间究竟是什么关系。关系抽取正是完成这一步的重要技术。本文以RoRED为例，系统介绍低资源语言关系抽取数据集如何从FewRel机器翻译、罗马尼亚语Wikipedia和Wikidata中构建，并进一步解释LUKE、Qwen、大语言模型、负样本生成、远程监督以及关系歧义对NLP模型性能的影响。RoRED最终包含146190个样本、101种正关系和一个no_relation类别，并使用LUKE-RoRED与Qwen-RoRED进行验证。对于正在研究自然语言处理、关系抽取、RAG、GraphRAG、大语言模型以及准备相关SCI发表辅导项目的读者，这是一套很值得研究的数据构建与模型评估案例。

一、为什么大语言模型时代还需要关系抽取？

最近几年，LLM几乎成为自然语言处理领域最热门的关键词。

很多人会产生一个疑问：

既然大语言模型已经能理解和生成文本，传统的Named Entity Recognition和Relation Extraction是不是已经不重要了？

实际上恰恰相反。

当企业真正开始做：

• RAG知识库；

• GraphRAG；

• 知识图谱；

• 企业文档问答；

• 自动信息抽取；

就会发现一个问题。

只有文本还不够。

系统还需要知道：

谁和谁之间是什么关系。

二、Relation Extraction到底在做什么？

Relation Extraction中文通常翻译为：

关系抽取。

假设有一句话：

“Albert Einstein was born in Ulm.”

里面至少存在两个Entity：

Albert Einstein。

Ulm。

而这两个实体之间的Relation是：

place of birth。

关系抽取模型要做的就是：

给定一句话以及其中两个实体，判断它们属于哪一种预定义Relation。

三、关系抽取为什么和RAG关系越来越大？

传统RAG通常把文档切成Chunks。

用户提问以后，通过Embedding检索相关Chunk，再交给LLM回答。

这种方法很实用。

但它对复杂知识关系的处理能力有限。

例如一个问题涉及：

A属于B。

B位于C。

C由D管理。

这种多跳关系只依靠相似度检索，很容易遗漏。

GraphRAG则希望把文本进一步转成：

• Entity；

• Relation；

• Graph Structure。

所以：

NER负责找到实体，Relation Extraction负责连接实体。

两者共同构成知识图谱和GraphRAG的重要基础。

四、为什么英语关系抽取发展得更成熟？

英语拥有大量成熟Dataset。

这些Dataset不断推动英语关系抽取Model发展。

问题是：

很多低资源语言没有相同规模的数据基础。

五、什么叫Low-resource Language？

所谓低资源语言，并不是说这种语言没有使用者。

而是：

适合机器学习训练的高质量标注数据、模型、工具和Benchmark相对少。

英语属于典型High-resource Language。

罗马尼亚语则拥有明显更少的Relation Extraction Resource。

这也是RoRED研究真正要解决的问题。

六、过去是不是完全没有罗马尼亚语关系抽取数据？

也不能这么说。

此前一些Multilingual Dataset包含Romanian。

例如：

MULTI-CROSSRE。

但它的Romanian部分主要来自：

English Dataset的Machine Translation。

这和真正从Romanian Wikipedia里采集原生句子仍然存在差别。

七、RoRED最重要的区别在哪里？

RoRED没有只做：

English → Romanian Translation。

它采用两条数据来源。

两种来源结合以后：

既保留FewRel的数据规模。

又增加Romanian Native Context。

八、为什么选择FewRel作为翻译基础？

FewRel本身具有几个优势：

• 数据质量较高；

• Relation数量丰富；

• 样本规模较大；

• License相对友好；

• 已有成熟的数据构建方法。

FewRel包含：

100种Relationship。

比早期只有几类关系的数据集更加Fine-grained。

九、直接把英文句子翻译成罗马尼亚语不就行了吗？

真正做Dataset Translation以后会发现：

翻译句子本身并不是最难的。

真正麻烦的是：

Entity Annotation必须跟着翻译后的文本重新对齐。

原始FewRel已经记录：

• Head Entity；

• Tail Entity；

• Token Position；

• Relation Type。

句子经过LLM Translation以后，语序可能变化。

原来的Entity Index自然就失效了。

十、研究比较了两种翻译Prompt设计

第一种：

Marker-based Translation。

也就是在Head Entity和Tail Entity前后加入Marker。

要求LLM翻译时保持这些标记。

第二种：

Metadata-based Translation。

把句子和Entity Metadata放进JSON。

要求模型同时更新Entity信息。

十一、哪一种翻译方式效果更好？

研究先使用：

100个样本进行Preliminary Test。

结果Marker-based Format更可靠。

Metadata方法容易出现两个问题。

第一：

Entity即使存在罗马尼亚语翻译，模型仍然可能保留英文名称。

第二：

LLM输出的Entity有时无法通过简单String Matching重新定位。

所以最终选择：

Marker-based Translation。

十二、翻译使用什么大语言模型？

研究使用：

gpt-oss:120b。

模型通过Ollama运行。

硬件使用：

NVIDIA A100 80GB GPU。

整个FewRel Translation是Sequential Processing。

总耗时大约：

350小时。

十三、Prompt有没有使用Few-shot？

使用的是：

One-shot Prompting。

Prompt里面包含：

• Romanian System Instruction；

• 一个带Head/Tail Marker的English Example；

• 一个正确Romanian Translation Example；

• 真正等待处理的Dataset Sample。

这种方式帮助模型更稳定地按照Dataset Format输出结果。

十四、翻译以后怎样重新获得Entity Index？

得到LLM翻译结果以后：

研究重新Tokenize Romanian Sentence。

再根据Marker确认两个Entity的位置。

最后重新计算：

• Head Entity Token Span；

• Tail Entity Token Span。

Relation Type和Entity Type则继续沿用原始FewRel Annotation。

十五、为什么只有Translated Dataset仍然不够？

因为翻译数据始终带有：

Source-language Bias。

英文Wikipedia表达什么内容。

翻译以后Romanian Dataset仍然主要表达这些内容。

它并不能充分反映Romanian Wikipedia里真正自然出现的：

• 人物；

• 地理实体；

• 历史事件；

• 组织；

• 文化背景。

所以研究又建立：

Native Romanian Wikipedia Dataset。

十六、Romanian Wikipedia数据是怎么获得Relation的？

研究使用：

• Romanian Wikipedia Article Dump；

• Wikipedia Page Properties；

• Wikidata Truthy Relations Dump。

首先：

把Romanian Wikipedia页面与Wikidata QID对应起来。

然后：

从Wikipedia Sentence里找出链接到Wikidata的Entity Mention。

如果两个实体之间在Wikidata中存在Property：

就可以把这个Relation投射到当前句子。

这就是：

Distant Supervision。

十七、这个自动流程产生了多少Raw Samples？

初步自动抽取以后：

超过270000个Relation Extraction Examples。

但这不能直接当Final Dataset。

因为：

Wikidata里存在Relation。

并不代表当前Sentence一定明确表达这个Relation。

十八、为什么Distant Supervision会产生Noise？

举个简单例子。

Wikidata知道：

A出生于B。

当前Wikipedia Sentence刚好同时出现A和B。

但这句话可能只是在说：

A后来访问了B。

如果直接使用Wikidata Triple给Sentence打标签：

就会产生：

Incorrect Relation Label。

十九、研究怎么过滤这种Distant Supervision Noise？

研究再次利用Self-hosted LLM。

输入：

• Sentence；

• Head Entity；

• Tail Entity；

• Relation Name。

然后让模型只回答：

Yes / No。

问题是：

“从当前Sentence中能不能推断出这个Relation？”

只有回答Yes的Sample被保留。

二十、Wikipedia原始文本还需要Clean吗？

需要。

Wikipedia Dump中可能残留：

• Template；

• File Syntax；

• Category Line；

• Bullet Marker；

• Empty Parentheses；

• 其他MediaWiki Markup。

研究使用mwparserfromhell以及固定规则进行Cleaning。

然后重新Tokenize。

重新定位Entity Span。

二十一、什么样的样本会直接被删除？

例如：

• 仍然包含异常Wiki Markup；

• Sentence少于5个Token；

• 超过80个Token；

• Head Entity无法重新找到；

• Tail Entity无法重新找到。

这些都会被Discard。

二十二、为什么还要控制每个Relation的样本数量？

Wikipedia中的Relation Frequency高度不均衡。

有些关系非常多。

有些则非常少。

如果完全保留：

High-frequency Relation会主导Training。

所以研究设置：

少于：

50个Samples

的Relation删除。

每个Relation最多保留：

1400个Examples。

二十三、为什么上限刚好是1400？

Translated FewRel中：

每个Relation最多约：

700个Examples。

因此1400允许：

Translated Source约700。

Native Romanian Source约700。

尽可能保持两个Source比较均衡。

二十四、为什么Relation Extraction还需要no_relation？

真实文本里面：

两个Entity同时出现在一句话。

不代表它们一定属于目标Relation。

如果Training Dataset只有Positive Relation：

Model很容易形成错误习惯：

只要看到两个实体，就必须猜一个关系。

现实系统显然不能这样。

所以Dataset加入：

no_relation。

二十五、Negative Samples怎么生成？

研究从已有Sentence中：

使用Romanian spaCy NER Model识别Named Entities。

然后随机选择：

两个不同且不重叠的Entity Mentions。

尽量排除原始Positive Head和Tail。

新Entity Pair标记为：

no_relation。

二十六、Positive和Negative比例是多少？

最终目标：

1:1。

也就是说：

Positive Examples多少。

就生成大致相同数量的Negative Examples。

二十七、RoRED最终有多大？

二十八、Translated和Native数据各占多少？

Positive Samples中：

Translated FewRel：

55977。

Romanian Wikipedia Native Samples：

17118。

这两种数据并不是简单重复。

它们提供的是互补信息。

二十九、两种数据源覆盖的Relation一样吗？

不完全一样。

两边共有：

68种Relation。

Romanian Wikipedia独有：

21种。

Translated FewRel独有：

12种。

这也是为什么加入Native Wikipedia具有实际价值。

它确实扩展了Relation Diversity。

三十、不同Relation的样本是不是完全平衡？

不是。

Positive Relation中：

最少：

51个Examples。

最多：

1400个Examples。

平均：

723.71个Samples / Relation。

Native Wikipedia数据自然出现，因此长尾更加明显。

三十一、机器翻译质量怎么样？

研究随机人工检查：

200个Translated Examples。

发现最常见的问题是：

Incomplete Translation。

共有：

37例，占18.5%。

第二类是：

Word Order Problem。

共有：

32例，占16%。

三十二、还有哪些翻译错误？

包括：

• Preposition错误；

• Gender错误；

• Verb Tense错误；

• Missing Article；

• 其他Lexical和Grammar问题。

这类错误总计：

15例，占7.5%。

研究认为：

虽然Language Quality并非完全自然。

但人工检查中的Relation Meaning仍然能够被Romanian Native Speaker理解。

三十三、Native Wikipedia就没有问题了吗？

同样存在Limitation。

因为它依赖：

• Wikipedia Entity Linking；

• Wikidata Coverage；

• Distant Supervision。

因此可能出现：

• Entity Link Ambiguity；

• Wikidata信息过时；

• 多个Possible Relation同时存在；

• 领域分布不均衡。

三十四、Native Dataset有什么领域偏差？

Romanian Wikipedia中：

比较容易出现：

• Geographic；

• Administrative；

• Historical；

• Biographical。

所以Native Dataset虽然增加Language Authenticity：

也会继承Wikipedia自身的内容Bias。

三十五、两个Source之间有没有重复数据？

研究按照：

• Relation ID；

• Head Entity ID；

• Tail Entity ID。

进行检查。

发现：

185个Overlapping Triples。

但人工检查以后发现：

它们不是重复Sentence。

而是：

相同Entity Relation使用不同句子表达。

因此保留。

三十六、Negative Samples还有什么潜在问题？

Negative Example依赖spaCy Romanian NER。

因此可能受到NER Model：

• Entity Boundary；

• Entity Type；

• Recognition Bias。

影响。

另外：

随机选择的新Entity Pair：

理论上仍有可能实际上存在某个Relation。

这会产生False Negative Label。

三十七、Dataset建好以后使用什么Model验证？

研究选择两种完全不同的Architecture。

三十八、LUKE为什么特别适合关系抽取？

普通Language Model主要对Token进行Encoding。

LUKE的特点是：

Entity-aware Self-attention。

关系抽取任务本身就需要模型重点理解：

Head Entity。

Tail Entity。

以及两者之间的Context。

所以LUKE的Architecture天然和这个Task比较匹配。

三十九、mLUKE原本支持Romanian吗？

原研究使用：

studio-ousia/mluke-large。

值得注意的是：

这个Checkpoint并没有明确把Romanian列为专门支持语言。

研究正是想测试：

Multilingual Pretraining能不能Transfer到Romanian Relation Extraction。

四十、LUKE-RoRED如何训练？

主要参数：

• Epoch：3；

• Learning Rate：2×10^-5；

• Weight Decay：0.01；

• Maximum Sequence Length：256；

• Batch Size：32。

A100 GPU Training Time：

约27分钟。

四十一、为什么还要测试Qwen？

现在NLP研究越来越关注：

Generative LLM能不能替代传统Task-specific Classifier。

所以研究选择：

Qwen3-0.6B。

这是一个大约600M Parameter的Compact Instruction-tuned Model。

规模不算大。

但具有Multilingual和Instruction-following能力。

四十二、Qwen怎么做Relation Extraction？

不是传统Classification Head。

而是把任务写成：

Chat-style Instruction。

输入Romanian Sentence。

标记Head和Tail Entity。

然后让Qwen：

生成对应Relation Label。

四十三、Qwen采用Full Fine-tuning吗？

没有。

使用：

LoRA。

主要设置：

• Epoch：3；

• Learning Rate：2×10^-4；

• Weight Decay：0.01；

• Maximum Sequence Length：2048；

• Batch Size：64；

• LoRA Rank：64；

• LoRA Alpha：64。

四十四、最终LUKE和Qwen谁更好？

整体测试结果：

LUKE-RoRED更强。

最终LUKE-RoRED：

Macro-F1达到0.8744。

Qwen同样能够学习这个Task。

但在当前RoRED Setting下：

Entity-aware Classification Architecture更加适合。

四十五、这是不是说明小型专用模型一定比LLM强？

不能这么下结论。

这个实验只能说明：

在当前Dataset、Training Method和Model Scale下，LUKE更适合这个Relation Extraction Task。

并不能推出：

所有Relation Extraction任务里Qwen或者其他LLM都不如LUKE。

四十六、为什么Task-specific Architecture仍然有价值？

这是这篇研究很值得讨论的一点。

LLM参数很多。

Training Corpus也很大。

但：

更大，不代表在每一个结构化NLP任务上自动更好。

关系抽取尤其需要模型准确区分：

两个指定Entity之间的细粒度Relation。

LUKE的Entity-aware Design在这里就具有明显优势。

四十七、LUKE对Native和Translated Data表现一样吗？

总体比较接近。

Native Romanian Wikipedia：

Accuracy略高。

所有Positive Samples合并以后：

Accuracy达到0.8843。

Macro-F1：

0.8930。

说明没有出现特别明显的Source Bias。

四十八、模型最容易错在哪些Relation？

错误并不是随机分布。

比较困难的Relation集中在：

• Geographic；

• Administrative；

• Ownership；

• Creative Role。

这些Relationship在Semantic Meaning上比较接近。

四十九、一个典型Confusion是什么？

例如：

P58 screenwriter

经常被错误预测成：

P1877 after a work by。

另一个例子：

P551 residence

经常被预测成：

P937 work location。

模型往往已经判断出大概Semantic Domain。

但：

没有准确区分更加Fine-grained Wikidata Property。

五十、Geographic Relation为什么特别容易混淆？

例如：

• P17 country；

• P131 located in administrative entity；

• P36 capital；

• P706 located on terrain feature。

都属于Location-related Relationship。

仅仅依靠Surface Word：

很难稳定判断。

真正区别往往取决于：

两个Entity在当前语境中的具体角色。

五十一、是不是Relation样本越多，F1就一定越高？

没有这么简单。

样本数：

≤50

的Rare Relation整体Macro-F1最低。

说明极端Low-support确实困难。

但：

Training Examples超过：

1000

以后，也并没有拿到最高Macro-F1。

表现最好的反而出现在：

501–1000 Samples。

五十二、统计分析说明了什么？

Spearman Correlation：

没有发现Training Support和Performance之间存在显著关联。

但对Support做Log Transform以后：

Pearson Correlation发现：

Precision：

r=0.285，p=0.0039。

F1：

r=0.255，p=0.0101。

存在Weak Positive Association。

Recall：

r=0.118，p=0.2412。

不显著。

五十三、这个结果怎么理解？

更多Training Data：

可能让模型：

减少False Positive。

所以Precision有所提高。

但：

它并没有自动解决：

• Semantic Overlap；

• Relation Ambiguity；

• Fine-grained Property Distinction。

所以Recall并没有同步明显改善。

五十四、RoRED最大的价值到底是什么？

并不是单纯又增加了一个NLP Dataset。

更重要的是展示了一条低资源语言资源建设路线：

高资源语言Dataset → LLM Translation → Annotation Alignment → Native Wikipedia Distant Supervision → LLM Filtering → Negative Sample Generation → Baseline Validation

对于很多缺少人工标注语料的Language来说：

这套思路具有一定参考价值。

五十五、Generative AI真正起了什么作用？

这篇研究没有简单使用LLM做Final Prediction。

Generative AI至少参与两个关键环节。

第一：

Machine Translation。

第二：

Distant-supervision Sample Filtering。

也就是说：

LLM本身成为：

Dataset Engineering Tool。

五十六、这对于现在做NLP论文有什么启发？

很多人现在做LLM论文：

第一个问题就是：

“应该用哪个大模型？”

但真正有价值的research Question还可以是：

• LLM怎样帮助建立低资源语言Dataset；

• Machine Translation怎样保持Entity Annotation；

• LLM Filter能否降低Distant Supervision Noise；

• Native和Translated Data怎样组合；

• 传统Task-specific Model和Generative LLM谁更适合结构化NLP任务。

五十七、关系抽取未来还能和哪些方向结合？

• RAG；

• GraphRAG；

• Knowledge Graph Construction；

• Multilingual NLP；

• Low-resource Language Modeling；

• LLM Dataset Generation；

• Cross-lingual Transfer Learning；

• Few-shot Relation Extraction；

• Document-level Relation Extraction；

• Knowledge Graph Question Answering。

五十八、做关系抽取SCI论文最容易出现哪些问题？

五十九、SCI发表辅导与NLP、大语言模型论文支持

自然语言处理、大语言模型、RAG、关系抽取和知识图谱类论文，现在真正影响文章质量的往往不是“模型参数越大越好”，而是Research Gap、Dataset Design和Evaluation有没有真正回答研究问题。

例如RoRED这类研究，如果只是把FewRel翻译成罗马尼亚语，再训练一个Qwen，很容易停留在普通Dataset Translation。

真正让研究完整的是后面继续加入Native Romanian Wikipedia、Distant Supervision、LLM Filtering、Synthetic Negative Samples、Source-level Evaluation和Relation-level Error Analysis，并且比较Entity-aware LUKE和Generative Qwen两种完全不同的Architecture。

对于已经有NLP研究方向、Dataset、实验代码或者论文初稿的作者，我们提供SCI发表辅导，可以根据项目阶段协助Research Gap梳理、Dataset Design、Baseline选择、模型实验、Ablation Study、Error Analysis、统计结果、论文结构、英文表达以及目标期刊方向等内容。

如果研究内容涉及LLM或者RAG，也不建议简单写成“使用大语言模型以后效果更好”。像RoRED这样的案例反而说明，传统Task-specific Architecture在某些结构化NLP任务上仍然可能优于Generative LLM，因此需要通过公平实验说明不同模型为什么表现不同。

对于需要持续跟进整个投稿周期的项目，也可以选择投稿无限期服务直到见刊，在约定服务范围内持续协助目标期刊筛选、投稿材料准备、审稿意见分析、返修以及必要情况下重新匹配期刊等环节。实际审稿周期与最终结果仍取决于研究质量、稿件完整度以及目标期刊的真实审稿流程。

FAQ：关系抽取、RAG、RoRED与Qwen常见问题

Q1：什么是Relation Extraction关系抽取？

关系抽取是自然语言处理中识别两个实体之间语义关系的任务，例如人物与出生地、公司与所在地、作品与作者之间的关系。

Q2：关系抽取和RAG有什么关系？

普通RAG主要依靠文本相似度检索，而GraphRAG进一步利用实体和关系构建知识图结构。关系抽取因此是把非结构化文本转成结构化知识的重要环节。

Q3：RoRED是什么？

RoRED是一套面向Romanian Relation Extraction的数据集，结合机器翻译FewRel样本、原生Romanian Wikipedia样本以及合成no_relation负样本。

Q4：RoRED有多少数据？

最终包含146190个Examples，其中116918个Training Examples、29272个Test Examples，Positive和Negative分别为73095个。

Q5：为什么RoRED不是简单翻译FewRel？

因为研究另外从Romanian Wikipedia和Wikidata构建原生样本，使数据包含真正Romanian语言环境中的实体、事实和文化背景。

Q6：为什么机器翻译关系抽取数据比较困难？

除了句子本身需要正确翻译，还必须保证Head和Tail Entity在翻译后的文本中能够重新准确定位，否则原有Relation Annotation会失效。

Q7：LUKE和Qwen哪个更适合RoRED？

当前实验中LUKE-RoRED表现更好，最终Macro-F1达到0.8744。Entity-aware Architecture与关系抽取任务本身高度匹配，是其优势之一。

Q8：是不是大语言模型一定比传统NLP模型好？

不一定。模型规模只是一个因素，Task Architecture同样重要。结构化实体关系任务中，针对Entity Pair设计的模型可能比通用生成式模型更加高效。

Q9：什么是Distant Supervision？

Distant Supervision利用现有知识库关系自动给文本打标签，例如把Wikidata中的Entity Relation投射到Wikipedia Sentence上，可以快速扩展Dataset，但同时可能引入标签噪声。

Q10：为什么要加入no_relation？

真实文本中两个Entity同时出现并不意味着它们一定存在目标关系。加入no_relation可以训练模型识别“没有相关Relation”的情况。

Q11：RoRED主要有哪些局限？

主要包括机器翻译残留错误、Distant Supervision噪声、Romanian Wikipedia领域偏差以及自动生成Negative Samples可能存在False Negative等问题。

Q12：关系抽取还能研究哪些SCI方向？

可以进一步研究GraphRAG、多语言关系抽取、跨语言迁移、低资源语言NLP、Document-level Relation Extraction、知识图谱构建以及LLM辅助数据生成等方向。

Q13：SCI发表辅导可以协助哪些NLP研究内容？

可以根据当前研究阶段协助Research Gap、Dataset Design、Baseline、模型实验、Error Analysis、Ablation Study、Results与Discussion以及目标期刊方向等内容。

Q14：投稿无限期服务直到见刊是什么意思？

主要指在约定服务范围内持续跟进目标期刊选择、投稿材料、审稿意见分析、返修以及必要情况下重新匹配期刊等流程，而不是只处理第一次投稿。

总结：关系抽取在大语言模型时代并没有过时

从RoRED这个案例可以看出，Generative AI正在改变NLP研究方式，但它并没有让传统关系抽取任务失去价值。

相反，当RAG进一步发展到GraphRAG、知识图谱和结构化检索以后，实体和关系的质量反而越来越重要。

RoRED的价值也不仅是提供一套Romanian Dataset。

它展示了一种比较现实的Low-resource NLP路线：先利用成熟英语Dataset和大型语言模型快速获得基础监督数据，再从本地Wikipedia补充真正自然出现的语言和文化语境，通过Distant Supervision扩大规模，再使用LLM和规则过滤Noise，最后用专用模型与Generative Model共同验证。

实验结果同时提醒我们，大语言模型并不一定在所有NLP任务上自动胜出。LUKE-RoRED凭借Entity-aware Architecture，在当前关系抽取任务中取得更好的总体表现。对于结构化NLP研究来说，真正重要的仍然是Dataset Quality、Task Design、Model–Task Match以及细致的Error Analysis，而不是单纯追求更大的模型参数量。