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