[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

PII 非識別化の本質——「誰か」は偽ってよい、「何が起きたか」は偽ってはならない

PII 非識別化の本質——「誰か」は偽ってよい、「何が起きたか」は偽ってはならない

こんにちは!Qualitegプロダクト開発部です! 本日は、PII( Personally Identifiable Information→個人情報)の非識別化に関する内容を解説いたします。 当社ではこれまで、高精度なPII検出技術やLLM利用時の段階的PIIマスキング、PII検出のテスト設計など、個人情報検出とAIセキュリティに関する技術解説をお届けしてきました。 現在、当社では、PII検出マスキング技術「PII-FIエンジン」と、それを活用したPIIのマスキング・非識別化サービス「PII-FI Scan」「PII-FI API」を開発・提供しています。 本記事では、「PIIを検出したあと、それをどう書き換えるか」の設計原則を、1つの例文を試金石にして、私たちが実際のプロダクトで採用している整理をご紹介します。 先にことわっておきますと、本記事でいう「非識別化(de-identification)」は、文書やログを安全に共有・分析するための技術的な加工(個人を特定できないように加工する処理)のお話です。 個人情報保護法上の「仮名加工情報」「匿名加工情報」に該当することを

By Qualiteg プロダクト開発部, Qualiteg AIセキュリティチーム
日本語対応 LLMランキング2026 ~ベンチマーク分析レポート~(7月10日版)

日本語対応 LLMランキング2026 ~ベンチマーク分析レポート~(7月10日版)

はじめに 本レポートは、Nejumi Leaderboard 4のベンチマークデータ(2026/7/10版)に基づいて、日本語対応LLMの性能を総合的に分析したものです。 前回は 2026/3/6 版の分析レポート を公開しましたが、 約4か月ぶりとなる今回も、上位勢の顔ぶれが大きく入れ替わる激動の回となりました! (定期的に最新LLMランキングを更新してまいります。当社のX(旧Twitter)をフォローいただくことで更新情報を受け取り可能です) Nejumi Leaderboard 4は、日本語タスクにおけるLLMの性能を多角的に評価する信頼性の高いベンチマークとして知られています。汎用的言語性能(GLP)とアラインメント(ALT)の2軸で構成され、翻訳・要約・推論・コーディングから毒性・バイアス・真実性まで、幅広い観点をカバーしているのが特徴です。 本分析では、商用APIモデルとオープンモデルの両方を対象に、それぞれの特徴や傾向を詳しく見ていきます。まず、今回の3大トピックを先にご紹介します。 * Claude Opus 4.8がリーダーボード史上初の総合スコア0.8

By Qualiteg プロダクト開発部
Claude Fable5 完全ガイド — 公式ドキュメントから読み解くモデル仕様とClaude Code運用ポイント

Claude Fable5 完全ガイド — 公式ドキュメントから読み解くモデル仕様とClaude Code運用ポイント

こんにちは! 2026年6月に登場した Claude Fable 5 は、公開直後の輸出規制による一時停止、グローバル再展開、そしてサブスクリプション枠からの離脱と、わずか1か月でめまぐるしい動きを見せています。 当ブログでもその時々の状況を追ってきました。 まず全体像は ついに一般公開、Claude Mythos 5 / Fable 5 を実務視点で読み解く で、公開直後の停止騒動は 公開から3日で停止──Fable 5/Mythos 5 をめぐる米政府指令が示した、AI の新しい可用性リスク で、料金と今後の見通しは Claude Fable 5 はこれからどうなる? 経緯・コスト・今後の見通し で扱っています。 本記事は、それらを踏まえた「実務で使うための決定版ガイド」です。 とくに 2026年7月12日(日本時間7月13日)を境にサブスクリプション枠から外れ、使用クレジットを有効化しないと使えなくなる (この期限は当初2026年7月7日とされていましたが、のちに5日間延長されて7月12日になりました。

By Qualiteg プロダクト開発部
AI時代のデータ漏洩防止の要諦とテクノロジー:第2回 従来型DLPを超えて、AI-DLPが解決すべき本質的課題

AI時代のデータ漏洩防止の要諦とテクノロジー:第2回 従来型DLPを超えて、AI-DLPが解決すべき本質的課題

こんにちは! 前回の記事では、AI時代のデータ漏洩防止における技術的な基礎として、HTTPSインターセプトの仕組みと限界について詳しく解説しました。プロキシサーバーによるSSL/TLS通信の復号化、中間CA証明書の運用、そして証明書ピンニングという技術的制約まで、企業がWeb通信を監視する際の技術的な現実を明らかにしました。 しかし、これらのプロキシ技術は、実は既存のDLP製品でも広く採用されている一般的な手法です。メール監視、ファイル転送の制御、Webアクセスの監査など、従来型のデータ漏洩防止においても、HTTPSインターセプトは中核的な役割を果たしてきました。 では、なぜAI時代において新たにDLPを考え直す必要があるのでしょうか。 前回にひきつづき、従来型DLPでは対応できないAI固有の課題と、AI-DLPとして新たに考慮すべき要素に焦点を当て、より本質的な議論を展開していきます。 1. AI時代が要求する新たなDLP要件 従来のDLP製品は、クレジットカード番号や社会保障番号といった定型的なパターンの検出において優れた実績を持っています。これらの技術は今後も重要な

By Qualiteg プロダクト開発部, Qualiteg コンサルティング