Deep Learning

ReALM 論文閱讀

用少量參數解決 reference resolution 問題

paper: ReALM: Reference Resolution As Language Modeling

Abstract

Reference resolution 是一個重要的問題，對於理解和充分處理不同類型的 context 很重要。

Context 包含 previous turns 和 non-conversational entities，比如使用者螢幕上的 entity，或是在背景執行的 entity。

LLM 雖然在各種任務都很強大，但對於 reference resolution 的使用，特別是 non-conversational entities 方面，依然沒有充分利用。

本文將展示如何引用 LLM 創建一個系統來處理不同類型的 reference，方法是展示如何把 reference resolution 轉換成 language modeling problem。 盡管螢幕上的 entity 傳統上不利於簡化成 text-only modality。

對於 GPT-4，本文最小的模型實現了和 GPT-4 相當的性能，而更大的模型則大幅領先。

Introduction

人類的語言很長包含 ambiguous reference，比如「這個」、「那個」等等，這些 reference 需要根據 context 來解決。

能夠能夠理解 context 對 conversational assistant 來說很重要。

讓使用者能夠對螢幕上看到的內容發出查詢是確保語音助理可以提供 hands-free 體驗的第一步。

Speaker Dialogue
User Show me pharmacies near me
Agent Here is a list I found.
Agent … (list presented)
User Call the one on Rainbow Rd.
User Call the bottom one.
User Call this number (present onscreen)

Table 1: Sample Interactions between a user and an agent.

以 Table 1 為例，如果沒有理解 context 的能力，agent 不可能完成查詢。

照理來說，處理用戶的查詢需要多種類型的 context，Conversational context 和 on-screen context 就是兩個主要的例子。

最近的 LLM 通常可以實現 End-to-End 的體驗，甚至可能可以消除包含 reference resolution 的多階段 piepline。

但是在一些實際案例中，pipeline 有他的價值，考慮以下情境：

  1. 在運算能力有限的設備上運作 (例如手機)

    • 由於功耗和延遲需求，單一大型 End-to-End 模型可能不適用。

  2. 需要與 API 整合的情境

    • 雖然存在可以用 LLM 編寫呼叫 API 的方法，但依然需要超大的模型還有對現有 pipeline 的徹底處理。

  3. 使用 focused model 可以允許現有的 reference resolution module 替換成更新的版本，而且由於系統是模組化的，可以改進能力和可解釋性。

  4. 對於本文所考慮的任務，reference resolution 不只限定於 conversational context，還包含 on-screen entities，這些 entities 是使用者可以感知到的一部份，但是還未出現在對話歷史紀錄中。

因此，盡管一些 LLM 可以 implicit 地處理 reference resolution，但是傳統的 NLP 任務 (比如 reference resolution) 仍然有價值。

因此本文提倡用較小的語言模型，但針對 reference resolution 進行了專門且明確的 fine-tuning。

然而這種語音助理會遇到最大的挑戰就是要怎麼讓 LM 「看」到螢幕。而且還要以有利於 LM 解析的方式對螢幕上的 entity 進行編碼，然後編碼還得足夠一致，讓 LM 可以成功執行 reference resolution。

本文建議使用使用 parsed entity 及其位置來重件螢幕，以產生螢幕的純文字表示。

然後螢幕上屬於 entity 的部分會被標記，以便 LM 能夠了解實體出現的位置及他們周圍的文字。

據作者所知，這是第一個目標是從螢幕 encode context 的 LLM 工作。

解析螢幕上的 reference 是一個目前探索比較不足的領域。

螢幕上的東西通常更加結構化和高度文字化，使的可以利用更輕的模型來轉換成文字。但雖然容易解析，分布和那種大型育訓練的基於圖像的系統不同，因為他們多半都用自然的現實圖片。

此外那些模型的訓練成本通常都非常高，而且在這種大量文字的情境也表現不佳。 常用於文字理解的方法又常常依賴多個模組，比如 bounding box detection 和 OCR。

聯合視覺 + 文字的模型在計算成本也更加昂貴。

對於螢幕上的參考有一些相關工作，被用作本文的 baseline。

然後他們有些缺點，在本文解決了這些缺點。

  1. 他們的方法依賴專用的 「Category Module」來處理 type-based reference，每次建立新類型，都需要手動加入 Entity
  2. 此類 Module 將每種類別視為不同的，忽略了他們的相似性
  3. 依賴手工製作的規則，往往需要大量特徵工程，而且不 robust
  4. 不考慮語意相似性，也沒法對現實的理解和常識進行推理
  5. 這些方法會獨立地判斷實體和 Query 的關聯性，而不考慮其他所有的實體，查詢既不考慮整個螢幕也不考慮其他實體

Task

作者提了三種和使用者相關的 Entity:

  1. On-screen Entities
  2. Conversational Entities
    • 可能是來自上一輪的對話，也可能是 virtual assistant 產生的
  3. Background Entities
    • 來自後台 process 的相關實體，使用者不一定在螢幕上看的到，比如背景的音樂

本文將 reference resolution 作為 LLM 的 multiple choice task，預期輸出是用戶螢幕上顯示的其中一個 Entity。

答案也可能是「None of these」。

Datasets

每筆資料包含使用者查詢和 Entity list，還有與對應使用者查詢相關的 ground truth entity。

每個實體又包含與其相關的訊息，比如與實體關聯的名稱和其他文字描述訊息。

對於存在 on-screen context 的資料，context 以 Entity 的邊界框，圍繞它的物件清單還有周圍物件的屬性 (比如類型、文字內容、位置) 來提供

Dataset Train Set Test Set
Conversational 2.3k 1.2k
Synthetic 3.9k 1.1k
On-screen 10.1k 1.9k

Table 2: Dataset Sizes (Train Set and Test Set)

Conversational Data

收集使用者和 agent 的相關資料。

評分者會看到帶有所提供 Entity 清單的截圖，並要求提供引用清單中任意挑選的 Entity 的 Query。

比如，可能會給使用者看企業清單，使用者可能會說「Call the one on Main Street」。

Synthetic Data

透過 template 去合成資料。

有兩種 template:

  1. Base Template
    • 包含 mentions, entities, possible slots
  2. Language Template
    • 除了 Base 還會新增不同變體的 query

On-screen Data

從存在電話、電子郵件和實際地址的各種網頁蒐集的。

進行兩階段的 annotation：

  1. 根據螢幕 extract query
    • 評分者會收到一張帶有綠色方框和紅色方框的截圖，要把綠方框方類為電話、電子郵件或地址等等
    • 然後要為綠框提供三個獨特的 query
  2. 根據 query 識別 entity 和 mention
    • 前面蒐集的 query 會被一一展示給評分者，並帶有相應的截圖，但沒有 bounding box，還會提供所有 screen entity list
    • 評分者要評估 query 是否包含給定的 visual entity，還有聽起來自不自然
    • 此外，評分者還要從清單中選出 query 提及的 entity，還要標記它們在 query 的哪裡

Models

MARRS

這個是 baseline，非 LLM，和前人的方法去做比較。

前人的方法著重於螢幕上的 entity，MARRS 也傾向於 conversational 和 background entities。

要注意的是，和其他通用的 LLM 相比，作者的 baseline 是專門為了 reference resolution 而設計的。

ChatGPT

作者考慮 GPT-3.5 和 GPT-4 作為另外一個 baseline。

對於 GPT-3.5，輸入只包含 prompt。

對於 GPT-4，因為他可以接受圖片的 context，所以為系統提供了螢幕截圖，發現可以有效提高其效能。

Our Approach

作者遵循以下 pipeline 來微調模型 (FLAN-T5)

向模型提供解析後的輸入，並用來微調。

和 Baseline 不同，作者沒有在 FLAN-T5 上進行大規模的超參數搜索，而是堅持使用預設的參數。

Conversational References

作者假設 conversational references 有兩種：

  1. Type-based
    • 這種非常依賴要將 query 和 entity type 結合，好進行識別
    • 比如「打給他」，可以知道要的是電話號碼，而不是地址
  2. Descriptive
    • 傾向於用唯一的實體屬性來標記他，比如「時代廣場的那個」

referenece 通常會同時依賴 type 和描述，比如「play the one from Abbey Road」和「directions to the one on Abbey Road」。

Onscreen References

作者假設存在能夠解析螢幕文字以提取 Entity 的上游資料偵測器。

為了以僅涉及文字的方式將其編碼到 LM 中，使用 Algorithm 2。

直觀上，假設所有實體和周圍物件的位置都可以用它們各自的邊界框的中心來表示。

然後從上到下對這些中心進行排序，並用 stable sort 從左到右排序。

然後，所有在一個 margin 內的物件都會被視作在 same line，並用 tab 隔開。

在 margin 下方外面的會被放在下一行，然後不斷重複。

Results

Model Conv Synth Screen Unseen
MARRS 92.1 99.4 83.5 84.5
GPT-3.5 84.1 34.2 74.1 67.5
GPT-4 97.0 58.7 90.1 98.4
ReALM-80M 96.7 99.5 88.9 99.3
ReALM-250M 97.8 99.8 90.6 97.2
ReALM-1B 97.9 99.7 91.4 94.8
ReALM-3B 97.9 99.8 93.0 97.8

Table 3:

預測正確的標準是要正確預測所有相關實體，不然就是錯的

作者發現它們的方法贏 MARRS 和 GPT-3.5。 GPT-3.5 的餐數量還多出了幾個數量級。

盡管模型相較 GPT-4 輕的多，但是性能大致相同。

而且作者採用文字編碼的方法能夠讓模型和 GPT-4 幾乎同等效能，後者還提供了螢幕截圖。

隨著模型加大，提升也很明顯，特別是 Screen，暗示任務本質上更加複雜。

Analysis

  • $GPT-4 \approx ReALM » MARRS$ for new use-cases
    • 測試了 zero-shot learning 的能力，Table 3 最後一個 column 就是在比較從未見過的資料集。
    • 作者發現對於測試集，所有 LLM-based 的方法都贏過 Fine-tuned Model
  • ReaLM > GPT-4 for domain-specific queries
    • 作者發現 ReALM 因為有對 user requests 做 fine-tuning，所以更能理解 domain-specific questions，如下表 (Table 4)
1
2
3
4
5
6
7

User Request: Can you make it brighter?
---
Entities Shown to User:
1. Type: Settings
2. Type: UserEntity | homeAutomationAccessoryName
---
GPT-4 Prediction: 1 Ground Truth: 1, 2

Table 4