Про модульность и контекстные окна LLM Я хочу показать, что вопрос «Как увеличить контекстное окно, чтобы засунуть туда весь размазанный код?» некорректен сам по себе, а корректный вопрос звучит как: __Как локализовать инварианты в компактных Bounded Contexts, чтобы размер контекста для модификации был разумным?__ Для этого потребуется ввести термин инварианта: Инвариант – условие, которое должно оставаться истинным для всех допустимых состояний объекта/модели на протяжении всего его жизненного цикла. Если инвариант модели распределен по нескольким компонентам (C1, C2, Cn) или слоям (L1, L2, Ln) (код/база/шина), то минимальный размер контекста, необходимый для безопасной модификации, удовлетворяющий инварианту, будет >= sum(size(Ci)) + sum (size(Li)), где size включает не только код, но и схему БД, контракты и прочее. Как следствие: ▪️Если модель выделена хорошо (в bounded context), то size(инвариант) <= размер одного bounded context ▪️Если модель расползлась по всему коду, то size(инвариант) стремится к суммарному размеру всех артефактов, принимающих участие в обеспечении инварианта (и это может выходить далеко за пределы одного репозитория) Почему Bounded Context? ▪️Он обеспечивает согласованность модели и языка внутри своих границ ▪️Он является границой для инвариантов А теперь к тому, почему размер контекстного окна не спасет. Предпосылки описаны здесь: https://t.me/blog_sb/664 https://t.me/blog_sb/665 Даже если у вас контекстное окно 10M токенов ▪️Lost-in-the-middle все равно потеряет связи между компонентами ▪️LLM может модифицировать один компонент, не видя, что это нарушит часть инварианта в другом Правильное решение: не увеличивать контекст, а уменьшать размер инварианта через улучшения в архитектуре. Как один из вариантов (разумеется, не единственно-верный): ▪️Выделить Bounded Contexts (инварианты внутри контекста) ▪️Выделить Aggregate Root (инварианты внутри агрегата) ▪️Использовать Eventual Consistency между контекстами (разные BC имеют разные инварианты, координация происходит через события) Конечно, будущие поколения LLM могут лучше справляться с длинным контекстом, а для решения здесь и сейчас есть и гибридные варианты – использование RAG, кеширования контекста, его сжатие, однако у этих подходов так же есть пределы. А что же Google/и прочие, которые говорят, что уже пишут 25% и более кода через LLM? У них огромные мощности, на самом дорогом тарифе в их системах вы даже на 1% не получите тех мощностей, которыми обладают они, поэтому придется компенсировать через хорошую, модульную архитектуру 🙂