共计 12684 个字符，预计需要花费 32 分钟才能阅读完成。
本文整顿自 NebulaGraph 布道师 wey 在「夜谈 LLM」主题分享上的演讲，次要包含以下内容：
-
背景
- LLM
- RAG
- Graph
- 常识抽取
- Text2Cypher
- Graph RAG
- 将来布局
技术背景
LLM 是什么
这里简略、疾速地介绍下大语言模型：从 GPT-2 开始，到起初风行的 GPT-3，人们逐步意识到语言模型达到肯定规模，借助局部技术手段之后，程序如同能够变得和人一样，去了解人类简单的思维表白。与此同时，一场技术改革也悄悄产生了，已经咱们须要用简单代码、深度学习才可能去形容的某些场景，或是实现的自动化、智能化的零碎能力，当初借助 LLM（Large Language Model）大语言模型就能不便地实现。不只如此，一些大的生成模型能够做更多多模态的事件，去实现一些更有创造性的需要。
如上所示，目前咱们利用大语言模型，将其当作通用智能感知层（接入层），再对接各类传统服务 Service 或者是生成模型服务 AIGC 的利用架构大略是这样。
而当中比拟典型的模式可能就是 RAG。
RAG 是什么
RAG，全称 Retrieval Augmented Generation，检索加强生成模型，善于解决常识密集型工作。
对应到下面的利用架构图，在 LLM 层，大语言模型会的常识不足以实现工作，此时咱们须要借助其余的工具，来取得额定常识，可能在之前是低廉的专家资源或者是 Fine-Tuning 微调模型。然而当初 RAG 它能解决这个问题，它能够辅助 LLM 取得额定的常识、数据，亦或是文档。RAG 在用户提交相干工作时，会将发问的问题进行解析，搭配已有的额定知识库，找寻到同它相干的那些常识。
上图下方就是 RAG 罕用的办法，通过 Embedding 和向量数据库达到检索加强的成果。具体来说，RAG 就是将一个语义压缩到一个多维的空间里的向量。尽管在这个过程中，信息是有损失，但如果算法足够正当、压缩的空间足够大的话，也能帮忙咱们在比拟疾速的状况下找到相干信息。
举个例子，之前咱们罕用的以图搜图，在淘宝上传一个商品图片，它会找类似的商品，这背地其实就是淘宝把图片的特征向量化，（并非事实）可能是一万维的向量。而你上传的新照片，用同样的压缩 Embedding 的形式生成一个新向量。再在已有的历史商品图片的向量库里搜寻间隔相近的，兴许是 Top100 的向量，将它对应的图片返回给你，也就是你上传商品的类似商品。
这种形式能够延长一下，用来做语义搜寻。通常来说，咱们能够将一本书或者是几百页的文档，拆分成一片片，每个分片的含意做一个 Embedding。同以图搜图相似，咱们在进行发问时，将这个语义的 Embedding 同已有的 Embedding 向量空间做匹配搜寻，找到同这个发问相近的常识片，而后再把这些常识片作为上下文，和工作一起提交给大语言模型。像是 ChatGPT-4、ChatGLM、LLMam 2 之类的感知智能层，当它有了须要的上下文时，就能够很好地去答复咱们问题或者是实现咱们的工作。
这是最简略的、利用额定的常识做问答的 LLM 工作的形式，在《图技术在 LLM 下的利用：常识图谱驱动的大语言模型 Llama Index》这篇文章中也有具体的介绍。
文中讲述了一些常识图谱驱动 LLM 的背景，然而这里能够略微简略地说下。像是上图下方的选举，它其实会毁坏到局部构造，比如说 TopN 要选多少才可能实现咱们的工作，此外咱们的常识分片也扩散在各处。不过既然是常识，其实用常识图谱是一个十分不便的形式，这也是图数据库 NebulaGraph 典型的利用场景。
Graph 是什么
图是什么，这里简略待过。
上述是图论的一个起源，有趣味的读者能够自行去理解背景。这里着重讲下为什么咱们要用到常识图谱、图数据库。
常识图谱，Knowledge Graph，最早是 Google 引入的技术。当咱们检索词条时，搜寻页面右侧会有相干词条卡片信息，这些信息是一种数据间的关联关系的内容体现。基于这种数据关联关系，咱们能够进行词条推理工作，像是“yaoming’s wife age”，找到姚明老婆的年龄。这种推理工作，采纳传统的倒排索引是无奈实现的，必须得基于常识的推理，而这背地的撑持的常识就是 Google 最开始从语义网络倒退进去的叫 Knowledge Graph 的一个专业术语。
其实，不只有 Knowledge Graph 这一个图的利用场景。
简略来说，如果你有海量的图关联场景，你用非图的数据库写查问语句（像是上图 SQL 局部）。尽管实践上 SQL 是能够实现多跳的查问，或是查问是两点之间任意的门路，但往往这个查询语言不好写，并且响应速度满足不了业务需要。简略来说，十分苦楚。
而图数据库便是面向连贯的存储，像雪人兄弟的跳转，其实就是 O(1) 的一跳，一种十分高效的形式解决跳转问题。而图数据库 NebulaGraph 是分布式的数据库，尤其是在海量数据库的场景下，会提供更高效的解决方案。
技术背景信息说完了，当初来讲讲大语言模型和图能够解决哪些问题？
构建常识图谱
LLM + Graph，首先能解决的是常识图谱的常识构建问题。
DEFAULT_KG_TRIPLET_EXTRACT_TMPL = (
"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.\n"
"---------------------\n"
"Example:"
"Text: Alice is Bob's mother.""Triplets:\n(Alice, is mother of, Bob)\n"
"Text: Philz is a coffee shop founded in Berkeley in 1982.\n"
"Triplets:\n"
"(Philz, is, coffee shop)\n"
"(Philz, founded in, Berkeley)\n"
"(Philz, founded in, 1982)\n"
"---------------------\n"
"Text: {text}\n"
"Triplets:\n"
)下面是最简陋的构建办法。
咱们要构建一个常识图谱，它的常识源头可能是很多张表，或者是很多非结构化的数据，要从中抽取进去要害的实体以及实体之间的关联关系（谓词），如果你想通过程序化的形式来实现常识提取，其实是很有难度的。事实上，咱们很多时候不只是在抽取常识，而是高质量地构建常识，这时候就须要用到 NLP 自然语言解决，或者是其余的技术。此外，这个抽取的数据最初还须要通过局部专家或者是人力去校验，把控数据品质。这个常识抽取的过程，其实老本是很低廉的。
实际上，整个常识抽取的各个环节，都能够借助大语言模型失去疾速地解决，比方：能够利用大语言模型生成代码，或者是间接提取非构造数据的常识。某种程度上，咱们能够用大语言模型来实成整个常识的抽取过程。
上文是让大语言模型从一段文字中抽取三元组的示例，这是一个简略的 prompt，通知程序：我当初提供了一些文字，你要帮我从中抽取最多 max_knowledge_triplets 的三元组，依照我给你的这个示例 (Philz, is, coffee shop) 的模式输入。当然，这里你能够让程序输入成 JSON、XML 格局。和大语言模型约定好输出和输入之后，这时候把文本批量丢给大语言模型，坐等大语言模型给你输入后果便是。
这里是我借助 Llama Index 这个大语言模型的 orchestrator 实现的多数据源的常识抽取，Llama Index 反对上百种数据源。实例中是抽取的维基百科数据，读取 Guardian of the Galaxy 第三部的长网页数据，Llama Index 会主动宰割数据，通过咱们之前 prompt 约定好的格局去解决数据，最终构建一个常识图。
这里有个残缺的介绍和 Demo：https://www.siwei.io/demos/text2cypher/ 能够去试玩下。这里简略讲下一些应用：
- 借助 GraphStore 形象，上面四行代码就能从维基百科的某一页抽取数据：
from llama_index import download_loader
WikipediaReader = download_loader("WikipediaReader")
loader = WikipediaReader()
documents = loader.load_data(pages=['Guardians of the Galaxy Vol. 3'], auto_suggest=False)- 调用配置好的大语言模型，抽取数据到 NebulaGraph，反对 ChatGLM-2 之类的各类模型：
kg_index = KnowledgeGraphIndex.from_documents(
documents,
storage_context=storage_context,
max_triplets_per_chunk=10,
service_context=service_context,
space_name=space_name,
edge_types=edge_types,
rel_prop_names=rel_prop_names,
tags=tags,
include_Embeddings=True,
)抽取完之后的数据，能够进行图谱可视化展现或者是用 Cypher 查问语句。
这个过程中，其实有一些可优化点，比方：借助额定的 prompt 将近似的实体进行合并，不须要全副选取，或者是预约义实体中的 Schema。欢送大家试玩之后，优化这个 Demo。
Text2Cypher
除了常识图谱的构建之外，大家在利用常识图谱或者是用图数据库 Graph Database 时，还面临着一个难题：query 的编写。往往写一些 query 语句时须要肯定的常识储备，像是理解 Cypher 或者是 nGQL（NebulaGraph 的图查询语言），这无疑会带来学习老本。
这里，咱们以基于 Knowledge Graph 的 QA 零碎为例，具体开展讲讲这个问题如何解决。大家相熟右侧的架构的话，其实晓得这是我之前做的一个名叫 siwi 的问答零碎，它次要基于 NebulaGraph 官网的 basketballplayer 的数据集实现。
下面标注区域，次要实现的是文字到 Cypher 的性能。它接管到一个 Sentence 语句的时候，须要进行用意辨认 Intent Matching，辨认进去外面的实体，把实体依照语义抽取进去。再依据不同的用意，把对应的槽填进去，最初依据填充的用意和槽生成 NebulaGraph 的 query。
这个过程其实是蛮简单的，如果这是一个单目标，像是问答，还挺好解决的，用穷举就能够实现。当然，谋求品质或者状况简单的话，可能会用到 NLP 技术。
当然，当初有了大语言模型，做这件事就更加不便、直观。这里能够提下在 ChatGPT 刚火的时候，大略往年 2 月份的时候，我做过一个更靠近 Text2Cypher 的一个我的项目，叫 ngql-GTP。在这个 Demo 视频里，你输出对应的 schema，再提出你的问题，零碎就能主动帮咱们写成一个适配 nGQL 语法的 query。而这件事也是大家期待大语言模型能帮咱们解决的，GitHub 上也有许多相干的文本转 SQL 或者是其余查询语言的我的项目。事实上，做这么一个 Text2Cypher 或者相似的利用，你要输出给大模型的 prompt 是很简略的
你是一位 NebulaGraph Cypher 专家，请依据给定的图 Schema 和问题，写出查问语句。schema 如下：---
{schema}
---
问题如下：---
{question}
---
上面写出查问语句：像下面便是，你首先定义了这个大语言模型的 role，它要表演什么角色。再通知这个 NebulaGraph 专家，你的图空间中数据结构是什么样，再把问题放进来，最初你的现实输入后果是什么，这些都和大语言模型讲述分明之后，这就是个现实的流程。但实操起来，你可能会减少一些额定的要求，像是：
- 只返回语句，不必给出解释，不必赔罪
- 强调不要写超出 schema 之外的点、边类型
就现状而言，你要失去称心的输入后果，来回调整你的 prompt 是肯定的，而 prompt 的现实成果调试，也是一门玄学。为了节俭大家调试的工夫，我的这一套曾经开源并奉献到了 LangChain 和 Llama Index，细节能够参考这篇文章《Text2Cypher：大语言模型驱动的图谱查问生成》
- LangChain 的链接：https://python.langchain.com/docs/modules/chains/additional/graph_nebula_qa
- Llama Index 的链接：https://siwei.io/graph-enabled-llama-index/knowledge_graph_query_engine.html
Text2Cypher 这里也有个 Demo，和下面的常识图谱是一个 Demo：
像是这样，很不便的，输出一个自然语言，就能够进行相干的查问。上面是对应 Text2Cypher 生成的查询语言
MATCH (p:`entity`)-[:relationship]->(e:`entity`)
WHERE p.`entity`.`name` == 'Peter Quill'
RETURN e.`entity`.`name`;像下面展现的，咱们还能够借助可视化工具，更直观地看到查问后果。而它具体实现的思路和咱们之前说的 prompt 调试有点不同，以 LangChain 为例，
## Langchain
# Doc: https://python.langchain.com/docs/modules/chains/additional/graph_nebula_qa
from langchain.chat_models import ChatOpenAI
from langchain.chains import NebulaGraphQAChain
from langchain.graphs import NebulaGraph
# 连贯 NebulaGraph 服务
graph = NebulaGraph(
space=space_name,
username="root",
password="nebula",
address="127.0.0.1",
port=9669,
session_pool_size=30,
)
# 实例化
chain = NebulaGraphQAChain.from_llm(llm, graph=graph, verbose=True)
chain.run("Tell me about Peter Quill?",) 在 LangChain 中引入 NebulaGraph，再连贯上你的 NebulaGraph 服务，实例化 NebulaGraphQAChain，再借助一行 chain.run() 函数，就能实现你的需要。相似的，在 Llama Index 有雷同的代码实现：
## Llama Index
# Doc: https://gpt-index.readthedocs.io/en/latest/examples/query_engine/knowledge_graph_query_engine.html
from llama_index.query_engine import KnowledgeGraphQueryEngine
from llama_index.storage.storage_context import StorageContext
from llama_index.graph_stores import NebulaGraphStore
nl2kg_query_engine = KnowledgeGraphQueryEngine(
storage_context=storage_context,
service_context=service_context,
llm=llm,
verbose=True,
)
response = nl2kg_query_engine.query("Tell me about Peter Quill?",) 下面是简略版的代码，如果你有趣味能够看 Demo 残缺 NoteBook 中的代码。这里再补充下，在 Llama Index 中还有额定的 generate_query 的办法，它次要实现返回 Cypher 而不做查问的性能，这样你就能取得对应的查问语句，而不是查问后果。
RAG 搜寻加强
前文也有做简略的 RAG 介绍，这里再补充下额定的点。
一般来说，咱们应用 RAG 时，会对文档进行 Embedding（对应上图的 1、2…96 分片），而咱们发问“Tell me …., please”时，也会进行 Embedding，再在 vectordb 向量数据库中进行 TopN 的匹配搜寻返回，将最靠近它的文档块（对应上图的 3、96）作为上下文，同问题一起输出给大语言模型。
但，这样做有什么问题呢？
如果当初咱们的问题是有对于乔布斯的，数据起源是乔布斯自传，而问题可能是他同苹果公司的关系，或者对于他在苹果产生的那些事。当初这个自传书籍中集中某个章节讲述了苹果公司的事件，它可能是 3、4 页的篇幅，而其余章节也有提到苹果公司，散布在 30 页中，这时候咱们是不合适采纳 Top30 的，因为会超出咱们的 Windows（token），导致对应的成本上升。
此外，咱们把常识片的内容放大，如果外面抽取进去常识图谱的话，大略可能是这样：
┌──────────────────┬──────────────────┬──────────────────┬──────────────────┐
│ .─. .─. │ .─. .─. │ .─. │ .─. .─. │
│(x)─────▶ y ) │ (x)─────▶ a ) │ (j) │ (m)◀────(x) │
│ `▲'`─' │ `─'`─' │ `─'│ `─' `─' │
│ │ 1 │ 2 │ 3 │ │ 4 │
│ .─. │ │ .▼. │ │
│(z)◀────────────┼──────────────────┼───────────(i)─┐│ │
│ `◀────┐ │ │ `─' ││ │
├───────┼──────────┴──────────────────┴─────────────────┼┴──────────────────┤
│ │ Docs/Knowledge │ │
│ │ ... │ │
│ │ │ │
├───────┼──────────┬──────────────────┬─────────────────┼┬──────────────────┤
│ .─. └──────. │ .─. │ ││ .─. │
│ (x ◀─────( b) │ (x) │ └┼▶(n) │
│ `─'`─' │ `─'│ │ `─' │
│ 95 │ │ │ 96 │ │ │ 98 │
│ .▼. │ .▼. │ │ ▼ │
│ (c) │ (d) │ │ .─. │
│ `─'│ `─' │ │ (x) │
└──────────────────┴──────────────────┴──────────────────┴──`─'─────────────┘ 能够看到，它外面的数据，有些是逾越 data triplet 的，像是散布在 1、3 片区的 i -> z，如果咱们只是用 Embedding 的话，这种关联关系就会被宰割，从而失落信息。此外，之前也提过，一般来说咱们创立 Embedding 时，没有将咱们的公有常识思考进去，而是针对通用型常识进行创立 Embedding。举个例子，保温大棚和保温杯，在语义上二者是有相似之处的。在咱们未理解具体的畛域常识时，光从语义角度，当咱们输出“保温杯”时，从向量类似度上，可能在在后果中会混淆二者一起输入给用户。这也是 Embedding 会产生的一些误会，或者是失落上下文关系的例子。
而采纳 Knowledge Graph 这种形式，它是更精炼，以及更高密度的常识总结。在保障精确度的状况下，还会保留畛域常识的语义，它是一个更细颗粒度的宰割，且保留了全局的数据连贯。
基于此，在 RAG 根底之上，咱们将问题中的实体进行抽取，生成大略这样的一个构造：
找到在问题实体的根底上构建的图的相干子图，将其同作为上下文一起输出给 LLM 这套工作流。最终实际下来，成果还是不错的。
能够看到，在原有的根底上，输入后果会更加的丰盛，因为借助了子图。具体的 demo 大家能够参考文末延长浏览里的链接，能够在线实时试玩一下。
总结
这是一个大语言模型，它能够做什么事呢？如上图 ① 所示，Graph（图 / 图数据库）能够在 Encounter Learning 或者是 RAG 时，帮忙咱们辅助 Embedding 工作。或是 ② 所示，借助 LLM，构建 Knowledge Graph，就是常识图谱。当然，当中波及到 prompt 的调试。此外，还有用户同数据库交互时，之前须要用到查询语言，当初借助 LLM，能够某种程度上用自然语言就能进行图数据库的查问。
而 NebulaGraph 将来在 LLM 这块的利用实际的话，咱们思考在做图剖析时，为 Graph 引入 analysis 的 Embedding，或者是从 Graph 登程，为它的子图创立更长的 Embedding，再依据 Embedding 进行搜寻。
LLM 你问我答
上面问题整顿收集于本场直播，由 Wey 同社区用户陈卓见一起回复。
大语言模型和常识图谱的联合案例
Q：目前大模型和常识图谱的联合案例有吗？有什么好的分享吗 ？
Wey：之前卓见老师在咱们社区分享过一篇文章《利用 ChatGLM 构建常识图谱》，包含我下面的分享，也算是一种实际分享。当然咱们后续会有更多的介绍。看看卓见有没有其余补充。
陈卓见：我是相干的 LLM 从业人员，不过外部窃密的缘故，这块可能不能和大家分享很多。基本上就是我之前文章所讲的那些，你如果有其余的问题交换，能够给文章留言，大家一起进一步交换下。
大模型入门教程
Q：当初如果要入门大语言模型的话，有什么好的入门教材 ？
Wey：如果是利用大语言模型的话，能够看下 LangChain 作者和吴恩达老师出的教程，据说这个教程还挺不错的。而我集体的话，会看一些论文，或者是追 LangChain 和 Llama Index 这两个我的项目的最新实现，或者曾经实现的货色，从中来学习下 LLM 能做什么，以及它是如何实现这些性能的。而一些新的论文实现，这两个我的项目也对其做了最小实现，能够很不便地疾速应用起来，像是怎么用 Embedding，它们反对哪些 Embedding 模型之类的事件。
陈卓见：思为分享的可能是偏应用层的，而对咱们这些 LLM 从业者而言更多的可能是如何训练大模型。比如说，咱们想实现某个性能，咱们应该如何去结构数据，抉择大模型。像是咱们团队，如果是来了一个实习生，会看他数学能力如何。如果数学不好的话，会先思考让他先多学点数学；如果数学程度不错，当初同大模型相干的综述文章也挺多的，会让他去看看综述文章，无论中文还是英文，都有不少相干的材料能够学习。像 transform 层，大模型训练的细节，分布式怎么做，工程化如何实现 ，都是要去理解的。当然，这外面必定是有侧重点的，你如果是想理解工程的常识，你能够去多看看工程常识；想理解底层原理，就多看看实践，因人而异。
这里给一些相干的材料，大家有趣味能够学习下：
- A Survey of Large Language Models：https://arxiv.org/abs/2303.18223，次要理解下基本概念；
- 中文版的综述《大语言模型综述》：https://github.com/RUCAIBox/LLMSurvey/blob/main/assets/LLM_Survey__Chinese_V1.pdf
如何基于 LLM 做问答
Q：NebulaGraph 论坛当初累计的问答数据和点赞标记，是不是很好的样本数据，能够用来搞个不错的专家客服 ？
Wey：在之前卓见老师的分享中，也提到了如果有高质量的问答 Pair，且有肯定的数据量，是能够思考用微调的形式，训练一个问答专家。当然，最间接、最简略的形式可能是下面分享说的 RAG 形式，用向量数据库 Embedding 下。
部署大模型的门路和实现配置
Q: 想问部署 65b 大模型最低老本的硬件配置和实现门路 ？
陈卓见：先看你有没有 GPU 的机器，当然 CPU 内存够大也是能够的，有一台 256B 内存的机器，应该 65b 也是能推理的。因为大模型分不同精度，个别咱们训练用到的精度是 fp16。而 fp16 的话，对于 65b 的模型，它大略显存占用大略是 120GB 到 130GB 之间。如果你用的内存训练的话，内存得超过这个量级，个别是 256GB，就能推理的。然而不大举荐用 CPU，因为它的速度可能只有等同规模 GPU 的 1/10，甚至 1/20、1/50 都有可能的，这具体得看你的环境。
如果你用 GPU，它是有几种抉择，如果你用 fp16 的精度想去做推理的话，那么你可能须要 2 张 80GB 显存的机器，比如说 A100、A800 这样机器能力行。但最低实现的话，你能够抉择 INT4 精度，这时候须要一个 40GB 左右的显存，比方买个 A6000，48GB 显存，它应该也是能推理的。但这个推理其实是有限度的，因为推理是一直的 next token prediction，是要始终生成 token 的，这就会占用你的显存。如果你让它写一篇长文的话，这时候 48GB 显存应该是不够用的，显存会爆。所以，你筹备 2 个 48GB 的显存，在 INT4 下能够不便地进行推理之余，还能搞搞模型并行，QPS 也会有所体现。然而单 48GB 显存的话，内存可能会爆。
最近比拟风行的有个 LLaMA CPP 我的项目，就反对 INT4 量化，而且将来还打算反对 INT2 量化。但 INT2 量化这个成果就不敢保障了，因为 INT4 至多有不少我的项目，像是 LLaMA、ChatGLM 都做过试验，测试下来精度损失不会那么大，然而 INT2 还没有实际数据进去，不晓得到底精度损失会有多少？
小结下，我倡议你最好是筹备一个 A800 的机器，或者是两个 A6000 这样的机器，或者四个 A30，都能做 65b 的推理。这个配置会比拟稳当一点。
下个问题。
Wey：这里我想诘问下卓见一个问题。我有一个富人版的 24GB 显存，临时还没试过 Fine-Tuning，然而我当初做失常精度的 6b 推理是 OK 的。如果是 INT4 的话，据说 6GB 显存就能够推理？
陈卓见：这里解释下显存和模型参数量的关系，如果你是 6b 模型的话，个别显存是 12GB，就能做失常的 fp16 推理，而 INT4 的话，间接显存除以 3，大略 4 GB 就能够做 INT4 的推理。如果你当初是 24GB 的显存，其实能够试试 13b 的模型。
非结构化数据如何存储到图
Q：非结构化的数据，比方就一本书，如何先存储到 graph 里 ？
Wey：😂 富人的实现思路，这个书如果是有 PDF 的话，间接用 Llama Index 6、7 行代码就能够扫入到数据库中。如果是之前咱们的 prompt 的话，用 NLP 业余角度判断的话，它其实成果并没有那么的好，然而能够承受。此外，Llama Index 还有个 hub 我的项目，如果你的 PDF 是纯光学扫描的话，它会主动 OCR 提取信息。
陈卓见：这里我补充下，你数据存储到图中要干嘛？如果是做一个问答，那么 Llama Index 是个不错的计划。如果是其余的需要，其实一个纯文本的 txt，可能也就行了。
如何筹备数据以及训练模型
Q：训练模型或者是进行 Fine-Tuning，在数据筹备方面有什么教训分享 ？
陈卓见：Fine-Tuning 要筹备的数据量取决于你要实现的性能，不同的事件难度，所需的数据量是不同的。比方，你要用 LLaMA 做一个中文问答，你要做中文的词表，筹备中文的问答数据，再搭配一部分英文的问答数据，这样做一个 LoRA 微调。但你如果是只做英文的问答，中文这块的数据就不须要了，用大量的英文数据，就能很好地调好模型。个别就是写 prompt，再写输入，组成对，LoRA 有规范格局，整成规范格局就能用。
模型的准确性
Q：在理论利用中，如何做畛域常识图谱的品控，确保 kg 就是常识图谱的内容齐备跟准确性，如果常识图谱的内容都错了怎么办 ？
陈卓见：其实，咱们个别是筹备好几个模型。大模型只是一部分，比如说咱们筹备三个模型，第一个模型是用大模型，第二个模型是 Bert + NER，第三个是基于规定的模型，而后这三个模型组成一个相似的投票模型。三个模型都通过的数据就放进去，两个模型通过的数据就让人校验下，只有一个通过的数据，目前咱们是不采纳的，间接不要。目前，实际下来，N+ 的准确率只有 70-80%，准确率并不是很高。但再通过一道 LoRA，准确率会进步点。倡议还是做多模型，绝对会保险一点。
大模型和 asr
Q：大模型的语言 ASR 解决有什么教训分享，比方：语音的特征提取怎么做 ？
陈卓见：这就是大模型的多模态，个别是先做小模型，对语音、图像进行 Embedding 之后，再归一成一个大模型。能够先看看语音的 Embedding 是如何实现的，再看看多模态的大模型是如何将其相结合。不过目前来说，尚在一个摸索阶段，没有十分成熟的解决方案。
模型固定输入
Q：让模型以固定模式回复问题，怎么构建数据训练模型呢？比如说法律问题要以什么法规去答复问题 ？
Wey：如果是训练的话，我其实没有做过 Fine-Tuning。如果是纯 prompt 的话，有几个准则：给出各种例子、各种强调输入后果格局，prompt 这套就是个黑匣子，有时候你来回调整语序就能失去不错的后果。当然有些边缘 case，可能难以依照固定的格局输入，你能够用正则表白做个兜底，确保最初的一个输入格局。
陈卓见：咱们在做 Fine-Tuning 的时候，在数据收集时，能够过滤掉一些偏见数据。还有就是在模型训练的微调阶段，有一个 Reward model，就是答复打分，你能够把某一类问题中你感觉答复的不好的回复打低分，而后在 PPO 阶段，模型进行学习时，就会升高输入这类答复的概率。一般来说，还是在 prompt 里加巨长的 prompt，可能是几百个 prompt，相似于不要答复什么，优先答复什么，写个很长这样的货色让它去做答复。个别不倡议在训练阶段，去做输入的格局的实现，因为老本十分低廉，绝对的写 prompt 的老本就低多了。
延长浏览
- LLM 相干的 Demo：www.siwei.io/demos
- 利用 ChatGLM 构建常识图谱：https://discuss.nebula-graph.com.cn/t/topic/13029
- 图技术在 LLM 下的利用：常识图谱驱动的大语言模型 Llama Index：https://discuss.nebula-graph.com.cn/t/topic/13624
- Text2Cypher，大语言模型驱动的图谱查问生成：https://www.siwei.io/llm-text-to-nebulagraph-query/
- 面向开发者的 Prompt Engineering：https://github.com/datawhalechina/prompt-engineering-for-developers
谢谢你读完本文 (///▽///)
如果你想尝鲜图数据库 NebulaGraph，记得去 GitHub 下载、应用、(^з^)-☆ star 它 -> GitHub；和其余的 NebulaGraph 用户一起交换图数据库技术和利用技能，留下「你的名片」一起游玩呀~
