[ChatStream] Transformer応答をモックする Transformer Mock

[ChatStream] Transformer応答をモックする Transformer Mock

こんにちは! (株)Qualiteg プロダクト開発部 です!

本稿では、モックデータの作成方法について説明します! これは正式には「Transformer Mock」と呼ばれている機能のためのもので、実際のLLM出力をレコーディングして再現するためのものです。

なぜこんなことが必要かというと、 LLM アプリのテスト(単体テストなど)で使用します。LLMアプリのテストをするとき、古典的な単体テストでは、入力に対して期待する出力は固定されていることが前提です。

ところがLLMはその特性上、同一の入力に対しても毎回異なる応答を返してきます。そこが生成AIの良いところですが古典的な単体テストをするときには悩んでしまいます。

ここで賢い読者の皆様は、同一の入力に対して、同一の出力を得たいなら、シードを固定すればいいじゃん。とお考えの方もいらっしゃるとおもいますが、シード値を固定して、入力を固定して、各種サンプリングパラメータを固定しても GPUの種類が異なると異なる出力を出してしまう、ということがわかっています。

これでは、GPUを変更したとたんに単体テストが通らなくなって困ってしまうため、それならば、あるGPUに対して入力した値と出力された値をレコーディングしておき、単体テストのときにはそのレコーディングした結果を「再現」することで疑似的にGPUの計算入力と計算結果を模すことができる、というのが本機能の発想となっております。

これにより、単体テストにおいても ChatStream 内コードの多くの部分を通る(1回のテストでのカバレッジがあがる)ため単体テストの信頼性を向上させることができます。

また、大型のモデルの読み込みには何十分もかかることもあり、nightly ビルドでCIしたとしても、本質的じゃない(そこはカバーしなくてよい)部分のために多くの時間をとられてしまうという課題もあり、そういった課題についても本機能によるエミュレーションで大幅に時間短縮することができます。

モックデータの作成方法

モデルを読み込まなくても、モデルと同じ応答を行わせることができる Mock モード(モックモード)について説明します。

Transformer Mockモードとは

事前に Model,Tokenizer への入力と出力のペアを記録し、それを再生することで
実際には Model,Tokenizer が無くても あたかも Model,Tokenizer があるかのように振る舞わせることができます。

このように Model,Tokenizer をエミュレーションするのが Mockモードです

Transformer Mockモードのメリット

  • モデルデータの読み込み時間が無い。
  • 再現性のある出力(AIアシスタントの応答)を得ることができる

ことで、モデルそのもの以外の評価やテストを手軽に用意に行うことができます

Generator Mockとの違い

類似の機能に Generator Mock があります。

Transfromer Mock モードは 実際のModel,Tokenizerの挙動を記録して再現するのにたいして Generator Mock は
入力を受け取った後、ダミーの文章で応答します。 Transformer Mock モードは決められた入力しか受け付けられませんが、Generator Mockはどのような入力でもダミーの文章で応答します。

Generator MockはAPIの挙動確認などで活用できますが、テストコード実行時のカバレッジは Transformer Mockモードに比べるとだいぶ低くなりますので、カバレッジを重視される場合は、Transformer Mockモードの使用がオススメです。

記録と再現

Transformer Mock モードのための記録 ~ Probeモード ~

厳密には Mock,Tokenizer の挙動を再現することを Transformer Mock モードと呼びます。
Mock,Tokenizer の挙動を記録するモードのことを Probe モードと呼びます。

以下のように probe_mode_enabled=True とすることで、 Probeモードが有効になります


chat_stream = ChatStream(
    num_of_concurrent_executions=2,
    max_queue_size=5,
    model=model,
    tokenizer=tokenizer,
    num_gpus=num_gpus,
    device=device,
    chat_prompt_clazz=ChatPrompt,
    add_special_tokens=False,
    max_new_tokens=128,
    context_len=1024,
    temperature=0.7,
    top_k=10,
    client_roles=client_role_free_access,
    locale='ja',
    token_sampler=TokenSamplerIsok(),
    seed=42,
    probe_mode_enabled=True,
)

probe_mode_enabled=True な状態で ChatStreamサーバーを起動し、UIからテキストの入力を行い
応答を生成します。このように普通にチャットを行うだけでその入力、応答が自動的に記録されます。

記録されたデータは以下ディレクトリに保存されます

 [home_dir]/.cache/chatstream/probe_data 

Transformer Mock モードで Model,Tokenizer をエミュレーション

MockTransformer をつかうと、記録されたデータをつかって Model,Tokenizer をエミュレーションすることができます

MockTransformer(parent_dir_path=[親ディレクトリ], dirname=[記録されたデータの保存されたディレクトリ名],
                wait_sec=[1トークン生成するたびに設定するウェイト(秒)])

[親ディレクトリ]を省略した場合は

 [home_dir]/.cache/chatstream/probe_data 

がディレクトリとして適用されます。

サンプルコード


mock_transformer = MockTransformer(parent_dir_path=mock_data_dir, dirname=mock_data_name, wait_sec=0)

model = mock_transformer.get_model() # model
tokenizer = mock_transformer.get_tokenizer() # tokenizer
token_sampler = mock_transformer.get_token_sampler() # サンプリングクラス

if device.type == 'cuda' and num_gpus == 1:
    model.to(device)

chat_stream = ChatStream(
    num_of_concurrent_executions=2,
    max_queue_size=5,
    model=model,
    tokenizer=tokenizer,
    num_gpus=num_gpus,
    device=device,
    chat_prompt_clazz=ChatPrompt,
    add_special_tokens=False,
    max_new_tokens=128,  # The maximum size of the newly generated tokens
    context_len=1024,  # The size of the context (in terms of the number of tokens)
    temperature=0.7,  # The temperature value for randomness in prediction
    top_k=10,  # Value of top K for sampling
    top_p=0.9,  # Value of top P for sampling,
    # repetition_penalty=1.05,
    client_roles=client_role_free_access,
    locale='ja',
    token_sampler=token_sampler,

)

これでChatStreamサーバーを起動するとTransformer Mockモードで動作します

注意

入力できるテキストや順序は、記録したときと同じテキストと順序となります

Read more

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第7回 セキュリティとベストプラクティス - 本番環境での考慮事項

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第7回 セキュリティとベストプラクティス - 本番環境での考慮事項

こんにちは、今回はシリーズ第7回セキュリティとベストプラクティス - 本番環境での考慮事項 について解説いたします! 連載の構成 * 第1章:基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎 * 第2章:ドメイン環境の構築 - 検証環境の構築手順 * 第3章:クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順 * 第4章:プロキシサーバーと統合Windows認証 * 第5章:ブラウザ設定と認証 - 各ブラウザでの設定方法 * 第6章:トラブルシューティング - よくある問題と解決方法 * 【★今回です★】第7章:セキュリティとベストプラクティス - 本番環境での考慮事項 * 第8章:実践的な構成例 - AIセキュリティツールとの統合事例 第7章:セキュリティとベストプラクティス 第 7 回は、ここまでの回で作った認証基盤を「本番で運用できる状態」にするための話です。 前半の 7.1

By Qualiteg コンサルティング
Ubuntu 24.04 の GPU サーバーが shutdown で固まる。犯人は HWE カーネルだった

Ubuntu 24.04 の GPU サーバーが shutdown で固まる。犯人は HWE カーネルだった

Ubuntu 24.04 の GPU 推論サーバーが shutdown で固まり、電源長押しになった。前回ブートのジャーナルで追うと、HWE カーネル 7.0 系と NVIDIA 595 open の組み合わせで CUDA プロセスの SIGKILL 直後にページ管理の異常が記録されていた。カーネルと対応する NVIDIA モジュールの組を GA 6.8 系に切り替えて正常な停止を確認し、うっかり HWE に戻らない 4 層の防御まで入れた記録。

By Qualiteg プロダクト開発部
ゼロから作るコーディングエージェント【第5回】ローカルLLMを一級市民にする。16GBのGPU2枚でWebシステムを自走で作らせるまで

ゼロから作るコーディングエージェント【第5回】ローカルLLMを一級市民にする。16GBのGPU2枚でWebシステムを自走で作らせるまで

RTX A5000(24GB)1枚で始めて、ローカルモデル7種類が全滅。RTX A4000(16GB)2枚にQwen3.6-35B-A3BをAWQ 4bitで載せ、fp8のKVキャッシュと98kの文脈で、認証つきWebシステムを3本連続93.8〜96.5点で作らせるまでの構成と落とし穴。モデルの癖、量子化の劣化、文脈長、壊れたツール呼び出しの直し方を、測った数字で書きます。

By Qualiteg プロダクト開発部