専門家一覧
医療・法務AI特化型トークナイザー：専門用語の欠落を防ぐ語彙拡張戦略

医療・法務LLMの精度を劇的に改善するトークナイザー拡張術：語彙追加と継続事前学習の完全実装ガイド

この記事は急速に進化する技術について解説しています。最新情報は公式ドキュメントをご確認ください。

約15分で読めます
文字サイズ:
医療・法務LLMの精度を劇的に改善するトークナイザー拡張術：語彙追加と継続事前学習の完全実装ガイド
目次

この記事の要点

  • LLMの医療・法務ドメインにおける専門用語処理能力を向上
  • トークナイザーの語彙にドメイン固有の専門用語を追加
  • 追加語彙をモデルに定着させる継続事前学習の実施

医療や法務といった専門性の高いドメインでLLM（大規模言語モデル）を導入しようとする際、開発現場が共通の課題に直面することは珍しくありません。

「RAG（検索拡張生成）を組んだのに、回答が微妙にずれる」
「プロンプトエンジニアリングを工夫しても、専門用語の扱いが安定しない」
「コンテキストウィンドウの消費が激しく、長い判例や症例データを効率的に処理できない」

もしこのような課題に直面しているなら、問題はプロンプトの記述や検索データベースの精度にあるとは限りません。根本的な原因は、モデルの「入り口」であるトークナイザーに潜んでいる可能性があります。

OpenAIのGPT-5.2やMetaのLlama 3.3、Llama 4といった最新のモデルは、一般的な言語処理において飛躍的な進化を遂げています。しかし、ドメイン特有の専門用語に対しては、依然として対応が難しいケースが存在します。専門用語を意味のない文字の羅列として細切れに処理してしまう現象です。

このボトルネックを解消するための「トークナイザー拡張（Vocabulary Expansion）」と「継続事前学習（Continued Pre-training）」の技術的アプローチについて、コードレベルの実装詳細まで踏み込んで解説します。これは単なる表面的なチューニングではなく、モデルの構造そのものを最適化する強力な手法です。

深層学習のアーキテクチャの根幹に関わる、この重要なアプローチを具体的に紐解いていきましょう。準備はいいですか？

1. なぜ汎用トークナイザーは専門領域で対応できないのか

汎用モデルのトークナイザーが、専門ドメインでパフォーマンスを十分に発揮できない根本的な理由を整理します。

「過失相殺」が3トークンに？サブワード分割の影響

現代のLLMの多くは、BPE（Byte-Pair Encoding）やUnigramといったサブワード分割アルゴリズムを採用しています。これは未知語（OOV: Out-Of-Vocabulary）をなくすために有効な手法ですが、学習データに頻出しない単語に対しては、文字単位に近いレベルまで分解してしまうことがあります。

例えば、法務ドメインで頻出する「善管注意義務（ぜんかんちゅういぎむ）」という言葉を考えてみましょう。

英語圏のデータセットを中心に構築された汎用トークナイザーに通すと、以下のように不自然に分割されることがあります。旧世代のモデルで顕著だったこの問題は、最新モデルの多言語対応が進んでも、ニッチな専門用語においては依然として発生し得ます。

# 汎用トークナイザーでの分割イメージ
Tokens: ["善", "管", "注", "意", "義", "務"]
# あるいは
Tokens: ["善", "管", "注意", "義務"]

人間が見れば一つの確固たる概念ですが、モデルにとっては「善い」「管（くだ）」「注意」「義務」という、バラバラの要素の集合体として入力されます。モデルはこれら複数のトークンから、文脈の力を使って「善管注意義務」という一つの法的概念を再構築しなければなりません。これは推論エンジンに対して余計な負荷をかけるだけでなく、アテンション（Attention）機構がより重要な文脈の理解にリソースを割くことを阻害します。

トークン効率の悪化が招くコスト増とコンテキスト圧迫

この「細切れ化」は、システム運用における経済的なデメリットにも直結します。経営者視点で見れば、これは見過ごせないランニングコストの増大要因です。

医療分野の電子カルテを分析する場合、一般的な日本語トークナイザーと、医療用語を追加学習させたカスタムトークナイザーでは、同じテキストを表現するために必要なトークン数に顕著な差が出ます。

  • 汎用トークナイザー: 1,000トークン消費
  • 拡張トークナイザー: 430トークンで表現可能

これは、API課金モデルにおいて直接的なランニングコストの増加を招く要因です。現在、Llama 3.3が128kコンテキスト、Llama 4が最大1,000万トークンの超長文脈に対応し、GPT-5.2も長い文脈の理解能力を大幅に向上させています。かつてのGPT-4oやLlama 2の時代と比較すると、一度に入力できる情報量は劇的に増加しました。

しかし、コンテキストウィンドウが拡大したとはいえ、無駄なトークン消費は計算リソースの浪費を意味します。数年分の診療履歴や膨大な判例データを効率よく処理し、実用的な応答速度を維持するためには、依然としてトークン効率の最適化が不可欠です。

未知語扱いによる推論精度の低下メカニズム

さらに深刻なのは、意味情報の損失による推論精度の低下です。

単語が細切れにされると、その単語が本来持っている「意味ベクトル（Embedding）」をモデルが直接利用できなくなります。モデルは「心」と「筋」と「梗」と「塞」それぞれのベクトルを合成して、文脈の中で意味を推測する必要があります。

一方、「心筋梗塞」が1つの独立したトークンとして語彙に登録されていれば、そのトークン自体に「虚血性心疾患の一種で、重篤な状態」という正確な意味ベクトルを直接学習させることができます。

専門用語を1つのトークンとして扱うことは、モデルに対して「これは不可分な重要な概念の塊だ」と明示することに他なりません。GPT-5.2の高度な推論機能（Thinking）や、Llama 4のMoE（Mixture of Experts）アーキテクチャによる効率的な処理能力は圧倒的ですが、ドメイン特有の語彙を正確に捉える基盤をトークナイザーレベルで整えることで、その卓越した能力を専門領域で最大限に引き出すことが可能になります。特に日本語の専門用語においては、このアプローチが実用化の壁を突破する鍵となります。

2. 統合戦略とアーキテクチャ設計

なぜ汎用トークナイザーは専門領域で失敗するのか - Section Image

では、どうすればよいのでしょうか？ モデルをゼロから作り直す（フルスクラッチ学習）のは、計算資源の観点から現実的ではありません。ここで採るべき戦略は、「既存の技術を参考にしつつ、新しい言語を教える」アプローチ、すなわち既存モデルへの語彙拡張（Vocabulary Expansion）です。プロトタイプ思考で、まずは既存の資産を活かして最速で検証可能な形を作ります。

語彙拡張（Vocabulary Expansion）の全体フロー

推奨するアーキテクチャ設計は以下の通りです。

  1. Base Model選定: 日本語能力がある程度高いオープンモデル（Llama, Mistral, Qwenなど）を基盤にします。
  2. Domain Corpus準備: 専門用語を抽出するためのテキストデータを集めます。
  3. Tokenizer Training: ドメインデータを用いて、新しいサブワードモデル（SentencePiece等）を学習させます。
  4. Vocabulary Merging: ベースモデルのトークナイザーに、新しく学習した専門用語を追加（マージ）します。
  5. Model Resizing & Initialization: モデルのEmbedding層を拡張し、新規トークンの重みを初期化します。
  6. Continued Pre-training: 拡張された語彙とモデルを使って、ドメインデータで追加の事前学習を行います。

既存モデルへの影響を最小限に抑える「追加学習」戦略

ここで重要なのは、既存の知識を維持することです。ベースモデルはすでに一般的な日本語や論理的思考能力を持っています。トークナイザーを変更しすぎると、この能力が低下するリスクがあります。

そのため、既存の語彙（Original Vocabulary）はそのまま維持し、そこに含まれていない専門用語だけを「追加（Append）」する形をとります。

使用するライブラリと技術スタック

このプロセスを実行するために、以下のスタックを使用します。

  • Hugging Face Transformers: モデル操作のデファクトスタンダード。
  • SentencePiece: Google製のトークナイザーツール。BPEやUnigramの学習に最適。
  • PyTorch: テンソル操作と学習フレームワーク。
  • LoRA (Low-Rank Adaptation): 計算コストを抑えて効率的に学習するために使用（オプションですが推奨）。

3. 前提条件とデータセット準備

「Garbage In, Garbage Out（質の悪いデータを入れれば、質の悪い結果が出る）」はAI開発における不変の原則です。トークナイザーの性能、ひいてはLLMの最終的な出力品質は、準備する学習データの質に大きく左右されます。

ドメインコーパスの収集とクリーニング

医療や法務といった専門性の高い領域では、一般的なWebテキストだけでは不十分です。信頼性の高い公開データセットと、組織内部のデータを適切に組み合わせる戦略が求められます。

  • 医療ドメイン:
    • PubMed: 英語中心ですが、医学用語の網羅性が高く必須のソースです。
    • J-STAGE等のオープンアクセス論文: 日本語の医学論文を収集します。
    • 医療ガイドライン: 学会が公開しているPDFからテキストを抽出します。
    • 退院サマリー: 倫理審査を経て利用可能な匿名化データがある場合、極めて有用です。
  • 法務ドメイン:
    • 判例検索システム: 公開されている判例データを利用します。
    • e-Gov法令検索: 正確な条文データの取得源として活用します。
    • 有価証券報告書: ビジネス法務用語や独特な言い回しが豊富に含まれています。

クリーニングのポイント:
単にテキストを集めるだけでは不十分です。特にPDFから抽出したテキストには、ヘッダー、フッター、ページ番号といったノイズが混入しがちです。これらはモデルの学習を阻害するため、正規表現などを用いて徹底的に除去し、クリーンなテキストファイル（.txt）に整形する必要があります。正規化処理を行い、表記ゆれを統一することも重要です。

既存トークナイザーの分析と語彙重複の確認

新しいトークンを追加する前に、ベースとなるモデルが既存の状態でどの程度専門用語を理解しているか（語彙に含まれているか）を分析する必要があります。Llamaなどの一般的なLLMは、日本語の専門用語を細切れのトークンとして処理する傾向があります。

以下は、Hugging Face Transformersライブラリを使用して、ベースモデルのトークナイズ状況を確認するPythonコードの例です。

from transformers import AutoTokenizer

# 使用するベースモデルのIDを指定（例: Llamaモデル系モデルなど）
# 最新情報は公式ドキュメントやHugging Face Hubを確認してください
model_id = "meta-llama/Meta-Llama-3.1-8B" 

tokenizer = AutoTokenizer.from_pretrained(model_id)

# 確認したい専門用語のリスト
terms_to_check = ["心筋梗塞", "善管注意義務", "インフォームド・コンセント"]

for term in terms_to_check:
    tokens = tokenizer.tokenize(term)
    # トークン分割の様子と長さを出力
    print(f"{term} -> {tokens} (Length: {len(tokens)})")

このスクリプトを実行し、重要な専門用語がどのように分割されるかを確認してください。例えば「心筋梗塞」が ['心', '筋', '梗', '塞'] のように意味を持たない単位まで細分化されている場合、モデルはその単語の意味を捉えるのに多くの計算リソースを消費することになります。このような語彙に対し、トークナイザーを拡張することで、推論速度と精度の向上が期待できます。

4. 実装ステップ1：トークナイザーの拡張と結合

ここからがエンジニアリングの重要な部分です。実際にコードを書いていきましょう。まずは手を動かして、動くものを作ることが先決です。

新規語彙の学習と抽出（SentencePieceの学習）

まず、用意したドメインコーパスを使って、SentencePieceモデルを学習させます。ここでは、新たに追加したい語彙数（例えば5,000語）を指定します。

import sentencepiece as spm

# ドメインコーパスのテキストファイル
corpus_file = "medical_corpus.txt"
# 新規モデルのプレフィックス
model_prefix = "medical_spm"
# 追加したい語彙サイズ
vocab_size = 5000

spm.SentencePieceTrainer.train(
    input=corpus_file,
    model_prefix=model_prefix,
    vocab_size=vocab_size,
    model_type="bpe",  # または 'unigram'
    character_coverage=0.9995,
    num_threads=16
)

これにより、medical_spm.model と medical_spm.vocab が生成されます。

既存トークナイザーへの新規トークン追加（add_tokens）

次に、学習したSentencePieceモデルから語彙をロードし、既存のHugging Faceトークナイザーに追加します。ただし、既存の語彙と重複するものは除外する必要があります。

from transformers import AutoTokenizer
import sentencepiece as spm_proto

# ベースモデルのトークナイザー
base_tokenizer = AutoTokenizer.from_pretrained("meta-llama/Meta-Llama-3-8B")

# 新しく学習したSPMモデルをロード
sp_new = spm_proto.SentencePieceProcessor()
sp_new.load("medical_spm.model")

# 追加候補のトークンを抽出
new_tokens = []
for i in range(sp_new.get_piece_size()):
    token = sp_new.id_to_piece(i)
    # 既存トークナイザーに含まれていないかチェック
    if token not in base_tokenizer.get_vocab():
        new_tokens.append(token)

print(f"Adding {len(new_tokens)} new tokens...")

# トークナイザーに追加
base_tokenizer.add_tokens(new_tokens)

# 保存
base_tokenizer.save_pretrained("./extended_tokenizer")

これで、トークナイザーは「医療用語」を知っている状態になりました。しかし、モデル本体（ニューラルネットワーク）はまだ、これらの新しいトークンに対応する「脳細胞（重み）」を持っていません。

5. 実装ステップ2：モデルの埋め込み層（Embedding）調整

ここは重要なパートです。トークナイザーを拡張したら、モデルの入力層（Embedding）と出力層（lm_head）のサイズを合わせる必要があります。

resize_token_embeddingsによる拡張

from transformers import AutoModelForCausalLM

model = AutoModelForCausalLM.from_pretrained("meta-llama/Meta-Llama-3-8B")

# トークナイザーの長さに合わせてモデルをリサイズ
model.resize_token_embeddings(len(base_tokenizer))

これでエラーなく動くようにはなります。しかし、新しく追加されたトークンのベクトル（重み）は、デフォルトではランダムな値で初期化されています。これは「心筋梗塞」という単語に対して、意味を与えていない状態です。このまま学習を始めると、モデルはゼロから意味を学習しなければならず、収束に時間がかかるだけでなく、既存の知識を損なう原因にもなります。

「Smart Initialization」：類似語からの重み継承テクニック

そこで推奨するのが、Smart Initializationです。これは、新しいトークン（例：「心筋梗塞」）の初期値を、それを構成していた元のサブワード（「心」「筋」「梗」「塞」）のベクトルの平均値で設定する手法です。

これにより、学習前からある程度「それっぽい意味」を持たせることができ、学習効率が飛躍的に向上します。

import torch
import torch.nn as nn

def smart_tokenizer_and_embedding_resize(
    special_tokens_dict,
    tokenizer,
    model,
    noise_std=0.001  # ノイズを少し加えてロバスト性を高める
):
    # 1. 既存の埋め込み層を取得
    input_embeddings = model.get_input_embeddings()
    output_embeddings = model.get_output_embeddings()
    
    # 既存の語彙サイズ
    old_vocab_size = input_embeddings.weight.size(0)
    
    # トークナイザーに特殊トークン等を追加（必要であれば）
    num_new_tokens = tokenizer.add_special_tokens(special_tokens_dict)
    
    # 2. モデルのリサイズ
    model.resize_token_embeddings(len(tokenizer))
    
    # 新しい埋め込み層への参照
    new_input_embeddings = model.get_input_embeddings()
    new_output_embeddings = model.get_output_embeddings()
    
    # 3. Smart Initializationの実装
    # 新しく追加されたトークンについてループ
    # 注意: ここでは簡略化のため、全新規トークンに対して処理するロジックの概念を示します
    
    # 新規追加されたトークンのIDリストを取得（例として実装）
    new_token_ids = list(range(old_vocab_size, len(tokenizer)))
    
    with torch.no_grad():
        for token_id in new_token_ids:
            token_str = tokenizer.decode([token_id])
            
            # 元のトークナイザー（リサイズ前）で分割した場合のIDを取得したいが、
            # ここでは簡易的に「新しいトークン文字列を構成する既存サブワード」を推測して平均化する
            # 実践的には、拡張前のトークナイザーインスタンスを保持しておく必要があります
            
            # 例: token_str = "心筋梗塞"
            # old_tokens = old_tokenizer.tokenize(token_str) -> ['心', '筋', '梗', '塞']
            # old_ids = old_tokenizer.convert_tokens_to_ids(old_tokens)
            
            # ここでは仮のold_idsとして、ランダムではなく意味のある平均値を計算するロジックを想定
            # input_embeddings.weight[old_ids].mean(dim=0) を計算し、
            # new_input_embeddings.weight[token_id] に代入する
            pass 

    print("Smart initialization complete.")

# ※ 実際の実装では、古いトークナイザーインスタンスを使って各新規単語を分解し、
# その平均ベクトルを計算して新しい重みに代入する処理を書きます。

このプロセスを経ることで、モデルは「心筋梗塞」という新しい単語を見た瞬間、少なくとも「心臓に関連する何か」であるという事前知識を持った状態でスタートできます。

6. 実装ステップ3：継続事前学習（Continued Pre-training）

実装ステップ2：モデルの埋め込み層（Embedding）調整 - Section Image

トークナイザーとモデルの準備ができたら、いよいよ学習です。これはファインチューニング（SFT）ではなく、継続事前学習（Continued Pre-training）と呼ばれるフェーズです。教師ありデータ（Q&A）ではなく、大量のドメインテキストを「次に来る単語を予測する（Causal Language Modeling）」タスクで学習させます。

拡張語彙を定着させるための学習設定

学習にはいくつかの戦略がありますが、リソース効率と精度のバランスが良いのは LoRA (Low-Rank Adaptation) を用いた手法です。ただし、Embedding層とLM Head層は学習可能（trainable）にしておく必要があります。LoRAは主にAttention層などに適用しますが、今回拡張したEmbedding層はフルで更新しないと意味がありません。

from peft import LoraConfig, get_peft_model, TaskType

# LoRAの設定
peft_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    inference_mode=False,
    r=8,
    lora_alpha=32,
    lora_dropout=0.1,
    # ターゲットモジュールを指定
    target_modules=["q_proj", "v_proj"],
    # 重要: Embedding層とLM Headも学習対象に含める設定（modules_to_save）
    modules_to_save=["embed_tokens", "lm_head"]
)

model = get_peft_model(model, peft_config)
model.print_trainable_parameters()

破滅的忘却（Catastrophic Forgetting）を防ぐ工夫

ドメイン知識を詰め込みすぎると、元の日本語能力や論理性が損なわれることがあります。これを防ぐために、学習データにはドメインデータだけでなく、一般的なWebテキスト（WikipediaやCC-100など）を混ぜることを推奨します。これを「リプレイバッファ」と呼びます。

7. 効果検証とトラブルシューティング

実装が終わったら、定量的な評価を行います。仮説を検証し、次のアクションにつなげる重要なステップです。

圧縮率（Fertility Score）の改善測定

最も分かりやすい指標は「圧縮率」です。同じドメインテキストをトークナイズした際のトークン数を比較します。

  • Fertility Score = (単語数) / (トークン数)

あるいは単純に、テストセット全体のトークン数がどれだけ減ったかを確認します。医療ドメインであれば、トークン数が削減されていれば成功です。

ダウンストリームタスクでの精度比較

最終的には、実際のタスク（固有表現抽出、要約、Q&A）での精度を見ます。特に、専門用語が含まれる回答において、正確な用語が生成されるようになっているかを確認してください。

よくあるエラー：Lossが収束しない場合の対処法

もし学習時のLossが下がらない、あるいは増加する場合は、以下の点をチェックしてください。

  1. 学習率が高すぎる: Embedding層を学習する場合、通常よりも低い学習率が推奨されます。例: 1e-5 〜 5e-5
  2. 初期化の失敗: Smart Initializationが正しく機能していない可能性があります。ランダム初期化に戻して比較実験を行ってみてください。
  3. データの品質: クリーニング不足で、意味不明な文字列が大量に語彙に含まれていませんか？

まとめ

トークナイザーに追加 - Section Image 3

トークナイザーの拡張は、プロンプトエンジニアリングに比べると目立たない作業です。しかし、医療や法務といった「言葉の正確性」が重要な領域において、極めて効果的な施策です。

  • コスト削減: トークン消費量が減り、運用コストが下がる。
  • 精度向上: 専門用語の意味理解が深まり、回答品質が上がる。
  • コンテキスト拡大: より多くの情報を一度に処理できるようになる。

もし、開発現場が「専門用語の壁」に直面しているなら、モデルの外側（RAGやプロンプト）だけでなく、内側（トークナイザー）に目を向けてみてください。技術の本質を見抜くことが、ビジネス課題解決への最短距離となります。

実装にはノウハウが必要ですが、確かな効果が期待できます。

AIプロジェクトが、言葉の壁を越えて真の価値を発揮することを願っています。

医療・法務LLMの精度を劇的に改善するトークナイザー拡張術：語彙追加と継続事前学習の完全実装ガイド - Conclusion Image

コメント

コメントは1週間で消えます
0 / 150
コメントを読み込み中...