拉德事實

其他源碼

下載

RadFact：基於法學碩士的人工智慧產生放射學報告的評估指標

RadFact 是一個框架，用於評估模型產生的放射學報告（給定真實報告，無論是否有依據） 。利用大型語言模型的邏輯推理能力，RadFact 不是一個單一的數字，而是一套指標，捕捉純文本和文本和基礎級別的精確度和召回率方面。

RadFact 在 MAIRA-2：基礎放射學報告產生中引入。在這裡，我們提供了該指標的開源實現，以方便其使用和開發。

入門

安裝

為了運行 RadFact，您只需克隆此存儲庫並運行以下命令：

pip install .

這將安裝radfact套件及其所有相依性。

或者，我們提供一個Makefile來設定包含所有依賴項的 conda 環境。您可以使用以下方式建立環境：

make miniconda
make mamba
make env
conda activate radfact

第一步安裝 miniconda，第二步安裝 mamba 以快速解決依賴關係，第三步驟建立一個名為radfact的 conda 環境，其中包含所有相依性。預設情況下，這也將透過setup_packages_with_deps配方以可編輯模式安裝 radfact 套件（請參閱 Makefile）。最後，啟動RadFact的運行環境。如果您打算為該專案做出貢獻，強烈建議您這樣做。

端點 (LLM) 設定

要使用 RadFact，您需要存取大型語言模型。您需要先透過驗證設定端點，然後使用我們的測試腳本確認它們的行為符合預期。

LLM 應以 API 端點提供，並受到langchain （版本 0.1.4）的支援。我們支援兩種類型的模型：AzureChatOpenAI 和 ChatOpenAI 模型。前者適用於 Azure 上提供的 GPT 模型，而後者適用於 Azure 中的 Llama-3 等自訂部署模型。

端點認證

我們支援以下認證方式：

API Key 環境變數：將API_KEY環境變數設定為端點的 API 金鑰。我們使用API_KEY作為預設環境變數名稱。如果您使用不同的名稱，您可以透過api_key_env_var_name在端點配置中指定它。當使用具有不同 API 金鑰的多個端點時，這尤其有用。
Azure Key Vault 中的 API 金鑰：從 AzureML 工作區的預設 Azure Key Vault 擷取 API 金鑰。這需要：
1. 在專案的根目錄中新增 AzureML 工作區設定檔config.json 。此配置應具有鍵subscription_id 、 resource_group和workspace_name 。可以透過入口網站從 AzureML 工作區下載它。該文件被加到.gitignore以避免意外提交。確保按照端點類別的預期將檔案保存在專案的根目錄中，名稱為config.json 。
2. 在端點配置中指定key_vault_secret_name 。
透過 Azure 令牌提供者進行基於令牌的身份驗證：這依賴於基於令牌的授權。如果未設定上述方法，我們將回退到產生 Azure 令牌提供者（假設您已設定正確的 Azure 憑證）。令牌提供者設定為允許自動令牌刷新的AzureChatOpenAI模型的azure_ad_token_provider參數。僅AzureChatOpenAI模型支援此功能。

要了解有關如何在 RadFact 中整合 enpoint 的更多信息，請參閱arguments.py 中的LLMAPIArguments類，該類使用 endpoint.py 中Endpoint類的端點物件。

設定端點配置

我們使用 Hydra 進行設定管理。端點配置位於路徑： configs/endpoints中。

這是設定檔的範例：

"
  deployment_name: "llama3-70b"
  api_key_env_var_name: ""
  keyvault_secret_name: ""
  speed_factor: 1.0
  num_parallel_processes: 10"> ENDPOINT_EXAMPLE :
  type : " CHAT_OPENAI "
  url : "  "
  deployment_name : " llama3-70b "
  api_key_env_var_name : "  "
  keyvault_secret_name : "  "
  speed_factor : 1.0
  num_parallel_processes : 10

有 2 種端點type: "CHAT_OPENAI"和type: "AZURE_CHAT_OPENAI"取決於所使用的模型端點。對於 Azure 上可用的 GPT 模型，請使用type: "AZURE_CHAT_OPENAI" 。對於 Azure 上的 Llama-3 等自訂部署模型，請使用type: "CHAT_OPENAI" 。
您將需要使用適當的值更新url和可能的deployment_name欄位。
keyvault_secret_name是可選的，如果您透過環境變數設定 api，則不需要。如果您對 API 金鑰使用的環境變數名稱與預設的"API_KEY"不同，請更新api_key_env_var_name 。使用多個端點時，為每個端點指定不同的api_key_env_var_name 。
當有多個端點可用時，使用speed_factor選項。這允許您指定端點與其他端點相比的相對速度，用於按比例跨端點分片資料。
選項num_parallel_processes用於指定查詢特定端點時要使用的平行進程數。所有請求均依序處理，除非num_parallel_processes設定為大於 1 的值（允許並行處理）。

如上所述，當使用 RadFact 評估無根據的報告（例如敘述性報告）時，RadFact 首先將報告轉換為短語清單。我們在此步驟中使用 LLM，但它不需要與用於蘊涵驗證的 LLM 相同。您可以在override endpoints: ：

configs/report_to_phrases.yaml -- 將報表轉換為片語清單。在 MAIRA-2 中，我們為此使用了 GPT-4，它可以作為 AzureChatOpenAI 模型進行查詢。
configs/radfact.yaml蘊含驗證。在 MAIRA-2 中，我們使用LLama-3-70B-Instruct來實現此目的，它可以作為 ChatOpenAI 模型進行查詢。

確認蘊含驗證正在工作

不同的後端法學碩士可能表現不同並產生不同的指標結果。特別是，在蘊含驗證方面表現不佳的模型不應該用於 RadFact。若要確認蘊涵驗證的行為符合預期，請執行python src/radfact/cli/run_radfact_test_examples.py並確認結果與預期類似。使用LLama-3-70b-Instruct模型獲得了預期結果。

請注意，這不會測試報告到短語步驟的行為。

用於平行處理的 LLMEngine

LLMEngine類別支援跨多個端點的並行處理。如果您可以存取具有不同吞吐量的多個端點，引擎可以根據端點的速度按比例將資料分片。該引擎還允許並行處理到單一端點的請求。無論端點數量多少，預設都會使用此選項。有關speed_factor和num_parallel_processes選項，請參閱端點設定檔。此外，該引擎還負責結果的批次和中間快取。所有中間結果都儲存在標有起始時間戳記的 run id 資料夾下的outputs/radfact目錄中，例如outputs/radfact/run_20240814_075225 。資料夾結構如下：

  outputs/radfact/run_20240814_075225
  ├── batch_outputs
  │   ├── outputs_0_100.json
  |   ├── .
  |   ├── .
  |   ├── .
  │   └── outputs_1000_1100.json
  ├── progress
  │   ├── subset_0_240.csv
  |   ├── .
  |   ├── .
  |   ├── .
  │   └── subset_800_1100.csv
  ├── skipped
  │   ├── subset_0_240.csv
  |   ├── .
  |   ├── .
  |   ├── .
  │   └── subset_800_1100.csv
  ├── outputs.json
  ├── progress.csv
  └── skipped.csv

outputs.json包含所有資料點的最終結果。 progress.csv包含每個端點的處理進度。 batch_outputs包含每個批次大小的中間結果。 skipped包含由於錯誤而被跳過的資料點。

運行 RadFact

您可以參考 getting_started 筆記本來了解如何在您自己的資料上執行 RadFact。我們強烈建議您先閱讀筆記本以了解 RadFact 工作流程以及如何使用它。我們還提供了一個腳本來對您的資料運行 RadFact。確保在運行腳本之前已按上述方式設定端點。 run_radfact指令在背景執行python src/radfact/cli/run_radfact.py腳本。您可以透過執行run_radfact --help透過下面解釋的命令列參數來覆寫預設行為。您需要在本機安裝該軟體包才能執行該腳本。

$ run_radfact --help
usage: run_radfact [-h] [--radfact_config_name RADFACT_CONFIG_NAME] [--phrases_config_name PHRASES_CONFIG_NAME] --input_path INPUT_PATH [--is_narrative_text] [--output_dir OUTPUT_DIR] [--bootstrap_samples BOOTSTRAP_SAMPLES]

Compute RadFact metric for a set of samples and saves the results to a json file.

options:
  -h, --help            show this help message and exit
  --input_path INPUT_PATH
                        The path to the csv or json file containing the samples to compute RadFact for. For finding generation samples, the csv file should have columns ' example_id ' ,
                        ' prediction ' , and ' target ' similar to the example in ` examples/findings_generation_examples.csv ` . For grounded reporting samples, provide a json file in the
                        same format as ` examples/grounded_reporting_examples.json ` .
  --is_narrative_text   Whether the input samples are narrative text or not. If true, the input samples are expected to be narrative text, otherwise they are expected to be grounded
                        phrases.
  --radfact_config_name RADFACT_CONFIG_NAME
                        The name of the config file for RadFact processing. We use the default config file but you can provide a custom config. Make sure the config follows the same
                        structure as ` configs/radfact.yaml ` and is saved in the ` configs ` directory. This is necessary for hydra initialization from the ` configs ` directory.
  --phrases_config_name PHRASES_CONFIG_NAME
                        The name of the config file for reports to phrases conversion. We use the default config file but you can provide a custom config. Make sure the config follows
                        the same structure as ` configs/report_to_phrases.yaml ` and is saved in the ` configs ` directory. This is necessary for hydra initialization from the ` configs `
                        directory.
  --output_dir OUTPUT_DIR
                        Path to the directory where the results will be saved as a json file.
  --bootstrap_samples BOOTSTRAP_SAMPLES
                        Number of bootstrap samples to use for computing the confidence intervals. Set to 0 to disable bootstrapping.

對於無根據的報告（調查結果產生敘述性文字）：

  run_radfact --input_path < path_to_input_file.csv > --is_narrative_text

對於接地報告：

  run_radfact --input_path < path_to_input_file.json >

有關輸入檔案的預期格式，請參閱examples目錄中的範例輸入檔。輸入檔案的格式應為 CSV 檔案（適用於非接地報告findings_ Generation_examples.csv）和 JSON 檔案（用於接地報告 grounded_reporting_examples.json）。

此腳本使用引導計算指標的置信區間。可以使用--bootstrap_samples參數來控制引導樣本的數量。預設值為--bootstrap_samples 0 。

️警告：由於端點限制（逾時、速率限制等），某些查詢可能會失敗。當LLM執行蘊涵驗證失敗時，我們預設將這些例子設為不蘊含。如果這種情況在大量情況下發生，結果將不可靠。最終的指標字典包含鍵num_llm_failures下此類跳過的查詢的數量。該腳本將在運行結束時列印跳過的查詢數，並將它們儲存在執行 id 資料夾下的skipped目錄中。您還將在日誌中看到每個失敗查詢的警告訊息。 WARNING: No response for example {query_id}. Setting as NOT ENTAILED 。

將報告拆分為短語

我們還提供了一個將報告轉換為短語的腳本。當您有敘述性報告並希望將其轉換為短語清單以進行 RadFact 評估時，這非常有用。您可以離線執行此步驟，然後使用輸出檔案作為 RadFact 的輸入。確保在運行腳本之前已按上述方式設定端點。 run_report_to_phrases指令在背景執行python src/radfact/cli/run_report_to_phrases.py腳本。

  run_report_to_phrases dataset.csv_path= < your_path_to_cxr_reports >

此腳本可使用report_to_phrases.yaml設定檔進行設定。您可以指定用於轉換的輸入檔、輸出檔和端點。

什麼是 RadFact？

Illustration of RadFact

如有必要，RadFact 首先將報告分解為最多描述一個發現的單一句子。然後，它使用大型語言模型的邏輯推理功能來確定給定參考報告的這些句子是否在邏輯上得到支持（「包含」）。我們從兩個方向進行計算，首先使用真實（原始）報告作為參考，反之亦然，使用模型產生的報告作為參考。這允許對正確性和完整性進行量化。

總體而言，RadFact 提供了六種（基礎）報告品質衡量標準：

公制	定義	它告訴我們什麼？	接地？
邏輯精確	真實報告所包含的生成句子的比例。	模型生成的真實程度如何：它會懲罰不正確的生成。	❌
邏輯回憶	產生的報告所包含的真實句子的比例。	產生的報告的完整性如何：它會懲罰遺漏。	❌
接地精度	邏輯蘊涵的接地生成句子中也具有空間蘊含的部分。	正確生成的發現也有正確依據的頻率有多少？	✔️
接地召回	邏輯上蘊含的、空間上蘊涵的事實句子的比例。	正確捕獲的發現也有正確依據的頻率有多少？	✔️
空間精度	所有接地生成的句子中邏輯和空間蘊涵的部分。	低分意味著模型產生了不必要的框或錯誤句子的框。	✔️
空間回憶	所有接地事實句子中在邏輯上和空間上都蘊涵的部分。	低分意味著模型無法為參考文獻中的發現產生框，可能是因為錯誤地描述了發現或根本沒有描述發現。	✔️

空間{精確度，召回率}不如其他指標直接解釋，但我們將它們包括在內以控制基礎{精度，召回}中隱含的分母：如果我們僅評估通過基礎測量的邏輯蘊含句子框的質量{精確度，召回率}，我們不會捕獲與錯誤句子相關的無關框（例如完全捏造的發現）或與遺漏發現相關的缺失框而引起的接地故障。

它是如何運作的？

RadFact 分兩步驟使用法學碩士。在這兩種情況下，我們都使用大約 10 個小樣本範例。

將報告轉換為最多描述一個發現的單一句子列表。這些少數樣本來自 MIMIC-CXR 風格的綜合發現。原始 MIMIC 報告受到禁止重新分發的資料使用協議的保護。因此，使用綜合報告。對於接地報告場景不需要此步驟，我們期望報告已格式化為句子清單（每個句子可能帶有邊界框）。
執行蘊含驗證。我們從兩個方向進行此操作，使用地面實況報告作為參考（提供精確度指標），或使用模型產生的報告作為參考（提供召回指標）。

單向蘊涵驗證（步驟 2 的一部分）的工作原理如下：

對於候選報告中的每個句子：給定參考報告中的所有句子，我們用以下內容查詢法學碩士：“這句話是蘊含的嗎？”如果是，請提供支持證據」。支持證據是參考報告中的句子。
為了計算空間蘊涵，我們使用證據。如果一個句子的盒子充分包含在其證據的聯合內，則它是空間蘊含的。實際上，這意味著我們需要高於 0.5 的像素精度，例如候選框中至少 50% 的像素位於證據框中。

這使我們能夠將每個句子標記為邏輯蘊涵（或非）和空間蘊涵（或非），從而計算上面列出的 RadFact 指標。請注意，空間蘊含僅針對有框的句子定義。

我們從哪裡得到這些少數樣本的例子？

為了將報告轉換為單獨的句子，我們使用FINDINGS部分產生了 MIMIC-CXR 報告風格的綜合範例。原始 MIMIC 報告受到禁止重新分發的資料使用協議的保護。我們手動將敘述性報告分成單獨的句子。範例和系統訊息可以在llm_utils.report_to_phrases.prompts下查看。

對於蘊涵驗證，少數樣本範例來自私人資料集（“USMix”）。每個範例都包含來自兩個報告的句子，我們使用 tf-idf 統計數據選擇相似但不相同的句子。然後，我們與放射科顧問合作，手動為它們貼上隱含狀態和證據的標籤。儘管是一項邏輯推理任務，但蘊涵驗證存在一定程度的主觀性，這是由於對某些概念的解釋有多嚴格而產生的。因此，其中一些例子可能存在爭議。範例和系統訊息可在llm_utils.nli.prompts下找到。

引文

若要引用 RadFact，您可以使用：

 @article { Bannur2024MAIRA2GR ,
  title = { MAIRA-2: Grounded Radiology Report Generation } ,
  author = { Shruthi Bannur and Kenza Bouzid and Daniel C. Castro and Anton Schwaighofer and Sam Bond-Taylor and Maximilian Ilse and Fernando P'erez-Garc'ia and Valentina Salvatelli and Harshita Sharma and Felix Meissen and Mercy Prasanna Ranjit and Shaury Srivastav and Julia Gong and Fabian Falck and Ozan Oktay and Anja Thieme and Matthew P. Lungren and Maria T. A. Wetscherek and Javier Alvarez-Valle and Stephanie L. Hyland } ,
  journal = { arXiv } ,
  year = { 2024 } ,
  volume = { abs/2406.04449 } ,
  url = { https://arxiv.org/abs/2406.04449 }
}