技术分享

多年 NLP 从业者对 LLM 和知识图谱的一些看法

图片

关于本文作者 Louis Guitton:曾任德国柏林 OneFootball Labs 的副总裁,在 NLP 领域、推荐系统、MVP 构建和 Flow 区块链方面有丰富的经验。 近一年大家没少被 LLM 相关的新闻刷屏,在本文 Louis Guitton 将同你分享在他这个 NLP 领域多年从业者对 LLM 和知识图谱的看法。

Vector RAG

在之前的 Graph + LLM 三部曲中,我们了解到知识图谱可以基于 Graph RAG(图 RAG)为 LLM 提供事实依据,并且成本可能比 Vector RAG(向量 RAG)更低。在本文,你将进一步了解到当中的差异,以及 Graph RAG 的便捷。

*注:本文是作者在 2024 年 2 月 15 日举办的“生产中的 AI”在线会议上的分享,演讲链接: https://home.mlops.community/public/events/ai-in-production-2024-02-15。

回顾 2019 年 spaCy IRL 大会

spaCy 是一个流行的 NLP 工具库,用于执行各种语言处理任务,例如词性标注、命名实体识别、依存句法分析等。

在 LLM 爆火之前,我已经从事自然语言处理(NLP)研究工作好几年,自然也就见证了大型语言模型(Large Language Models)的崛起。我在 NLP 和图谱方面的工作可以追溯到 2018 年,那时我在德国柏林的足球媒体公司 OneFootball 任职机器学习工程师,在那时我开始将相关技术应用到体育媒体领域。

作为一名从业者,我对那段时间记忆犹新,因为那是 NLP 领域发生巨变的时期。我们从基于规则的系统和词嵌入时代进入到深度学习时代,从 LSTM 转向了基于 transformer 架构的一系列模型,如 ELMo 或 ULMFiT。作为少数能参加在柏林举行的 spaCy IRL 2019 会议的幸运儿,我同其他人一起交流了关于 transformer、会话型 AI 助手以及在金融或媒体领域的应用的 NLP 的看法。

transformer

图注:Spacy IRL 2019 keynote by Sebastian Ruder

NLP

图注:会议现场照

在主题演讲《The missing elements in NLP (spaCy IRL 2019) 》(NLP 缺失的元素)中,Yoav Goldberg 曾预测 NLP 领域下一个重大进步是使非专家能够使用 NLP。某种程度,至少从结果上看,他是对的。他认为我们将通过人类编写规则的方式实现,这些规则有深度学习的辅助,从而产生透明且可调试的模型。但,方式错了。我们仅仅通过聊天就能实现这一点,而且现在的模型透明度更低,以及可调试性差了点意思。现在,我们在他的图表上进一步向右下方移动(见下图),我们到了一个比深度学习更远的地方。至于能否向更透明的模型迈进,领域专家们只用少量数据就能让模型干活,这点我们目前没有一个定论。

OneFootball

回到我之前说到过的 OneFootball 工作,在这家支持 12 种语言、每月有 1,000 万活跃用户的足球媒体公司,我们用 NLP 帮新闻编辑室解锁了新的产品功能:我建立了一套系统,来提取网站文章中的实体和关系、给新闻打上标签,以及向用户推荐相关文章。这块的工作,我在柏林的一次 NLP 聚会上分享过。我们有中等的数据量,不算多。前面提过给新闻打标签工作,其实我们还有部分的标签重打工作,因为我们付不起太多的计算成本,所以只能借助 NLP 来提升效能。

在深入 NLP 应用的过程中,我无意间了解到了 Graph(图)这个概念。这不得不提下我的朋友 Paco Nathan(多部关于机器学习、自然语言处理、图技术及相关主题的书籍和流行视频教程的作者),以及他的优秀的 PyTextRank 真是帮上大忙了。图,与基于规则的匹配器、弱监督,再加上我多年的 NLP 经验,帮我自动地处理了部分的注释数据工作。此外,在构建系统的同时,系统还融入了领域专家的声明式知识,非专业人士也能使用,甚至是维护这套系统。还有提的一点是,这个系统具备了一定程度的人机合作能力。于是,我们推出了一个更好的标签系统及新的推荐系统。借助图技术来完成这一套的工作,让我觉得太有意思了。

所以,当 LLM 兴起,我看到图和 LLM 二者结合的潜力,我一定要和你分享下下面的事情。

事实归因与图 RAG

微调 vs 检索增强生成

图和 LLM 第一个交集便是事实归因。大家都知道,LLM 目前存在一些问题,比如:幻觉、知识截断、偏见和失控。为了绕开这些问题,人们开始转向可用(可信) 的领域数据。尤其是在两种技术:微调(Fine Tuning)和检索增强生成(Retrieval-Augmented Generation, RAG)出来之后。

在三个月前的 AI 大会上,Anyscale 首席科学家 Dr. Waleed Kadous 在他的演讲 LLMs in Production 中,对这两种方式的抉择权衡提供了一些见解。他说:“微调是针对形式而非事实的。”、“而 RAG 是针对事实的。”

像是 OpenAccess-AI-Collective/axolotl、huggingface/trl 之类的开源库的存在,让微调变得更容易、更便宜。虽然难度和成本都降低了,但微调还是那个资源密集的工作,而且要以此为生的话,NLP 技术得更成熟才行。与此同时,另一边的 RAG 也变得更容易获取了。2 个月前,Hacker News 上有个咨询贴《2023 年 12 月了,有哪些方式来基于文档定制我的 LLM/ChatGPT?》,里面大多数的回复(从业者)都在用 RAG 而非微调。

Vector RAG vs Graph RAG

一说到 RAG,一般人们指代是基于向量数据库的检索系统,即 Vector RAG。但是在 NebulaGraph(一个开源的图数据库)的博客和教程中,介绍了一种称之为 Graph RAG 的替代方法,这是一种基于图数据库的检索系统。他们展示了不同的架构中 RAG 系统检索的事实是如何的不同。

在 LlamaIndex 的 KnowledgeGraph vs VectorStoreIndex vs 混合 Index 结果对比中,提到与 Vector RAG 相比,Graph RAG 更简洁,在 token 开销方面更加便宜。

RAG 概览

为了方便你理解不同的 RAG 架构,这里放出了我绘制的图表:

Vector RAG

图注:Differences and similarities of the RAG architectures

在绝大多数情况下,我们会以自然语言问问题 ,再得到一个自然语言的回复 。而系统这边的处理流程就是,编码模型提取问题的结构后,同生成模型(答案生成器)一起生成对应的答案。

Vector RAG 将查询嵌入到向量 VQ中,通常它会使用比 LLM 小的模型,像是 Flag Embedding 或者是 Huggingface 这些嵌入排行榜上主流的小型模型。然后,从向量数据库里检索出与VQ最相近的 TOP K 个文档块,并将这些作为向量和块(vj,cj)返回。这些块连同Qnl 一起作为上下文传给 LLM 生成答案ANL 。

Graph RAG 从查询中提取关键词kj,并检索与关键词匹配的图中的三元组。然后,它将这些三元组(Sj, pj, 0j)连同 QN 一起传递给 LLM 生成答案 ANL。

Structured RAG 使用生成模型(LLM 或更小的经过微调的模型)来生成数据库查询语言中的查询。它可以为关系型数据库生成一个 SQL 查询,或者为图数据库生成一个 Cypher 查询。例如,我们想查询一个关系数据库:模型将生成QSQL,再传给数据库来检索答案。如果留意AsQz 的话,都是从数据库运行 QSQL得到的数据记录。答案 ASQL 以及QNL 都会传给 LLM 来生成ANL 。

在混合 RAG 情况下,系统会结合了上述所有方法。因为混合技术不在本文的讨论范畴,总之记住有很多种混合技术。当中最简单的是,传递更多上下文给 LLM 用于答案生成,并让它利用摘要能力强化生成的答案。

LlamaIndex 中的 Graph RAG 实现

现在,来看下使用当前的框架,10 行 Python 代码构建出来的 Graph RAG 系统。

`
from llama_index.llms import Ollama
from llama_index import ServiceContext, KnowledgeGraphIndex
from llama_index.retrievers import KGTableRetriever
from llama_index.graph_stores import NebulaGraphStore
from llama_index.storage.storage_context import StorageContext
from llama_index.query_engine import RetrieverQueryEngine
from llama_index.data_structs.data_structs import KG
from IPython.display import Markdown, display

llm = Ollama(model='mistral', base_url="http://localhost:11434")
service_context = ServiceContext.from_defaults(llm=llm, embed_model="local:BAAI/bge-small-en")

graph_store = NebulaGraphStore(space_name="wikipedia", edge_types=["relationship"], rel_prop_names=["relationship"], tags=["entity"])
storage_context = StorageContext.from_defaults(graph_store=graph_store)

kg_index = KnowledgeGraphIndex(index_struct=KG(index_id="vector"), service_context=service_context, storage_context=storage_context)
graph_rag_retriever = KGTableRetriever(index=kg_index, retriever_mode="keyword")

kg_rag_query_engine = RetrieverQueryEngine.from_args(retriever=graph_rag_retriever, service_context=service_context)

response_graph_rag = kg_rag_query_engine.query("Tell me about Peter Quill.")
display(Markdown(f"<b>{response_graph_rag}</b>"))`

这段代码假设你已经在 Ollama 上部署了 mistral 模型,并在本地运行了一个 nebula 实例。此外,它还假设 NebulaGraph 中已加载了一个知识图谱。如果你没有知识图谱的话,在下一节中我们将介绍如何构建一个知识图谱。

这里,你可以使用 Docker 桌面的 NebulaGraph Extension 来快速启动一个 nebula 实例。

首次启动(v3.6.0)版本之前,你可能需要添加下 storage 的信息:

`ADD HOSTS "storaged0":9779,"storaged1":9779,"storaged2":9779`

在使用 NebulaGraph 进行查询之前,你可能需要创建相关索引

`创建图空间
CREATE SPACE wikipedia(vid_type=FIXED_STRING(256), partition_num=1, replica_factor=1);
使用图空间
USE wikipedia;
创建实体
CREATE TAG entity(name string);
创建关系边
CREATE EDGE relationship(relationship string);
创建实体类型对应的索引
CREATE TAG INDEX entity_index ON entity(name(256));`

知识图谱的搭建

构建一个知识图谱

在进行推理之前,你需要在向量数据库或图数据库中对数据进行索引构建。

Graph RAG

图注:Indexing architectures for RAG

对于 Graph RAG 来说,与 Vector RAG 的文档分块、嵌入等操作对等的是,提取三元组。三元组的形式一般是(s, p, o),其中 s 是主体,p 是谓词,o 是客体。主体和客体是实体,谓词是关系。

从文本中提取三元组有多种方式,但最常见的方法是使用命名实体识别器(NER)和关系提取器(RE)的组合。NER 提取像“Peter Quill”和“银河护卫队第 3 卷”这样的实体,RE 提取像“在…中扮演角色”和“由…导演”这样的关系。

虽然市面上有专门用于 RE 的微调模型,比如:REBEL,但人们开始使用 LLM 来提取三元组了。下面是 LlamaIndex 的 RE 默认提示词:

`Some text is provided below. Given the text, extract up to
{max_knowledge_triplets}
knowledge triplets in the form of (subject, predicate, object). Avoid stopwords.
---------------------
Example:
Text: Alice is Bob's mother.
Triplets: (Alice, is mother of, Bob)
Text: Philz is a coffee shop founded in Berkeley in 1982.
Triplets:
(Philz, is, coffee shop)
(Philz, founded in, Berkeley)
(Philz, founded in, 1982)
---------------------
Text: {text}
Triplets:
`

使用这种方法的问题在于,你必须用正则表达式解析聊天输出,而且你还无法控制提取的实体或关系的质量。

LlamaIndex 中的知识图谱

但是,有了 LlamaIndex,用以下的代码片段,10 行 Python 代码就完成了一个知识图谱的构建工作:

`from llama_index.llms import Ollama
from llama_index import ServiceContext, KnowledgeGraphIndex
from llama_index.graph_stores import NebulaGraphStore
from llama_index.storage.storage_context import StorageContext
from llama_index import download_loader

llm = Ollama(model='mistral', base_url="http://localhost:11434")
service_context = ServiceContext.from_defaults(llm=llm, embed_model="local:BAAI/bge-small-en")

graph_store = NebulaGraphStore(space_name="wikipedia", edge_types=["relationship"], rel_prop_names=["relationship"], tags=["entity"])
storage_context = StorageContext.from_defaults(graph_store=graph_store)

loader = download_loader("WikipediaReader")()
documents = loader.load_data(pages=['Guardians of the Galaxy Vol. 3'], auto_suggest=False)

kg_index = KnowledgeGraphIndex.from_documents(
    documents,
    storage_context=storage_context,
    service_context=service_context,
    max_triplets_per_chunk=5,
    include_embeddings=True,
    kg_triplet_extract_fn=None,
    kg_triple_extract_template=None,
    space_name="wikipedia",
    edge_types=["relationship"],
    rel_prop_names=["relationship"],
    tags=["entity"],
)`

基于 LLM 构建知识图谱的失败示例

如果我们查看电影“银河护卫队第 3 卷”所生成的知识图谱,我们可能会发现一些问题: 这里有个问题的汇总表:

LLM

图注:问题汇总表格

将它同与手工标记的 Wikidata 图谱对比是这样的:

Human-labelled

图注:Human-labelled KG in Wikidata generated with metaphacts

为了更好地构建知识图谱

所以,我们的前进方向在哪里呢?本质上,知识图谱的构建优化要自然演进的话,其实目前有一些技术挑战需要解决:构建知识图谱的方法需要新的事实和表示未见过的知识。论文《统一大语言模型和知识图谱:路线图(Unifying Large Language Models and Knowledge Graphs: A Roadmap)》 很好地概述了当前的技术现状以及未来的挑战。

构建知识图谱涉及在特定领域内创建知识的结构化表示,包括识别实体及其之间的关系。知识图谱构建过程通常包括多个阶段,包括:1) 实体发现;2) 共指消解;3) 关系提取。论文的 Fig.19 展示了在知识图谱构建的每个阶段应用大型语言模型(LLM)的一般框架。最近,还探索了 4) 端到端的知识图谱构建,涉及一步构建完整的知识图谱,或者直接从大型语言模型(LLM)中提炼知识图谱。

这篇论文可以用下图总结下:

图片

图注:Fig.19 The general framework of LLM-based KG construction

我只看到过少数几个尝试解决上述问题的项目:DerwenAI/textgraphs 和 IBM/zshot.。

解锁 AI 专业技能

Human vs AI

图谱和 LLM 相遇的尽头是人机合作。谁不喜欢“人类与 AI”的故事呢?毕竟,现在关于“AGI”或是“ChatGPT 通过资格考试”的新闻遍地都是。

图片

图注:Human vs AI

我建议阅读本文的你读一读 AI Snake Oil 报道中的这个回答。他们提出了一个好观点,即:像 ChatGPT 这样的模型只是记住了解决方案而不是推理它们,这让考试成为比较人类和机器的一个糟糕方式。

超越存储记忆,还有一个围绕所谓的泛化、推理、计划、表示学习的研究领域,图能帮上忙。

人机合作:可视化

人机的关系,我更认同人机合作的观点,而不是彼此对抗。这就要求人类得知道,如何解释和优化那些内部工作机制不透明的机器学习模型。

一个关键项目推动了这块的发展,那就是 Vincent Warmerdam 在 2020 年发表的 whatlies 论文。他用 UMAP 对嵌入进行了可视化,来揭示 LLM 中的质量问题,并建立了一个框架,供其他人审计他们的嵌入,而不是盲目信任它们。

同样,图数据库提供了许多开箱即用的可视化工具。例如,它们会通过颜色、元数据和不同的布局算法(基于力导向图)添加上下文。

图片

图片

人机合作:Human in the Loop

最后一件事,我们如何解决深度学习模型缺乏控制的问题,以及我们如何将领域专家的声明性知识结合起来?

我喜欢引用“真理在于实践”的说法,我的意思是,技术的价值必须基于其在生产中的结果来判断。当我们观察生产系统时,我们看到 LLM 或深度学习模型不是孤立使用的,而是与人类一起共同进步的。

在两周前的一个项目和论文中,谷歌开始使用语言模型来帮助它在 C/C++、Java 和 Go 代码中找到和发现错误。更让人兴奋的是,Google 最近开始使用基于 Gemini 模型的 LLM 来“成功修复单元测试期间发现的 15% 的sanitiser bug,修补了数百个问题”。尽管 15% 的接受率听起来相对较小,但在谷歌这个规模上却有很大的影响。这个错误修复的处理流程、结果优于人类——谷歌说道:“大约 95% 的代码提交被代码所有者在没有讨论的情况下就接受了。这是一个比人类生成的代码变更更高的接受率,后者通常会引发问题和评论”。

对我来说,关键的收获与他们的架构有关:

图片

图注:AI-powered patching at Google

他们用 LLM 构建了它,但他们还将 LLM 与更小的、更具体的 AI 模型结合起来,更重要的是在顶层加上了双重人类过滤器,从而与机器协同工作。

小结

我还清晰地记得 2019 年那些日子,从 LSTM 转向 Transformers,我们认为那就是深度学习。现在,有了 LLM,我们达到了我所描述的 Abysmal Learning(深渊学习)。我喜欢 Abysmal Learning,因为它既可以意味着“极其深远”,也可以意味着“极其糟糕”。

比以往任何时候都更需要更多的控制、更多的透明度,以及人类与机器合作的方式。在这篇博客文章中,我们看到了一些图谱和 LLMs 可以如何合作来帮助实现这一目标的方式,我很兴奋地期待着未来会带来什么。

图片

参考资料

  • Language, Graphs, and AI in industry - Paco Nathan - Jan, 2024

  • Graph ML meets Language Models - Paco Nathan - Oct 25, 2023

  • [2306.08302] Unifying Large Language Models and Knowledge Graphs: A Roadmap

  • GitHub - RManLuo/Awesome-LLM-KG: Awesome papers about unifying LLMs and KGs - Jun 14, 2023

  • Evaluating LLMs is a minefield

  • GPT-4 and professional benchmarks: the wrong answer to the wrong question - AI Snake Oil - Oct 4, 2023

  • AI-powered patching: the future of automated vulnerability fixes - Google Security - Jan 31, 2024

  • Graph & Geometric ML in 2024: Where We Are and What’s Next (Part II — Applications) | by Michael Galkin - Jan 16, 2024

  • [2312.02783] Large Language Models on Graphs: A Comprehensive Survey - Dec 5, 2023

  • ULTRA: Foundation Models for Knowledge Graph Reasoning | by Michael Galkin | Towards Data Science - Nov 3, 2023

  • Fine Tuning Is For Form, Not Facts | Anyscale - July 5, 2023

  • GenAI Stack Walkthrough: Behind the Scenes With Neo4j, LangChain, and Ollama in Docker - Oct 05, 2023

  • NebulaGraph Launches Industry-First Graph RAG: Retrieval-Augmented Generation with LLM Based on Knowledge Graphs - Sep 6, 2023

  • RAG Using Unstructured Data & Role of Knowledge Graphs | Kùzu - Jan 15, 2024

  • Constructing knowledge graphs from text using OpenAI functions | by Tomaz Bratanic - Oct 20, 2023

  • Knowledge graph from unstructured text | by Noah Mayerhofer | Neo4j Developer Blog - Sep 21, 2023

关于 NebulaGraph

NebulaGraph 是一款开源的分布式图数据库,自 2019 年开源以来,先后被美团、京东、360 数科、快手、众安金融等多家企业采用,应用在智能推荐、金融风控、数据治理、知识图谱等等应用场景。GitHub 地址:https://github.com/vesoft-inc/nebula


Tag
Recommended for you
green iguana

技术分享

使用 nebula-spark-connector 3.6 版本搭建备集群实践
green iguana

技术分享

来自开发者的认可,NebulaGraph Star 突破 10,000 大关
green iguana

技术分享

多年 NLP 从业者对 LLM 和知识图谱的一些看法