水漲船高，法學碩士的最新進展也不例外。在這篇博文中，我們將探討知識圖譜如何從法學碩士中受益，反之亦然。
特別是，知識圖可以使用 Graph RAG 將 LLM 與事實結合起來，這比 Vector RAG 更便宜。我們將查看 LlamaIndex 中的 10 行代碼示例，看看它是多么容易啟動。法學碩士可以幫助構建自動化知識圖譜，這在過去一直是一個瓶頸。圖表可以為您的領域專家提供一個界面來監督您的人工智能系統。
Spacy IRL 2019 的記憶之旅
我從事自然語言處理工作已經有幾年了，我已經看到了大型語言模型的興起。我的 NLP 和圖工作開始可以追溯到 2018 年，當時我在德國柏林的一家足球媒體公司 OneFootball 擔任機器學習工程師，并將其應用于體育媒體領域。
作為一名從業者，我對那段時光記憶猶新，因為那是 NLP 領域發生巨大變革的時期。我們正在從基于規則的系統和詞嵌入時代轉向深度學習時代，從 LSTM 轉向基于 Transformer 架構的 Elmo 或 ULMfit 等一系列模型。我是少數能夠參加在柏林舉行的 Spacy IRL 2019 會議的幸運者之一。隨后舉辦了企業培訓研討會，討論了變形金剛、對話式人工智能助手以及 NLP 在金融或媒體領域的應用。
在主題演講NLP 中缺失的元素 (spaCy IRL 2019) 中，Yoav Goldberg 預測下一個大的發展將是讓非專家也能使用 NLP。他是對的。他認為我們可以通過人類在深度學習的幫助下編寫規則來實現這一目標，從而產生透明且可調試的模型。他錯了。我們通過聊天達到了這一點，現在我們的模型透明度和可調試性都較差。我們在他的圖表上進一步向右和向下移動（見下文），到達比深度學習更深的地方。我們是否可以轉向適用于非專家且數據很少的更透明的模型，目前尚無定論。
在我當時的雇主 OneFootball 的背景下，OneFootball 是一家擁有 12 種語言、每月擁有 1000 萬活躍用戶的足球媒體，我們使用 NLP 來協助我們的新聞編輯室并解鎖新產品功能。我構建了從足球文章中提取實體和關系、標記新聞并向用戶推薦文章的系統。我在柏林 NLP 聚會的之前的演講中分享了其中的一些工作。我們有中等數據，但不是很多。我們有“重新標記”形式的部分標簽。我們也無法支付太多的計算費用。所以我們必須要有創意。這是應用 NLP 的領域。
就是在那里，我偶然發現了圖譜的美麗世界，特別是我現在的朋友 Paco Nathan 及其圖書館的偉大作品 pytextrank。圖（以及基于規則的匹配器、弱監督和我多年來應用的其他 NLP 技巧）幫助我處理少量帶注釋的數據，并結合領域專家的聲明性知識，同時構建一個可由非專家使用和維護的系統，具有一定程度的人機協作。我們提供了更好的標簽系統和新的推薦系統，我被迷住了。
如今，隨著法學碩士的興起，我看到了將圖譜和法學碩士這兩個世界結合起來的巨大潛力，我想與您分享。
1。使用圖 RAG 進行事實基礎
1.1 微調與檢索增強生成
圖表和法學碩士的第一個交匯點是事實基礎領域。法學碩士面臨著幻覺、知識切斷、偏見和缺乏控制等問題。為了規避這些問題，人們轉向了可用的域數據。特別是，出現了兩種方法：微調和檢索增強生成（RAG）。
首席科學家 Waleed Kadous 博士在 3 個月前的 AI 大會上生產中的法學碩士演講中在 AnyScale 上，對兩種方法之間的權衡提供了一些啟示。 “微調是為了形式，而不是事實，”他說 。 “RAG 代表事實”。
微調將變得更容易、更便宜。開源庫，例如 OpenAccess-AI-Collective/axolotl 和 OpenAccess-AI-Collective/axolotl com/huggingface/trl”>huggingface/trl 已經使這個過程變得更容易。但是，它仍然是資源密集型的，并且需要更多的 NLP 成熟度作為一項業務。另一方面，RAG 更容易訪問。
根據 2 個月前的黑客新聞帖子，詢問 HN：如何在我的計算機上訓練自定義 LLM/ChatGPT 2023年12月的文件？，絕大多數從業者確實在使用RAG而不是微調。
1.2 矢量 RAG 與圖 RAG
當人們說RAG時，他們通常指的是Vector RAG，它是一個基于向量數據庫的檢索系統。在他們的博客文章和隨附的筆記本教程，NebulaGraph 引入了一種稱為 Graph RAG 的替代方案，這是一個基于圖數據庫的檢索系統（免責聲明：他們是圖數據庫供應商）。他們表明，RAG 系統檢索的事實將根據所選架構的不同而有所不同。
它們還顯示在單獨的教程部分中LlamaIndex 文檔指出，Graph RAG 更簡潔，因此在代幣方面比 Vector RAG 更便宜。
1.3 RAG動物園
為了理解不同的 RAG 架構，請考慮我創建的以下圖表：
在所有情況下，我們都用自然語言 QNL 提出問題，并用自然語言 ANL 得到答案。在所有情況下，都有某種從問題中提取結構的編碼模型，再加上某種生成答案的生成器模型（“答案生成器”）。
Vector RAG 嵌入查詢（通常使用比 LLM 更小的模型；例如 FlagEmbeddings 或 Huggingface Embeddings Leaderboard）到向量嵌入 vQ 中。然后，它從向量數據庫中檢索最接近 vQ 的前 k 個文檔塊，并將它們作為向量和塊返回 (vj, Cj< /子>）。這些內容與 QNL 作為上下文一起傳遞給 LLM，生成答案 ANL。
Graph RAG 從查詢中提取關鍵字 ki 并從圖中檢索與關鍵字匹配的三元組。然后將三元組 (sj, pj, oj) 與 QNL 一起傳遞給 LLM ，生成答案 ANL。
結構化 RAG 使用生成器模型（LLM 或更小的微調模型）以數據庫的查詢語言生成查詢。它可以生成 RDBMS 的 SQL 查詢或 Graph DB 的 Cypher 查詢。例如，假設我們查詢 RDBMS：模型將生成 QSQL，然后將其傳遞到數據庫以檢索答案。我們記下答案 ASQL，但這些是在數據庫中運行 QSQL 產生的數據記錄。答案 ASQL 以及 QNL 被傳遞到 LLM 以生成 ANL。
在混合 RAG 的情況下，系統使用上述的組合。除了本文之外，還有多種混合技術。簡單的想法是，您將更多上下文傳遞給 LLM 的 Answer Gen，然后讓它利用其總結能力來生成答案。
1.4 LlamaIndex 中的圖 RAG 實現
現在的代碼，使用當前的框架，我們可以用 10 行 Python 構建一個 Graph RAG 系統。
?
“`” data-lang=”text/x-python”>
```python
從 llama_index.llms 導入 Ollama
從 llama_index 導入 ServiceContext、KnowledgeGraphIndex
從 llama_index.retrievers 導入 KGTableRetriever
從 llama_index.graph_stores 導入 NebulaGraphStore
從 llama_index.storage.storage_context 導入 StorageContext
從 llama_index.query_engine 導入 RetrieverQueryEngine
從 llama_index.data_structs.data_structs 導入 KG
從 IPython.display 導入 Markdown，顯示
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="維基百科", edge_types=["關系"], rel_prop_names=["關系"], 標簽=["實體"])
storage_context = StorageContext.from_defaults(graph_store=graph_store)
kg_index = KnowledgeGraphIndex(index_struct=KG(index_id="向量"), service_context=service_context, storage_context=storage_context)
graph_rag_retriever = KGTableRetriever（索引= kg_index，retriever_mode =“關鍵字”）
kg_rag_query_engine = RetrieverQueryEngine.from_args(retriever=graph_rag_retriever, service_context=service_context)
response_graph_rag = kg_rag_query_engine.query("告訴我關于彼得·奎爾的事。")
顯示(Markdown(f"{response_graph_rag}"))
```此代碼段假設您有 Ollama 提供 mistral 模型和本地運行的 Nebula 實例。它還假設您的 Nebula 數據庫中加載了知識圖，但如果沒有，我們將在下一節中介紹如何構建知識圖。
星云入門詳細信息
?
您可以使用 Docker 桌面 Nebula 擴展啟動 Nebula 實例。
運行 Nebula 后，您需要進行首次設置：
?
```密碼
添加主機“存儲0”：9779，“存儲1”：9779，“存儲2”：9779
```那么在使用之前需要先創建索引：
?
```密碼
創建空間維基百科（vid_type = FIXED_STRING（256），partition_num = 1，replica_factor = 1）；
```和：
?
```密碼
使用維基百科；
創建標簽實體（名稱字符串）；
創建邊緣關系（關系字符串）；
創建標簽索引實體索引實體（名稱（256））；
```在進行推理之前，您需要在向量數據庫或圖形數據庫中對數據建立索引。
RAG 的索引架構 Vector RAG 的分塊和嵌入文檔相當于為 Graph RAG 提取三元組。三元組的形式為 (s, p, o)，其中 s 是主語，p 是謂語，o 是賓語。主語和賓語是實體，謂語是關系。
有幾種方法可以從文本中提取三元組，但最常見的方法是使用命名實體識別器 (NER) 和關系提取器 (RE) 的組合。 NER 將提取諸如“Peter Quill”和“Guardians of the Galaxy Vol 3”之類的實體，而 RE 將提取諸如“plays role in”和“directed by”之類的關系。
有專門針對 RE 的微調模型，例如 REBEL，但人們開始使用 LLM 來提取三元組。這是 LlamaIndex for RE 的默認提示鏈：
?
```jinja
下面提供了一些文字。給定文本，提取最多
{max_knowledge_triplets}
形式為（主語、謂語、賓語）的知識三元組。避免停用詞。
--------------------
例子：
文本：愛麗絲是鮑勃的母親。
三胞胎：（愛麗絲，是鮑勃的母親）
文字：Philz 是一家于 1982 年在伯克利成立的咖啡店。
三胞胎：
（Philz，是，咖啡店）
（菲爾茲，創立于伯克利）
（菲爾茲，成立于 1982 年）
--------------------
文本：{文本}
三胞胎：
```這種方法的問題在于，首先您必須使用正則表達式解析聊天輸出，其次您無法控制提取的實體或關系的質量。
2.2 LlamaIndex中的KG構建實現
但是，使用 LlamaIndex，您可以使用以下代碼片段在 10 行 Python 中構建知識圖譜：
?
```python
從 llama_index.llms 導入 Ollama
從 llama_index 導入 ServiceContext、KnowledgeGraphIndex
從 llama_index.graph_stores 導入 NebulaGraphStore
從 llama_index.storage.storage_context 導入 StorageContext
從 llama_index 導入 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="維基百科", edge_types=["關系"], rel_prop_names=["關系"], 標簽=["實體"])
storage_context = StorageContext.from_defaults(graph_store=graph_store)
loader = download_loader("WikipediaReader")()
文檔 = loader.load_data(pages=['銀河護衛隊第 3 卷'], auto_suggest=False)
kg_index = KnowledgeGraphIndex.from_documents(
文件，
存儲上下文=存儲上下文，
服務上下文=服務上下文，
max_triplets_per_chunk=5,
include_embeddings=真，
kg_triplet_extract_fn=無,
kg_triple_extract_template=無,
space_name=“維基百科”，
edge_types=["關系"],
rel_prop_names=["關系"],
標簽=[“實體”]，
）
```2.3 基于LLM的KG構建的失敗模式示例
但是，如果我們查看電影“銀河護衛隊第 3 卷”的最終 KG，我們可以注意到一些問題。
以下是問題的表格概述
論文 從兩周前開始，Google 已開始使用語言模型來幫助其查找和發現其C/C++、Java 和 Go 代碼。結果令人鼓舞：它最近開始使用基于 Gemini 模型的法學碩士“成功修復了單元測試期間發現的 15% 的消毒劑錯誤，從而修復了數百個錯誤”。盡管15%的接受率聽起來相對較小，但它對谷歌的規模影響很大。錯誤管道產生了比人類更好的修復——“發送給代碼所有者的大約 95% 的提交未經討論就被接受了，”谷歌寫道。 “這比人工生成的代碼更改的接受率更高，而人工生成的代碼更改經常引發問題和評論。”