7月28日、AWSが「Beyond RAG: Task-aware knowledge compression for enterprise AI on AWS」と題した記事を公開した。RAGの限界を超えるアプローチとして「タスク認識型知識圧縮（TAKC：Task-Aware Knowledge Compression）」の概念と、AWSサーバーレス構成による実装方法を解説している。
RAGが「壁」にぶつかる場面
RAG（Retrieval-Augmented Generation）はシンプルな事実検索には強いが、数百ドキュメントにまたがる複雑な分析タスクでは限界がある。記事が挙げる具体例が鋭い——約5億ドル（$500M）のM&A案件で、12子会社・5年分の財務諸表、200件超の供給者契約、8施設の環境コンプライアンス報告書、50件超の訴訟案件を同時に分析するケースだ。
「現在の仕入先条件と係争中の訴訟を踏まえた財務リスクを総合的に教えてほしい」という問いに対し、RAGの類似検索は答えを出せない。関連情報は何百ものドキュメントに散らばっており、それらの間に語彙的・意味的な共通点がないからだ。
この問題はRAGに限らず、関連技術でも共通の課題として認識されている。たとえばGraphRAGはドキュメント間の関係をグラフ構造で補完するアプローチだが、構築コストが高い。Long-Context LLMはドキュメント全体をコンテキストに詰め込む方法だが、トークンコストが膨大になる。TAKCはこれらとは異なり、「タスクに特化した事前圧縮」によってクエリ時のコストと精度を両立しようとするアプローチだ。なお、TAKCはAWSが本記事で独自に命名した概念であり、学術論文上の確立した用語ではない点に留意が必要だ。知識蒸留（Knowledge Distillation）やクエリ指向サマリゼーションといった既存研究と方向性を同じくするが、AWSはサーバーレス実装と組み合わせた実用的なフレームワークとして位置づけている。
TAKCの核心：「目的別圧縮」という発想
TAKCが解くのはこの問題だ。LLMを使ってドキュメントをタスク特化型のサマリーに事前圧縮し、クエリ時には圧縮済み表現を取り出して推論する。
ポイントは「同じドキュメントでも、タスクによって圧縮結果が異なる」点にある。
- 財務分析向けの圧縮：売上、マージン、キャッシュフロー、負債を保持
- コンプライアンスレビュー向けの圧縮：規制の引用、違反履歴を保持
汎用サマリーは全てをカバーしようとするため情報密度が下がるが、TAKCは特定タスクのレンズを通してドキュメントを圧縮する。圧縮プロンプトはこんな形になる：
TASK: Financial analysis. Preserve revenue metrics, margins, cash flow, debt obligations, and financial risk indicators.
COMPRESSION TARGET: Reduce to approximately 1/16 of original length.
INSTRUCTIONS:
- Focus on facts and relationships relevant to the task
- Preserve numerical data and metrics
- Maintain entities and their attributes
- Keep causal relationships and dependencies
- Remove redundant or irrelevant information
圧縮はドキュメント取り込み時に一度だけ実行される。クエリ時のコストはキャッシュ参照＋圧縮済みコンテキストでの推論のみだ。
4段階の圧縮率と自動ルーティング
TAKCは各タスクタイプに対して4段階の圧縮ティアを維持する。
| ティア | 圧縮率 | 用途 |
|---|---|---|
| Light | 8× | 複数ステップの推論、クロスドキュメント合成 |
| Medium | 16× | 中程度の複雑さの分析クエリ |
| High | 32× | 事実の参照、明確な質問 |
| Ultra | 64× | 分類タスク、キーワード検索 |
「Q3の売上は？」はUltraティアで十分だが、「複数子会社の仕入先支払条件と四半期キャッシュフローの関係は？」はLightティアを要する。クエリの複雑度アナライザーがクエリ長・質問タイプ・分析的言語の有無などを手がかりに自動ルーティングし、ユーザーは意識しなくてよい。ルーティングの確信度が低い場合はMediumティアにフォールバックする。
AWSサーバーレス構成
実装はIngestionパイプラインとQueryパイプラインの2つのサーバーレスパイプラインで構成される。
Ingestionパイプライン：
- S3にドキュメントを配置（例：
raw-data/financial/）するとS3イベントがLambdaをトリガー - Lambdaがドキュメントを256トークン・50トークンオーバーラップでチャンク化
- Amazon Bedrockを呼び出して4段階すべての圧縮を実行
- 圧縮結果を
takc:financial:mediumのようなキーでElastiCache Serverlessに格納（TTL 24時間）、S3にバックアップ
Queryパイプライン：
- Amazon CognitoでJWT認証
- AWS WAFがAPI Gatewayの手前でレート制限・脅威防御
- LambdaがElastiCacheから適切な圧縮キャッシュを取得し、Amazon Bedrockで推論
モデルはAnthropic Claude 3 HaikuおよびClaude 3 Sonnet、Amazon Titan Textから選択でき、CDKのコンテキスト値で切り替え可能だ。
コスト感
10万トークンのナレッジベースを1日1,000クエリで処理した場合の入力トークン比較：
| アプローチ | 1クエリあたり入力トークン | 相対コスト |
|---|---|---|
| フルコンテキスト | 100,000 | 100% |
| RAG (top-10チャンク) | ~10,000 | 10% |
| TAKC Light (8×) | ~12,500 | 12.5% |
| TAKC Medium (16×) | ~6,250 | 6.25% |
| TAKC High (32×) | ~3,125 | 3.1% |
| TAKC Ultra (64×) | ~1,563 | 1.6% |
表を見ると、TAKC Light（8×圧縮）はRAG top-10チャンクより入力トークンが多い（12,500 vs 10,000）点が目を引く。これはRAGがクエリに近いチャンクのみを選択的に取得するのに対し、TAKC Lightはナレッジベース全体を8倍に圧縮したものをまるごと渡すため、粒度が粗くなる分だけトークン量が増えやすいからだ。TAKC Lightの強みはコスト削減ではなく、クロスドキュメントの推論精度にある。
TAKCはIngestion時に一度だけBedrock呼び出しコストが発生する。更新頻度が低く、繰り返しクエリされるナレッジベースほどこのコストが薄まる。逆に、1時間ごとに更新されるナレッジベースにはRAGの方が実用的とAWSは明記している。
TAKCとRAGを使い分ける判断基準
| 判断軸 | TAKCが有利 | RAGが有利 |
|---|---|---|
| クエリの性質 | クロスドキュメントの推論・合成 | 狭い事実の検索 |
| ナレッジベースの更新頻度 | 日次以下 | 時間単位以上 |
| ソース参照の必要性 | 不要 | 必要（監査証跡） |
| トークン予算 | 厳しい | 余裕がある |
両者の併用も現実的な選択肢だ。TAKCで分析回答を生成し、RAGで根拠となるソースドキュメントを取得して監査証跡を確保するという使い方が規制対応ワークロードに向く。
デプロイ手順
aws-samples/sample-bedrock-takc-compressionからリポジトリをクローンし、CDKスタックをデプロイするだけで動く。
git clone https://github.com/aws-samples/sample-bedrock-takc-compression
cd sample-bedrock-takc-compression/cdk
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cdk deploy
デプロイ後、S3にドキュメントをアップロードして2〜3分待てば、4段階すべての圧縮が完了し、APIに対してクエリを投げられる。前提条件はAmazon Bedrockのモデルアクセス権限を持つAWSアカウント、AWS CDK CLI、Python 3.12以降、Node.js 18以降だ。
詳細はBeyond RAG: Task-aware knowledge compression for enterprise AI on AWSを参照していただきたい。
