Slimming context: как уменьшать токен-контекст без потери качества

Я — Денис Шохирев, Enterprise AI архитектор из Фрайбурга, Германия. В DennisCraft AI Studio я внедряю AI-агентов для B2B-клиентов из DACH-региона в логистике, финтехе и промышленной автоматизации. Стек: Claude, Supabase, n8n, Doppler, self-hosted Postgres. За последние полгода я внедрил 14 production-агентов, и каждый второй проект упирался в проблему «раздувания» токен-контекста: в реальных пайплайнах промты быстро переростают лимиты моделей, а решения из демо не выдерживают регламентированных нагрузок.

Почему контекст разрастается в проде

Когда вы проектируете LLM-агента для индустриального клиента, особенно с длинными историческими данными (например, отслеживание грузов или аудиторские логи), размер токен-контекста быстро уходит за тысячи токенов. Claude 3 Opus держит до 200K токенов (Anthropic docs, 2024), но даже это не всегда хватает — особенно если в pipeline несколько агентов, которые пересылают друг другу состояния и результаты.

Проблемы, которые я вижу у клиентов:

• В логистике — вся история диалога плюс технические данные по грузам, SLA, инструкциям.
• В финтехе — длинные цепочки транзакций (до 5000 строк на одного пользователя), которые надо анализировать в real-time.
• В промышленности — логи оборудования, диагностические отчёты, часто превышающие 10K токенов за одну сессию.

Перегруз контекста бьёт по latency и бюджету: inference растёт по времени и стоимости, а качество ответа падает из-за «размытия» релевантной информации.

Топ-5 production-паттернов slimming context

Semantic Chunking и RAG на практике

Semantic Chunking

Вместо того чтобы «резать» документы по 1024 или 2048 токенов, режу их по смысловым блокам (абзацам, главам, секциям). Для этого использую python-скрипты с sentence-transformers и стандартными токенизаторами от openai/anthropic. Краткий пример:

from sentence_transformers import SentenceTransformer
import tiktoken

model = SentenceTransformer('all-MiniLM-L6-v2')
tokenizer = tiktoken.get_encoding('cl100k_base')

def semantic_chunks(text, max_tokens=1024):
    sentences = text.split('. ')
    current_chunk = []
    current_len = 0
    for sent in sentences:
        token_len = len(tokenizer.encode(sent))
        if current_len + token_len > max_tokens:
            yield ' '.join(current_chunk)
            current_chunk = [sent]
            current_len = token_len
        else:
            current_chunk.append(sent)
            current_len += token_len
    if current_chunk:
        yield ' '.join(current_chunk)

Этот паттерн особенно хорош для длинных регламентов или инструкций.

RAG с Supabase и pgvector

В проде для поиска по историческим данным всегда использую RAG-паттерн: индексация документов в pgvector (Supabase), быстрый поиск топ-N релевантных чанков, отправка только их в LLM. Пример pipeline на n8n:

// n8n custom function for RAG
items = $input.all();
const query = items[0].json.query;
const results = await $supabase
  .from('documents')
  .select('content, embedding')
  .order('embedding', { ascending: false })
  .limit(5);
return results.data;

Такой подход «сжимает» контекст с 20K токенов до 1-2K без потери релевантности.

Context Window Pruning и Summarization

Context Window Pruning

Для диалоговых агентов внедряю sliding window: только последние 5-7 сообщений, плюс summary по истории. Итоговый prompt всегда укладывается в 2-3K токенов. Это критично для latency и стабильности. В n8n или python-функциях реализую фильтрацию:

def prune_context(messages, max_tokens=2048):
    pruned = []
    total = 0
    for msg in reversed(messages):
        tokens = len(tokenizer.encode(msg['content']))
        if total + tokens > max_tokens:
            break
        pruned.insert(0, msg)
        total += tokens
    return pruned

Summarization-on-the-fly

Для логов и длинных цепочек данных запускаю промежуточное суммирование на каждом этапе пайплайна. Например, каждые 1000 событий агрегирую summary с помощью GPT-4 или Claude, чтобы сохранить суть, а не детали. Это особенно актуально для финтех-агентов, где нужно видеть только аномалии или outliers.

Schema-based Filtering: когда структура — друг

Если данные строго структурированы (JSON, API-ответы), фильтрую только нужные поля через Pydantic или собственные фильтры. Это «холодный» способ выкинуть шум до попадания в prompt.

from pydantic import BaseModel

class Transaction(BaseModel):
    id: str
    amount: float
    date: str
    status: str

def filter_transactions(raw):
    txs = [Transaction(**t) for t in raw if t['status'] == 'active']
    return txs

FAQ

Какая реальная экономия токенов?

На практике slimming-паттерны уменьшают итоговый prompt в 5-10 раз (с 20K до 2-4K токенов) без падения качества. Считаю savings через OpenAI tokenizer и анализ latency/стоимости.

Есть ли разница между Claude и OpenAI по контекст-менеджменту?

Да, у Claude лучше переносится длинный контекст (до 200K), но prompt-оптимизация нужна и там — latency и стоимость растут нелинейно.

RAG всегда лучше, чем summary?

Нет, для диалогов или событийных данных summary эффективнее. RAG — для поиска по документам.

А что с безопасностью при slimming?

Важно не выбрасывать security-значимые фрагменты. Для этого использую semgrep/bandit/gitleaks для автоматического поиска паттернов в данных.

Нужно ли делать тесты на каждом slimming-этапе?

Да, иначе легко потерять критичные данные. Покрываю пайплайны тестами — как минимум через pytest и ручную валидацию.

В вашем prod-LLM pipeline где чаще всего «раздувается» контекст — на этапе сбора данных, передачи между агентами или при логировании? Готов обсудить. Я провожу бесплатный 30-мин аудит стека для DACH-компаний, кто строит AI в регламентированных отраслях. Пишите в LinkedIn или на @ger_dennis_ai.