公開日: 2025 年 3 月 12 日、最終更新日: 2025 年 5 月 28 日
| 商品の解説 | ウェブ | 拡張機能 | Chrome ステータス | インテント |
|---|---|---|---|---|
| MDN | 表示 | 発送予定 |
Summarizer API を使用すると、さまざまな長さと形式で情報の要約を生成できます。Chrome の Gemini Nano や、ブラウザに組み込まれている他の言語モデルと組み合わせて使用すると、長文や複雑なテキストを簡潔に説明できます。
クライアントサイドで実行すると、データをローカルで処理できるため、機密データを安全に保ち、大規模な可用性を実現できます。ただし、コンテキスト ウィンドウはサーバーサイド モデルよりもはるかに小さいため、非常に大きなドキュメントの要約は難しい場合があります。この問題を解決するには、要約の要約の手法を使用します。
要約の要約とは何ですか？
要約の要約の手法を使用するには、入力コンテンツをキーポイントで分割し、各部分を個別に要約します。各部分の出力を連結し、この連結されたテキストを 1 つの最終的な要約にまとめることができます。
コンテンツを慎重に分割する
大規模なテキストを分割する方法を検討することが重要です。戦略が異なると、LLM 間で異なる出力が生成される可能性があります。理想的には、記事の新しいセクションや段落など、トピックが変更されたときにテキストを分割する必要があります。単語や文の途中でテキストを分割しないことが重要です。つまり、文字数だけを分割のガイドラインとして使用することはできません。
これにはさまざまな方法があります。次の例では、パフォーマンスと出力品質のバランスが取れた LangChain.js の Recursive Text Splitter を使用しました。これはほとんどのワークロードで機能します。
新しいインスタンスを作成する際には、次の 2 つの重要なパラメータがあります。
chunkSizeは、各分割で許可される最大文字数です。chunkOverlapは、2 つの連続する分割間で重複する文字数です。これにより、各チャンクに前のチャンクのコンテキストの一部が含まれるようになります。
splitText() でテキストを分割し、各チャンクを含む文字列の配列を返します。
ほとんどの LLM のコンテキスト ウィンドウは、文字数ではなくトークン数で表されます。トークンには平均して 4 文字が含まれています。この例では、chunkSize は 3, 000 文字で、約 750 トークンです。
トークンの可用性を判断する
入力に使用できるトークンの数を判断するには、measureInputUsage() メソッドと inputQuota プロパティを使用します。この場合、すべてのテキストを処理するために要約ツールが何回実行されるかわからないため、実装は無制限になります。
分割ごとに要約を生成する
コンテンツの分割方法を設定したら、Summarizer API を使用して各部分の要約を生成できます。
create() 関数を使用して、要約ツールのインスタンスを作成します。コンテキストをできるだけ保持するため、format パラメータを plain-text に、type を tldr に、length を long に設定しました。
次に、RecursiveCharacterTextSplitter によって作成された分割ごとに要約を生成し、結果を新しい文字列に連結します。各パートの概要を明確に識別できるように、各概要を改行で区切りました。
この新しい行は、このループを 1 回だけ実行する場合は重要ではありませんが、各要約が最終的な要約のトークン値にどのように追加されるかを判断するのに役立ちます。ほとんどの場合、このソリューションは中程度の長さのコンテンツと長いコンテンツで機能します。
要約の再帰的要約
テキストが非常に長い場合、連結された要約の長さが使用可能なコンテキスト ウィンドウよりも大きくなるため、要約が失敗することがあります。これに対処するには、要約を再帰的に要約します。
RecursiveCharacterTextSplitter によって生成された最初の分割は引き続き収集されます。次に、recursiveSummarizer() 関数で、連結された分割の文字長に基づいて要約プロセスをループします。要約の文字数が 3000 を超える場合は、fullSummaries に連結します。上限に達していない場合は、要約が partialSummaries として保存されます。
すべての要約が生成されると、最終的な部分的な要約が完全な要約に追加されます。fullSummaries に要約が 1 つしかない場合、追加の再帰は必要ありません。この関数は最終的な要約を返します。複数の要約が存在する場合、関数は繰り返され、部分的な要約の要約が続行されます。
このソリューションは、17,560 語を含む 110,030 文字の インターネット リレー チャット（IRC）RFC でテストしました。Summarizer API は次の要約を提供しました。
インターネット リレー チャット（IRC）は、テキスト メッセージを使用してオンラインでリアルタイムにコミュニケーションをとる方法です。チャンネルでチャットしたり、プライベート メッセージを送信したりできます。また、コマンドを使用してチャットを制御したり、サーバーとやり取りしたりできます。インターネット上のチャットルームのようなもので、メッセージを入力すると、他のユーザーのメッセージがすぐに表示されます。
これはかなり効果的です。文字数は 309 文字です。
制限事項
要約の要約手法は、クライアント サイズのモデルのコンテキスト ウィンドウ内で動作するのに役立ちます。クライアントサイド AI には多くのメリットがありますが、次のような問題が発生する可能性があります。
- 要約の精度が低下する: 再帰を使用すると、要約プロセスの繰り返しが無限になる可能性があり、各要約が元のテキストから遠ざかります。つまり、モデルが生成する最終的な要約が浅すぎて、役に立たない可能性があります。
- パフォーマンスの低下: 各要約の生成に時間がかかります。大規模なテキストでは要約の数が無限になる可能性があるため、このアプローチでは完了までに数分かかることがあります。
要約ツールのデモをご用意しています。また、完全なソースコードもご覧いただけます。
フィードバックをお寄せください
Summarizer API を使用して、入力テキストの長さ、分割サイズ、オーバーラップの長さを変えて、要約の要約の手法を試してください。
- Chrome の実装に関するフィードバックについては、バグレポートまたは機能リクエストを送信してください。
- MDN のドキュメントを読む
- 要約プロセスやその他の組み込み AI に関する質問については、Chrome AI チームとチャットしてください。