本文整理自 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 用戶一起交流圖數據庫技術和應用技能，留下「你的名片」一起玩耍呀~