Интересные мысли по работе с ЛЛМ здесь

Интересные мысли по работе с ЛЛМ здесь

Краткие выжимки:

1. Контекст — главный ресурс, не модель

Модель статична и без памяти, единственное, чем вы управляете, — какие токены попадают в окно контекста и в какой последовательности.

Плохие/лишние токены ухудшают траекторию диалога: если история диалога — «ошибся → ругань → снова ошибка», модель статистически продолжает этот паттерн.

Нужно оптимизировать контекст по четырём осям: корректность, полнота, размер и «траектория» (как развивается диалог).

Принцип для работы с LLM: думать не «какой промпт», а «какой набор и порядок фрагментов контекста я даю на этом шаге».

2. «Умная зона» и частая компакция

Большое окно контекста обманчиво: после ~40% заполнения качество часто падает — начинается «dumb zone».

Если пускать в окно всё подряд (логов, JSON, MCP-инструменты, длинные доки), вы почти постоянно работаете в «тупой зоне».

Решение — frequent intentional compaction: регулярно сжимать историю в краткий markdown‑конспект (файлы, строки, важные выводы) и начинать новый диалог уже с этим сжатием.

Принцип: на длинных задачах регулярно просить модель «суммировать и структурировать» достигнутое (код, гипотезы, решения) и работать дальше уже от этих сжатых артефактов, а не от бесконечной переписки.

...

4. Не аутсорсить мышление, а усиливать его

LLM не заменяет мышление, только усиливает уже проделанное или, симметрично, усиливает отсутствие мысли.

Ошибка на уровне research (неправильное понимание системы) масштабируется в сотни строк плохого кода; ошибка в плане даёт «сто плохих строк» одним махом.

Как бы всё это намекает на приоритет архитектуры перед кодингом.

Архитектуру мы как раз пытаемся зашить в СППР.

Мысль что входную информацию в ЛЛМ/контекст надо фильтровать/обрабатывать противоречит моим убеждениям

(считаю что обрабатывать не надо, потому как RAG/LLM сами по себе уже обработчики).