GraphRAG新增文件對已有知識庫影響有多大？緩存又是何時失效？一文帶你探究到底 原創
在使用 LLM 應用時，我們經常會遇到需要向知識庫中添加新文件的需求。傳統的 RAG 通過對 chunk 進行 embedding 來處理這種情況，并且新文件的加入不會影響之前生成的 chunk embedding。但是，GraphRAG 的處理方式有所不同。由于其索引過程涉及多個 pipeline 階段，因此可能會產生一些問題：當新文件加入時，是否需要對已有的文件重新進行索引？緩存在這個過程中起到了什么作用？哪些 workflow 需要重做？帶著這些問題，我們來一探究竟。
GraphRAG緩存
我們首先來看下GraphRAG的緩存的作用，GraphRAG默認使用文件緩存，配置如下。
cache:
type: file # or blob
base_dir: "cache"
# connection_string: <azure_blob_storage_connection_string>
# container_name: <azure_blob_storage_container_name>緩存數據被儲存在 'cache' 目錄下，并且根據不同的處理流程，它被分為四個主要部分：實體提取、總結描述、社區報告以及文本嵌入。因此，幾乎所有涉及到 LLM 或者 Embedding 調用的環節都在緩存中得到了覆蓋。
緩存文件的命名規則是基于 "tag" 和 "hash" 值進行組合，例如：chat-02c8a6be0acf8abe79b876438853cebb 或 create_community_report-chat-v2-0a8d6dcd76f6d92edb9388681da40d1d。那么，緩存的具體內容包含什么呢？實際上，它就是 LLM 的請求輸入和響應輸出，或者是 Embedding API 調用的返回結果。
那么何時緩存會生效？修改哪些部分會影響緩存呢？讓我們看GraphRAG中如下代碼，它是為緩存文件生成文件名，也就是上文看到文件名。
def create_hash_key(
operation: str, prompt: str, parameters: dict, history: list[dict] | None
) -> str:
"""Compute cache key from prompt and associated model and settings.
Args:
prompt (str): The prompt run through the language model.
llm_string (str): The language model version and settings.
Returns
-------
str: The cache key.
"""
llm_string = _llm_string(parameters)
history_string = _hash(json.dumps(history)) if history else None
hash_string = (
_hash(prompt + llm_string + history_string)
if history_string
else _hash(prompt + llm_string)
)
return f"{operation}-{hash_string}"從這份代碼可以看到有三個因素影響hash值的生成：
- 輸入的Prompt，包含用戶輸入
- LLM 參數
- 聊天歷史
那么，何時會導致緩存失效呢？
- 首先，如果我們修改了 LLM 的參數，如 model_name、temperature、top_p 等，緩存就會失效。
- 其次，當我們帶著聊天歷史的時候，每輪聊天都會新增聊天歷史，在進行聊天的時候緩存也失效
- 最后，如果調用 LLM 的輸入提示（prompt）發生改變，緩存同樣會失效。這點尤其重要，因為在添加新文件的情況下，我們通常不會修改 LLM 的參數，但可能會影響到 prompt，或更準確地說，可能會影響 prompt 模板中的變量值。那么，哪些 workflow 會影響 GraphRAG prompt 模板中的值呢？
哪些workflow會受到影響
GraphRAG index的14個workflow可以進一步細分為四大類：
- 關于文檔的document_workflows
- craete_final_documents
- create_base_document
- 關于文檔單元的text_unit_workflows
- join_text_units_to_entity_ids
- join_text_units_to_relationship_ids
- create_final_text_units
- create_base_text_units
- 構建圖譜的graph_workflows
- create_summarized_entities
- create_base_entity_graph
- create_final_entities
- create_final_relationships
- create_final_nodes
- create_base_extracted_entities
- 社區聚類的community_workflows
- create_final_communities
- create_final_community_reports
各個workflow的內部詳細做了哪些事可以參考之前的文章??小白也能讀懂的GraphRAG知識圖譜全流程解析，多圖預警！??
在此，我將重點探討新增文件對于某些核心工作流程的影響：
- ?
?create_base_text_units??：這個步驟用于將文件切分成多個 chunk。雖然對于已經存在的文件而言，此步驟可能會進行重復切分，但由于切分本身的代價相對較小，所以并不會造成大的影響。 - ?
?create_base_extracted_entities??：這個步驟是根據 chunk 來生成對應的實體。對于已有的文件，其 chunk 是不會改變的，因此可以利用緩存來加快速度。然而，對于新文件，我們需要調用 LLM 來執行新的實體抽取。除此之外， create_base_extracted_entities一個比較重要的子步驟是 ??merge_graphs???，它的任務是將多個子圖合并成一個新的大圖。由于我們新增了文件，因此也就意味著有了新的子圖需要合并。例如，如果 A.txt 和 B.txt 這兩個文件都包含 "路飛" 這個實體，在 ??merge_graphs?? 中，A.txt 和 B.txt 的 "路飛" 會被合并成一個新的實體，并更新實體的 description 列表 - ?
?create_summarized_entities???：此過程將對節點（node）和關系（relationship）的描述（descriptions）進行匯總。如果新增的文件包含與舊文件相同的實體，那么經過??create_base_extracted_entities?? 后，節點和關系的描述也會改變。因此，填充到prompt??summarize_descriptions.txt?? 的??description_list?? 變量的值也會改變，無法利用緩存，必須重新執行。但是，如果新文件和舊文件內容沒有任何關聯，那么節點和關系的描述就不會改變，這時就能利用緩存了。 - ?
?create_final_entities???：此過程將對節點進行嵌入化處理（embedding），以便于后續查詢。如果新增的文件與舊文件有緊密的關系，比如存在相同的實體，那么經過??create_summarized_entities?? 后，描述將會改變，從而導致嵌入的輸入也發生改變，無法利用緩存。然而，當新文件與舊文件的內容完全無關時，舊文件的??name_description?? 字段則無需重復進行嵌入。 - create_final_communities：此過程是進行社區檢索重新生成社區，新增文件會產生新的社區或者對已有社區進行修改，所以這個工作流程需要重新執行
- ?
?create_final_community_reports??：此過程借助 LLM 生成每個社區的摘要信息。如果新文件與舊文件的內容相關，會對已有的社區產生影響，需要重新進行 LLM 操作。而如果新文件和舊文件內容無關，那么生成的社區是全新的，舊的社區可以利用緩存，然后使用 LLM 為新社區生成對應的報告
總結
從上面的內容可以看出，新增文件的社區檢測和生成是必不可少的。如果新增的文件與知識庫中的已有知識相關聯，GraphRAG需要做的工作會更多。值得一提的是，知識庫的增長是一個漸進的過程，因此了解GraphRAG在處理新增內容時的邏輯對于我們評估成本和效果非常有幫助。通過這個過程，我們可以加深對GraphRAG整套流水線的理解。
?
本文轉載自公眾號AI 博物院 作者：longyunfeigu
