🤗 Transformersにおいて制約付きビームサーチを用いたテキスト生成のガイド

'🤗 Transformersの制約付きビームサーチガイド'

イントロダクション

このブログ投稿では、トランスフォーマーを使用した言語生成のための異なるデコーディング方法について説明したブログ投稿「テキスト生成方法: トランスフォーマーを使用した異なるデコーディング方法」で説明されているように、読者がビームサーチの異なるバリアントを使用したテキスト生成方法に精通していることを前提としています。

通常のビームサーチとは異なり、制約付きビームサーチではテキスト生成の出力に対して制御を行うことができます。これは、出力内に正確に何を含めたいかを知っている場合に役立ちます。たとえば、ニューラル機械翻訳のタスクでは、辞書検索を使用して最終的な翻訳に含まれる必要がある単語を知っているかもしれません。言語モデルにとってほぼ同じくらい可能性がある生成出力でも、特定の文脈においてエンドユーザーにとっては同じくらい望ましくない場合があります。これらの状況は、ユーザーがモデルに最終出力に含まれる必要のある単語を指示することで解決できます。

なぜ難しいのか

しかし、これは非常に非自明な問題です。これは、生成されたテキストの最終出力のどこかで、特定の部分文字列の生成を強制する必要があるからです。

• Hugging Face TransformersとAWS Inferentiaを使用して、BERT推論を高速化する
• Hugging FaceでのDecision Transformersの紹介 🤗
• ~自分自身を~ 繰り返さない

例えば、トークン t 1 , t 2 t_1, t_2 t 1 ​ , t 2 ​ を順番に含む文 S を生成したいとします。予測される文 S は次のように定義されます：

S e x p e c t e d = { s 1 , s 2 , . . . , s k , t 1 , t 2 , s k + 1 , . . . , s n } S_{expected} = \{ s_1, s_2, …, s_k, t_1, t_2, s_{k+1}, …, s_n \} S e x p e c t e d ​ = { s 1 ​ , s 2 ​ , . . . , s k ​ , t 1 ​ , t 2 ​ , s k + 1 ​ , . . . , s n ​ }

問題は、ビームサーチがトークンを1つずつ生成することです。ビームサーチを関数 B ( s 0 : i ) = s i + 1 B(\mathbf{s}_{0:i}) = s_{i+1} B ( s 0 : i ​ ) = s i + 1 ​ と考えることができます。この関数は、現在生成されているトークンのシーケンス s 0 : i s_{0:i} s 0 : i ​ （0 0 0 から i i i まで）を見て、次のトークンを i + 1 i+1 i + 1 で予測します。しかし、任意のステップ i < k i < k i < k で、この関数がトークンが将来のステップ k k k で生成される必要があることをどのように知ることができますか？また、ステップ i = k i=k i = k の場合、これがトークンを強制するのに最適な場所であり、将来のステップ i > k i>k i > k ではないことを確実に知ることができますか？

さらに、異なる要件を持つ複数の制約がある場合はどうなりますか？フレーズ p 1 = { t 1 , t 2 } p_1=\{ t_1, t_2 \} p 1 ​ = { t 1 ​ , t 2 ​ } とフレーズ p 2 = { t 3 , t 4 , t 5 , t 6 } p_2=\{ t_3, t_4, t_5, t_6\} p 2 ​ = { t 3 ​ , t 4 ​ , t 5 ​ , t 6 ​ } を強制したい場合はどうなりますか？2つのフレーズの間で選択させたい場合はどうなりますか？フレーズ p 1 p_1 p 1 ​ を強制し、フレーズのリスト { p 21 , p 22 , p 23 } \{p_{21}, p_{22}, p_{23}\} { p 2 1 ​ , p 2 2 ​ , p 2 3 ​ } の中から1つのフレーズを強制したい場合はどうなりますか？

上記の例は実際に非常に合理的なユースケースです。以下で示されるように、新しい制約付きビームサーチ機能では、これらすべてが可能になります！

この投稿では、新しい制約付きビームサーチ機能があなたに何ができるかを簡単に説明し、その仕組みについてより詳細に説明します。

例1：単語を強制する

「How old are you?」をドイツ語に翻訳しようとしているとします。

非公式な場面では「Wie alt bist du?」と言いますが、公式な場面では「Wie alt sind Sie?」と言います。

そして、文脈によっては、一方の形式の方が他方よりも好ましい場合がありますが、モデルにそれを伝えるにはどうすればよいでしょうか？

従来のビームサーチ

以下は、従来のビームサーチ設定でのテキスト翻訳の方法です。

!pip install -q git+https://github.com/huggingface/transformers.git

from transformers import AutoTokenizer, AutoModelForSeq2SeqLM

tokenizer = AutoTokenizer.from_pretrained("t5-base")
model = AutoModelForSeq2SeqLM.from_pretrained("t5-base")

encoder_input_str = "translate English to German: How old are you?"

input_ids = tokenizer(encoder_input_str, return_tensors="pt").input_ids

outputs = model.generate(
    input_ids,
    num_beams=10,
    num_return_sequences=1,
    no_repeat_ngram_size=1,
    remove_invalid_values=True,
)

print("Output:\n" + 100 * '-')
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Output:
----------------------------------------------------------------------------------------------------
Wie alt bist du?

制約付きビームサーチを使用した場合

しかし、非公式なものではなく公式な出力を望むとわかっている場合はどうでしょうか？以前は、いくつかの可能な出力を生成し、要件に合うものをフィルタリングする必要がありました。しかし、今では生成ステージでそれを行うことができます。

model.generate() の force_words_ids キーワード引数を使用すると、次のようなことが可能です：

tokenizer = AutoTokenizer.from_pretrained("t5-base")
model = AutoModelForSeq2SeqLM.from_pretrained("t5-base")

encoder_input_str = "translate English to German: How old are you?"

force_words = ["Sie"]

input_ids = tokenizer(encoder_input_str, return_tensors="pt").input_ids
force_words_ids = tokenizer(force_words, add_special_tokens=False).input_ids

outputs = model.generate(
    input_ids,
    force_words_ids=force_words_ids,
    num_beams=5,
    num_return_sequences=1,
    no_repeat_ngram_size=1,
    remove_invalid_values=True,
)


print("Output:\n" + 100 * '-')
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Output:
----------------------------------------------------------------------------------------------------
Wie alt sind Sie?

ご覧のように、望ましい出力に関する事前知識を使用して生成を誘導することができました。以前は、可能な出力を生成し、その後、要件に合うものをフィルタリングする必要がありました。しかし、今では生成ステージでそれを行うことができます。

例2：選択制約

前述のように、最終的な出力に含まれてほしい単語を事前に知っているユースケースを挙げました。これは、ニューラル機械翻訳中に辞書検索を使用する場合の例です。

しかし、出力に使用する単語形式を知らない場合、例えば ["raining", "rained", "rains", ...] のような出力が同じくらい可能である場合はどうでしょうか？一般的には、文字通りの単語だけでなく、関連する他の可能性も考慮する場合があります。

このような振る舞いを許可する制約は、選択制約 です。ユーザーは、生成の際に最終的な出力に含まれる必要がある単語のリストを入力することができます。

以下は、上記の2つの制約タイプを組み合わせた例です：

from transformers import GPT2LMHeadModel, GPT2Tokenizer

model = GPT2LMHeadModel.from_pretrained("gpt2")
tokenizer = GPT2Tokenizer.from_pretrained("gpt2")

force_word = "scared"
force_flexible = ["scream", "screams", "screaming", "screamed"]

force_words_ids = [
    tokenizer([force_word], add_prefix_space=True, add_special_tokens=False).input_ids,
    tokenizer(force_flexible, add_prefix_space=True, add_special_tokens=False).input_ids,
]

starting_text = ["The soldiers", "The child"]

input_ids = tokenizer(starting_text, return_tensors="pt").input_ids

outputs = model.generate(
    input_ids,
    force_words_ids=force_words_ids,
    num_beams=10,
    num_return_sequences=1,
    no_repeat_ngram_size=1,
    remove_invalid_values=True,
)


print("Output:\n" + 100 * '-')
print(tokenizer.decode(outputs[0], skip_special_tokens=True))
print(tokenizer.decode(outputs[1], skip_special_tokens=True))

Setting `pad_token_id` to `eos_token_id`:50256 for open-end generation.


Output:
----------------------------------------------------------------------------------------------------
The soldiers, who were all scared and screaming at each other as they tried to get out of the
The child was taken to a local hospital where she screamed and scared for her life, police said.

ご覧の通り、最初の出力では"screaming"が使用され、2番目の出力では"screamed"が使用され、両方の出力で"scared"がそのまま使用されています。選択リスト["screaming", "screamed", ...]は単語形式である必要はありません。このリストは、単にリストから1つだけ必要な場合に使用できます。

従来のビームサーチ

以下は、以前のブログ記事から引用した従来のビームサーチの例です。

グリーディサーチとは異なり、ビームサーチはより長い仮説のリストを保持することによって機能します。上記の画像では、各ステップで生成可能な次のトークンを3つ表示しています。

以下の例では、num_beams=3の場合のビームサーチの最初のステップを別の視点から見てみましょう。

貪欲な検索が行うように"The dog"のみを選択するのではなく、ビームサーチでは"The nice"と"The car"の考慮も許容されます。

次のステップでは、前のステップで作成した3つの枝それぞれに対して次の可能なトークンを考慮します。

num_beams以上の出力を考慮することになりますが、ステップの最後にそれらをnum_beamsに減らします。無制限に枝分かれし続けることはできません。枝分かれするたびに追跡する必要のあるbeamsの数は、非常に早く非常に大きくなります（10ステップ後には10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000の10,000,000,000

銀行は、制約を満たすことと合理的な出力を作成することのバランスを作り出すことで、この問題を解決します。

銀行 n n n は、制約を満たすために n n n ステップ進んだビームのリストを指します。すべての可能なビームを各銀行に分類した後、ラウンドロビン選択を行います。上記の例では、Bank 2 から最も確率の高い出力、次に Bank 1 から最も確率の高い出力、Bank 0 から 1 つ、Bank 2 から 2 番目に確率の高い出力、Bank 1 から 2 番目に確率の高い出力、というように選択します。 num_beams=3 を使用しているため、上記のプロセスを 3 回繰り返すことで、["The is fast", "The dog is", "The dog and"] になります。

このように、手動で望ましいトークンを追加した枝を考慮するようにモデルに強制する一方で、より意味のあるシーケンスを追跡することができます。 "The is fast" は制約を完全に満たしていますが、非常に意味のあるフレーズではありません。幸いにも、未来のステップで作業するために "The dog is" と "The dog and" を使用できます。これにより、後の段階でより意味のある出力につながることを期待しています。

この動作は、上記の例の第 3 ステップで示されています:

"The is fast" は手動で制約トークンを追加する必要がないため、既に満たされていることに注意してください（つまり、フレーズ "is fast" を含んでいます）。また、"The dog is slow" や "The dog is mad" のようなビームは、実際には Bank 0 にあります。なぜなら、トークン "is" を含んでいるにもかかわらず、"is fast" を生成するために最初からやり直す必要があるからです。 "is" の後に "slow" のようなものを追加することで、効果的に進捗がリセットされます。

そして最後に、制約フレーズを含む意味のある出力にたどり着いたことに注意してください: "The dog is fast" です。

最初は "The is fast" のような意味のないフレーズが得られる可能性があるため、心配していました。しかし、銀行からのラウンドロビン選択を使用することで、より意味のある出力を優先するために意味のない出力を暗黙的に取り除くことができました。

Constraint クラスとカスタム制約についての詳細

説明から得られる主なポイントは次のように要約することができます。各ステップで、制約を満たすトークンを考慮するようにモデルに要求し続けながら、要求を満たさないビームを追跡し、最終的に望ましいフレーズを含む比較的高い確率のシーケンスに到達します。

したがって、この実装を設計するための原則的な方法は、各制約を Constraint オブジェクトとして表現し、その進捗を追跡し、ビームサーチに次に生成するトークンを伝えることでした。 model.generate() のキーワード引数 force_words_ids を提供していますが、バックエンドで実際に行われることは次のとおりです:

from transformers import AutoTokenizer, AutoModelForSeq2SeqLM, PhrasalConstraint

tokenizer = AutoTokenizer.from_pretrained("t5-base")
model = AutoModelForSeq2SeqLM.from_pretrained("t5-base")

encoder_input_str = "translate English to German: How old are you?"

constraints = [
    PhrasalConstraint(
        tokenizer("Sie", add_special_tokens=False).input_ids
    )
]

input_ids = tokenizer(encoder_input_str, return_tensors="pt").input_ids


outputs = model.generate(
    input_ids,
    constraints=constraints,
    num_beams=10,
    num_return_sequences=1,
    no_repeat_ngram_size=1,
    remove_invalid_values=True,
)


print("Output:\n" + 100 * '-')
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Output:
----------------------------------------------------------------------------------------------------
Wie alt sind Sie?

自分で定義してユニークな制約を設計するために、constraints キーワード引数にそれを入力することができます。 Constraint の抽象インターフェースクラスのサブクラスを作成し、その要件に従ってください。 Constraint の定義に関する詳細な情報は、こちらで見つけることができます。

一部未実装のユニークなアイデア（お試しいただけるかもしれません！）には、OrderedConstraints、TemplateConstraintsなどの制約が追加される可能性があります。現在、生成は出力のどこにでもシーケンスを含めることで実現されています。例えば、以前の例では、scared -> screamingの1つのシーケンスと、screamed -> scaredのもう1つのシーケンスがありました。 OrderedConstraintsでは、これらの制約が実現される順序をユーザーが指定することができます。

TemplateConstraintsでは、よりニッチな使い方が可能で、目的は次のようなものになります:

starting_text = "The woman"
template = ["the", "", "School of", "", "in"]

possible_outputs == [
   "The woman attended the Ross School of Business in Michigan.",
   "The woman was the administrator for the Harvard School of Business in MA."
]

または:

starting_text = "The woman"
template = ["the", "", "", "University", "", "in"]

possible_outputs == [
   "The woman attended the Carnegie Mellon University in Pittsburgh.",
]
impossible_outputs == [
  "The woman attended the Harvard University in MA."
]

もしくは、ユーザーが2つの単語の間に挿入できるトークンの数に関心を持たない場合、OrderedConstraintを使用することができます。

結論

制約付きビームサーチは、テキスト生成に外部の知識や要件を柔軟に注入する手段を提供します。以前は、モデルに対して以下の指示を簡単に伝える方法がありませんでした：1. シーケンスのリストを含めること、2. そのうちのいくつかはオプションであり、いくつかは必須であり、3. それらがシーケンス内の適切な位置に生成されるようにすること。今では、Constraintオブジェクトのさまざまなサブクラスの組み合わせで、生成に完全な制御が可能です！

この新機能は、主に以下の論文に基づいています：

• Guided Open Vocabulary Image Captioning with Constrained Beam Search
• Fast Lexically Constrained Decoding with Dynamic Beam Allocation for Neural Machine Translation
• Improved Lexically Constrained Decoding for Translation and Monolingual Rewriting
• Guided Generation of Cause and Effect

上記のように、多くの新しい研究論文では、外部の知識（例：KG、KB）を使用して大規模な深層学習モデルの出力を誘導する方法を探索しています。この制約付きビームサーチ機能がこの目的を達成するためのもう一つの効果的な手段となることを願っています。

この機能の貢献にガイダンスを提供してくれたすべての方々に感謝します：初期の問題から最終PRまで関与してくれたPatrick von Platen氏、およびコードに対する詳細なフィードバックを提供してくれたNarsil Patry氏。

この投稿のサムネイルは、以下の属性を持つアイコンを使用しています：Shorthand icons created by Freepik – Flaticon

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!