モデル概要
モデル特徴
モデル能力
使用事例
🚀 TENターン検出
全二重対話通信のためのターン検出
🚀 クイックスタート
TENターン検出は、GitHub上でも利用可能です。TEN-framework/ten-turn-detection
インストール
pip install "transformers>=4.45.0"
pip install "torch>=2.0.0"
モデルの重み
TENターン検出モデルは、HuggingFace上で利用可能です。
推論
from transformers import AutoTokenizer, AutoModelForCausalLM
import torch
# モデルとトークナイザーをロード
model_id = 'TEN-framework/TEN_Turn_Detection'
model = AutoModelForCausalLM.from_pretrained(model_id, trust_remote_code=True, torch_dtype=torch.bfloat16)
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
# モデルをGPUに移動
model = model.cuda()
model.eval()
# 推論用の関数
def analyze_text(text, system_prompt=""):
inf_messages = [{"role":"system", "content":system_prompt}] + [{"role":"user", "content":text}]
input_ids = tokenizer.apply_chat_template(
inf_messages,
add_generation_prompt=True,
return_tensors="pt"
).cuda()
with torch.no_grad():
outputs = model.generate(
input_ids,
max_new_tokens=1,
do_sample=True,
top_p=0.1,
temperature=0.1,
pad_token_id=tokenizer.eos_token_id
)
response = outputs[0][input_ids.shape[-1]:]
return tokenizer.decode(response, skip_special_tokens=True)
# 使用例
text = "Hello I have a question about"
result = analyze_text(text)
print(f"Input: '{text}'")
print(f"Turn Detection Result: '{result}'")
✨ 主な機能
-
コンテキスト認識型ターン管理 TENターン検出は、言語パターンとセマンティックコンテキストを分析して、ターンの完了ポイントを正確に識別します。この機能により、システムはコンテキストに適した割り込みを判断し、さまざまな対話シナリオで自然な会話の流れを維持することができます。
-
多言語ターン検出サポート TENターン検出は、英語と中国語の両方の言語をサポートしています。多言語の会話でターンテイキングの手がかりと完了信号を正確に識別するように設計されています。
-
卓越した性能 複数のオープンソースソリューションと比較して、TENは公開されているテストデータセットのすべての指標で卓越した性能を達成しています。
📦 インストール
pip install "transformers>=4.45.0"
pip install "torch>=2.0.0"
💻 使用例
基本的な使用法
from transformers import AutoTokenizer, AutoModelForCausalLM
import torch
# モデルとトークナイザーをロード
model_id = 'TEN-framework/TEN_Turn_Detection'
model = AutoModelForCausalLM.from_pretrained(model_id, trust_remote_code=True, torch_dtype=torch.bfloat16)
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
# モデルをGPUに移動
model = model.cuda()
model.eval()
# 推論用の関数
def analyze_text(text, system_prompt=""):
inf_messages = [{"role":"system", "content":system_prompt}] + [{"role":"user", "content":text}]
input_ids = tokenizer.apply_chat_template(
inf_messages,
add_generation_prompt=True,
return_tensors="pt"
).cuda()
with torch.no_grad():
outputs = model.generate(
input_ids,
max_new_tokens=1,
do_sample=True,
top_p=0.1,
temperature=0.1,
pad_token_id=tokenizer.eos_token_id
)
response = outputs[0][input_ids.shape[-1]:]
return tokenizer.decode(response, skip_special_tokens=True)
# 使用例
text = "Hello I have a question about"
result = analyze_text(text)
print(f"Input: '{text}'")
print(f"Turn Detection Result: '{result}'")
📚 ドキュメント
概要
TENターン検出は、人間とAIエージェントの自然で動的なコミュニケーションを目的として設計された高度な智能ターン検出モデルです。この技術は、人間とAIの会話における最も困難な課題の1つである、自然なターンテイキングの手がかりを検出し、コンテキストを考慮した割り込みを可能にすることを解決します。TENは、会話コンテキストと言語パターンの深いセマンティック理解を組み込み、AIとのより自然な対話を実現します。
TENターン検出は、ユーザーのテキストを3つの主要な状態に分類します。
finished:ユーザーが完全な考えを表現し、応答を期待している完了した発話。例: "Hey there I was wondering can you help me with my order"
wait:ユーザーがAIに話さないように明示的に指示した待機発話。例: "Shut up"
unfinished:ユーザーが一時的に一時停止したが、話を続ける意図がある明らかに未完了の発話。例: "Hello I have a question about"
これらの3つの分類状態により、TENシステムはターンテイキングをインテリジェントに管理し、不自然な割り込みを減らしながら会話の流れを維持することで、自然な会話のダイナミクスを作成することができます。
TENターン検出は、トランスフォーマーベースの言語モデル(Qwen2.5-7B)に基づく多層アプローチを利用してセマンティック分析を行います。
用意されたデータセット
TEN-Turn-Detection TestSetをオープンソース化しました。これは、AI対話システムのターン検出機能を評価するために特別に設計された、中国語と英語のバイリンガルの会話入力のコレクションです。データセットは3つの異なるコンポーネントで構成されています。
wait.txt:会話の一時停止または終了を要求する表現が含まれています。
unfinished.txt:途中で途切れた不完全な対話入力が特徴です。
finished.txt:複数のドメインにわたる完全な会話入力を提供します。
検出性能
テストデータセットを使用して、いくつかのオープンソースモデルのターン検出性能を比較する包括的な評価を行いました。
精度 | 未完了
精度 | 待機
精度 | |:--------:|:-----:|:--------------------:|:----------------------:|:----------------:| | 英語 | モデルA | 59.74% | 86.46% | N/A | | 英語 | モデルB | 71.61% | 96.88% | N/A | | 英語 | **TENターン検出** | **90.64%** | **98.44%** | **91%** |
言語 | モデル | 完了 精度 |
未完了 精度 |
待機 精度 |
---|---|---|---|---|
中国語 | モデルB | 74.63% | 88.89% | N/A |
中国語 | TENターン検出 | 98.90% | 92.74% | 92% |
⚠️ 重要提示
- モデルAは中国語の処理をサポートしていません。
- モデルAとモデルBのどちらも、「待機」状態の検出をサポートしていません。
🔧 技術詳細
量子化を超えたIMatrix
標準のIMatrixが低ビット量子化とMOEモデルではあまりうまく機能しないことがわかったため、llama.cpp --tensor-typeを使用して選択したレイヤーをバンプアップしています。詳細はLayer bumping with llama.cppを参照してください。
これにより、モデルファイルが大きくなりますが、与えられたモデルサイズに対する精度が向上します。
適切なモデル形式の選択
正しいモデル形式の選択は、ハードウェア能力とメモリ制限に依存します。
BF16(Brain Float 16) – BF16アクセラレーションが利用可能な場合に使用
- 高速な計算を目的とした16ビット浮動小数点形式で、良好な精度を維持します。
- FP32と同様のダイナミックレンジを提供しますが、メモリ使用量が少なくなります。
- ハードウェアがBF16アクセラレーションをサポートしている場合に推奨されます(デバイスの仕様を確認してください)。
- FP32と比較して、メモリ使用量を削減しながら高性能な推論に最適です。
📌 BF16を使用する場合 ✔ ハードウェアがネイティブのBF16サポートを持っている場合(例:新しいGPU、TPU)。 ✔ メモリを節約しながら、より高い精度が必要な場合。 ✔ モデルを別の形式に再量子化する予定の場合。
📌 BF16を避ける場合 ❌ ハードウェアがBF16をサポートしていない場合(FP32にフォールバックして低速になる可能性があります)。 ❌ BF16最適化を欠く古いデバイスとの互換性が必要な場合。
F16(Float 16) – BF16よりも広くサポートされています
- 16ビット浮動小数点形式で、高い精度を持ちますが、BF16よりも値の範囲が狭くなります。
- ほとんどのデバイスでFP16アクセラレーションをサポートしています(多くのGPUと一部のCPUを含む)。
- BF16よりもわずかに数値精度が低いですが、一般的に推論には十分です。
📌 F16を使用する場合 ✔ ハードウェアがFP16をサポートしているが、BF16をサポートしていない場合。 ✔ 速度、メモリ使用量、精度のバランスが必要な場合。 ✔ GPUまたはFP16計算に最適化された他のデバイスで実行する場合。
📌 F16を避ける場合 ❌ デバイスがネイティブのFP16サポートを欠いている場合(予想よりも低速になる可能性があります)。 ❌ メモリ制限がある場合。
ハイブリッド精度モデル(例:bf16_q8_0
、f16_q4_K
) – 両方の世界のベスト
これらの形式は、重要でないレイヤーを選択的に量子化しながら、キーレイヤーをフル精度(例:注意レイヤーと出力レイヤー)で保持します。
bf16_q8_0
のような名前がつけられています(フル精度のBF16コアレイヤー + 量子化されたQ8_0の他のレイヤーを意味します)。- メモリ効率と精度のバランスをとり、完全に量子化されたモデルよりも改善され、BF16/F16の完全なメモリを必要としません。
📌 ハイブリッドモデルを使用する場合 ✔ 量子化のみのモデルよりも高い精度が必要で、すべての場所でフルBF16/F16を使用する余裕がない場合。 ✔ デバイスが混合精度推論をサポートしている場合。 ✔ 制約されたハードウェアでの本番グレードのモデルのトレードオフを最適化したい場合。
📌 ハイブリッドモデルを避ける場合 ❌ ターゲットデバイスが混合またはフル精度アクセラレーションをサポートしていない場合。 ❌ 超厳格なメモリ制限の下で動作している場合(その場合は完全に量子化された形式を使用してください)。
量子化モデル(Q4_K、Q6_K、Q8など) – CPUと低VRAM推論用
量子化は、モデルサイズとメモリ使用量を削減しながら、できるだけ精度を維持します。
- 低ビットモデル(Q4_K) → 最小のメモリ使用量に最適ですが、精度が低くなる可能性があります。
- 高ビットモデル(Q6_K、Q8_0) → より高い精度を提供しますが、より多くのメモリが必要です。
📌 量子化モデルを使用する場合 ✔ CPUで推論を実行し、最適化されたモデルが必要な場合。 ✔ デバイスのVRAMが少なく、フル精度のモデルをロードできない場合。 ✔ 合理的な精度を維持しながら、メモリ使用量を削減したい場合。
📌 量子化モデルを避ける場合 ❌ 最大の精度が必要な場合(フル精度のモデルの方が適しています)。 ❌ ハードウェアに十分なVRAMがあり、より高い精度の形式(BF16/F16)を使用できる場合。
超低ビット量子化(IQ3_XS、IQ3_S、IQ3_M、Q4_K、Q4_0)
これらのモデルは、非常に高いメモリ効率のために最適化されており、低電力デバイスまたはメモリが重要な制約となる大規模なデプロイメントに最適です。
-
IQ3_XS:超低ビット量子化(3ビット)で、非常に高いメモリ効率を持ちます。
- 使用例:Q4_Kでさえ大きすぎる超低メモリデバイスに最適です。
- トレードオフ:より高いビット量子化と比較して、精度が低くなります。
-
IQ3_S:最大のメモリ効率のための小さなブロックサイズです。
- 使用例:IQ3_XSが過度に制限的である低メモリデバイスに最適です。
-
IQ3_M:IQ3_Sよりも精度が高い中サイズのブロックサイズです。
- 使用例:IQ3_Sが制限的である低メモリデバイスに適しています。
-
Q4_K:ブロック単位の最適化による4ビット量子化で、精度が向上します。
- 使用例:Q6_Kが大きすぎる低メモリデバイスに最適です。
-
Q4_0:純粋な4ビット量子化で、ARMデバイス用に最適化されています。
- 使用例:ARMベースのデバイスまたは低メモリ環境に最適です。
超超低ビット量子化(IQ1_S IQ1_M IQ2_S IQ2_M IQ2_XS IQ2_XSS)
- 超超低ビット量子化(1 2ビット)で、極端なメモリ効率を持ちます。
- 使用例:モデルを非常に制限されたメモリに収める必要がある場合に最適です。
- トレードオフ:非常に低い精度。期待どおりに機能しない可能性があります。使用前に十分にテストしてください。
モデル形式選択のまとめ表
モデル形式 | 精度 | メモリ使用量 | デバイス要件 | 最適な使用例 |
---|---|---|---|---|
BF16 | 非常に高い | 高い | BF16対応のGPU/CPU | メモリを削減した高速推論 |
F16 | 高い | 高い | FP16対応のGPU/CPU | BF16が利用できない場合の推論 |
Q4_K | 中~低 | 低い | CPUまたは低VRAMデバイス | メモリ制限のある推論 |
Q6_K | 中 | 中程度 | より多くのメモリを持つCPU | 量子化によるより高い精度 |
Q8_0 | 高い | 中程度 | 中程度のVRAMを持つGPU/CPU | 量子化モデルの中で最も高い精度 |
IQ3_XS | 低い | 非常に低い | 超低メモリデバイス | 最大のメモリ効率、低い精度 |
IQ3_S | 低い | 非常に低い | 低メモリデバイス | IQ3_XSよりも少し使いやすい |
IQ3_M | 低~中 | 低い | 低メモリデバイス | IQ3_Sよりも高い精度 |
Q4_0 | 低い | 低い | ARMベース/組み込みデバイス | Llama.cppが自動的にARM推論を最適化します |
超超低ビット(IQ1/2_*) | 非常に低い | 非常に低い | 小型のエッジ/組み込みデバイス | 非常に限られたメモリにモデルを収める;低い精度 |
ハイブリッド(例:bf16_q8_0 ) |
中~高 | 中程度 | 混合精度対応のハードウェア | パフォーマンスとメモリのバランス、重要なレイヤーでのFPに近い精度 |
テストについて
これらのモデルが役立つと思われる場合は、AI搭載の量子ネットワークモニターアシスタントのテストに協力していただけると幸いです。
量子ネットワークモニターサービスの完全なオープンソースコードは、私のGitHubリポジトリ(NetworkMonitorという名前のリポジトリ)で入手できます。量子ネットワークモニターのソースコード また、モデルを自分で量子化したい場合は、使用しているコードも見つけることができます。GGUFModelBuilder
テスト方法
AIアシスタントのタイプを選択します。
TurboLLM
(GPT-4.1-mini)HugLLM
(最新のオープンソースモデル)TestLLM
(実験的なCPU専用)
テスト内容
AIネットワークモニタリングの小さなオープンソースモデルの限界を追求しています。具体的には、
- ライブネットワークサービスに対する関数呼び出し
- モデルがどれだけ小さくなっても、以下の処理を行えるか
- 自動化されたNmapセキュリティスキャン
- 量子対応チェック
- ネットワークモニタリングタスク
現在の実験モデル(TestLLM)
- ✅ ゼロコンフィギュレーションセットアップ
- ⏳ 30秒のロード時間(推論は遅いですが、APIコストがかからない)。コストが低いため、トークン制限はありません。
- 🔧 協力者募集! エッジデバイスAIに興味がある方は、一緒に協力しましょう!
その他のアシスタント
🟢 TurboLLM – gpt-4.1-mini を使用しています。
- **非常に良好なパフォーマンスを発揮しますが、残念ながらOpenAIはトークンごとに料金を請求します。そのため、トークンの使用量は制限されています。
- 量子ネットワークモニターエージェントで.NETコードを実行するカスタムコマンドプロセッサを作成する
- リアルタイムのネットワーク診断とモニタリング
- セキュリティ監査
- 侵入テスト(Nmap/Metasploit)
🔵 HugLLM – 最新のオープンソースモデルです。
- 🌐 Hugging Face Inference APIで実行されます。Novitaにホストされている最新のモデルを使用して、かなり良好なパフォーマンスを発揮します。
テストできるコマンドの例
"Give me info on my websites SSL certificate"
"Check if my server is using quantum safe encyption for communication"
"Run a comprehensive security audit on my server"
- '"Create a cmd processor to .. (what ever you want)" 注:.NETコードを実行するには、量子ネットワークモニターエージェントをインストールする必要があります。これは非常に柔軟で強力な機能です。注意して使用してください!
最後の言葉
これらのモデルファイルを作成するために使用するサーバー、量子ネットワークモニターサービスを実行するためのサーバー、およびNovitaとOpenAIからの推論費用は、すべて私の私費で負担しています。モデル作成と量子ネットワークモニタープロジェクトの背後にあるすべてのコードはオープンソースです。役に立つものがあれば、自由に使用してください。
もしあなたがこの仕事を評価してくれるなら、コーヒーを買ってくれることを検討してみてください。あなたの支援は、サービスコストをカバーし、誰もがトークン制限を引き上げることができるようにするのに役立ちます。
また、仕事の機会やスポンサーシップも歓迎しています。
ありがとうございます!😊
📄 ライセンス
このプロジェクトはApache 2.0ライセンスの下で提供されています。
引用
もしあなたが研究やアプリケーションでTEN Turn Detectionを使用する場合は、以下のように引用してください。
@misc{TEN_Turn_Detection,
author = {TEN Team},
title = {TEN Turn Detection: Turn detection for full-duplex dialogue communication },
year = {2025},
url = {https://github.com/TEN-framework/ten-turn-detection},
}






