История о том, как я решаю проблему, которую мне мешает работать с локльными моделями ИИ( пост помог составить ии)

Каждый, кто пользовался ChatGPT, Claude или любым другим LLM в длинных диалогах, замечал странное: первые 10–20 (условно)сообщений модель работает прекрасно, а потом начинает забывать, путаться и выдумывать. К десятому уточнению она уже не помнит, что обсуждали в самом начале. К тридцатому — теряет нить разговора. К пятидесятому — превращается в полуслучайный генератор текста. Это фундаментальное ограничение всех современных LLM: у каждой модели есть context window — максимальный объём текста, который она может «видеть» одновременно. У GPT-4 это 128k токенов, у Claude — 200k, у локальных моделей на 12 GB видеокарты — обычно 4–8k. Но проблема не только в размере окна. Даже когда текст помещается в окно, модель начинает терять фокус. Это называется context degradation — способность модели «удерживать внимание» на важной информации падает по мере роста объёма. Исследования показывают, что после 20k токенов качество ответов деградирует даже у GPT-4. Что делают обычные решения? Truncate (обрезка) — отрезаем начало разговора. Информация потеряна навсегда. Summarize (суммаризация) — сжимаем старое в краткое резюме. Потери неизбежны. RAG (поиск) — достаём релевантные куски из базы знаний. Работает для документов, но не для диалогов. Большее context window — просто увеличиваем окно. Дорого, медленно, всё равно деградирует. Все эти подходы — про обход проблемы, но не решают её.

Что сделал я и ИИ ): Собрал Contextor — локальный AI-оркестратор, который решает эту проблему архитектурно, а не костылями. Главная фишка, которую нельзя пропустить Вот что делает Contextor принципиально отличным от всех остальных решений: генеративная модель (9B) ВСЕГДА работает с чистым, коротким контекстом. Она никогда не видит 50-сообщений в разговоре. Она никогда не перегружена. Она не «помнит» прошлое — она его не видит вообще. Вся долгосрочная память снаружи — в координатах, working memory, storage. Генератор получает только: Текущий system prompt (~400 токенов) Последние 3 turns (6 сообщений) Мета-координату + последнюю координату (~600 токенов) Якорные факты (имя, проект, ключевые решения) Семантически релевантные факты по текущему запросу Итого ~1200 токенов. Каждый turn. Как будто разговор только начался. Это как если бы у вас был идеальный помощник с амнезией и безупречным блокнотом. Он не помнит ничего сам — но мгновенно находит любую нужную информацию во внешней памяти. И вы общаетесь с ним так, будто у него безупречная память. Почему это работает: Модель не тратит внимание на «выуживание» из огромного контекста Нет degradation — она всегда работает в оптимальном режиме Token cost не растёт с длиной разговора Качество ответа стабильное от первого turn до тысячного Это не “summarize the old messages and feed them in”. Это архитектурно другой подход: модель stateless, память — снаружи, оркестратор — между ними. Ключевая идея простая: модель никогда не видит весь разговор. Вместо этого она видит три уровня памяти, каждый со своей ролью.

Уровень 1: Working Memory (HOT) Оперативная память. Маленькая, сфокусированная, всегда в контексте. Здесь лежат активные факты с весами важности. ~2000 токенов, ~50 фактов. Если переполняется — холодные автоматически уходят вниз. Уровень 2: Memory Storage (WARM) Долгосрочная память. Все факты, которые когда-либо были важны, но сейчас не в фокусе. Здесь же — embeddings (векторные представления), которые позволяют делать семантический поиск: «найди всё, что связано с Python и FastAPI». Когда модель нуждается в чём-то из прошлого — она это достанет. Уровень 3: Coordinates (сжатая история) А вот это — самое интересное. Каждые 8–16 сообщений Contextor делает «снимок» разговора — координату. Это компактное резюме на ~200 токенов А каждые 4 координаты маленькая модель (2B) делает мета-координату — сжатую сводку всей истории. Старые координаты уходят в архив. В итоге в prompt попадает всего ~600 токенов, но они покрывают всю историю сессии любой длины. Продолжение следует…