AWS documente le Task-aware Knowledge Compression (TAKC), une approche qui pré-compresse des bases documentales entières en représentations spécifiques pour chaque type d’analyse, avec cache à plusieurs niveaux de fidélité et routage automatique des requêtes. L’article inclut une implémentation open-source.

Si tu as essayé de faire analyser par un assistant des centaines de documents pour une tâche complexe (résumer les facteurs de risque dans 200 rapports trimestriels, trouver des contradictions entre 50 contrats), tu as vu où le RAG classique dysfonctionne. Il récupère les fragments pertinents pour chaque question isolée, mais perd les connexions entre documents ou remplit la fenêtre de contexte au-delà du lisible. Comme nous l’expliquions le 23 juillet, quand c’est un agent qui lit, la qualité du retrieval se déplace du document unique à l’ensemble.

TAKC déplace le travail en amont. Au lieu de récupérer à la volée pour chaque requête, il compresse l’ensemble de la base pour le type de tâche, tient prêtes les versions compressées en cache à plusieurs niveaux et achemine chaque question vers le niveau approprié. La lecture intensive se fait une fois, les requêtes suivantes voyagent sur les représentations préparées.

C’est l’étape pratique suivante après RAG, avec code ouvert et blueprint testé, pas une idée de papier. Le fait qu’AWS la documente avec un repo distribuable la rend vérifiable.

En détail

Le RAG traditionnel fonctionne ainsi : tu prends une question, la transformes en vecteur, cherches dans la base de données les fragments de document les plus similaires, les colles dans le prompt et laisses le modèle répondre. Pour « trouve le paragraphe qui mentionne la clause 4.2 » c’est parfait. Mais quand la tâche est analytique et couvre des dizaines ou des centaines de documents, deux choses se cassent.

D’abord : le retrieval attrape trop de matériel ou trop peu. Trop, et tu dépasses la fenêtre de contexte du modèle. Pas assez, et tu perds les connexions entre documents nécessaires pour construire la réponse.

Ensuite : chaque requête répète le même travail. Si cent analystes posent des questions similaires sur les mêmes documents, le système récupère et relit chaque fois depuis zéro.

TAKC change le moment où le travail est fait. Il pré-traite l’ensemble de la base documentale pour des types de tâches spécifiques, compresse les documents en représentations orientées vers la tâche, les mémorise en cache à plusieurs niveaux de fidélité (du résumé à l’extraction détaillée) et achemine chaque requête vers le niveau approprié.

Imagine un analyste qui lit tout une fois, prépare des fiches résumées par thème et garde à portée de main tant les fiches que les originaux. Quand arrive une question, il décide si le résumé suffit ou si le document complet est nécessaire. Le travail de lecture intensive se fait une fois, pas pour chaque requête.

L’article d’AWS décrit l’architecture complète, les niveaux de cache et le routage, et fournit une implémentation open-source distribuable sur votre propre infrastructure.

Les limites. L’article vient d’AWS, qui a intérêt à promouvoir des solutions qui tournent sur ses services. L’implémentation ouverte aide, mais nous n’avons pas de benchmarks indépendants comparant TAKC au RAG traditionnel sur des tâches identiques. La pré-compression a un coût initial : elle exige de connaître les types de tâches à l’avance et consomme du compute avant que la première requête soit posée. Si tes tâches sont imprévisibles ou changent fréquemment, l’investissement initial pourrait ne pas être rentable. Et la compression introduira toujours une certaine perte d’information : l’importance dépend de ton cas concret.

Pour qui construit des systèmes sur des corpus importants, vaut la peine de lire l’article et d’essayer le repo. Pour qui fait du RAG à petite échelle (quelques dizaines de documents), le problème que TAKC résout ne se pose pas encore. Le playbook sur comment faire lire les documents longs sans omissions silencieuses reste le point de départ pratique pour qui y travaille aujourd’hui.