Простые лайфхаки для локализации инвариантов Продолжение поста «Про модульность и контекстные окна LLM» Как можно хоть немного себя обезопасить и при этом сократить объем кода в контекстом окне. (Не явлется инвестиционной рекомендацией 🙂 ) ▪️ValueObject из арсенала DDD Христоматийный пример: у вас 500к строк кода, по ним (например, в 15 разных местах) разбросаны проверки на инвариант «баланс не отрицательный». Полный рефакторинг сходу, понятное дело, – дорого. Вводим ValueObject с нужным инвариантом, назовем его Money. Заменяем явные условия на ValueObject и да, инвариант все еще размазан по 15 местам, но теперь он защищен в одной точке (класс Money) и LLM может писать код, работающий с Money не видя все 15 мест. Это не решает проблему плохой архитектуры/дизайна, но радиус поражения уменьшает достаточно серьезно. (и да, можно было упростить до обычного «убрать дублирование через инкапсуляцию общей логики в отдельный класс», но я намеренно использую ValueObject, так как вокруг этой концепции есть дополнительный контекст в рамках DDD) ▪️Тесты 🤷♂️ Если инвариант размазан по нескольким системам/репозиториям, то после внесения изменений в один репозиторий, интеграционный тест может упасть и… если бы я хотел показаться больно умным, то сказал бы – __результат передается в другую LLM, она определяет какая часть инварианта нарушена, выявляет в каком репозитории оно лежит, передает контекст дальше, та правит, коммитит, код деплоится, снова запускается интеграционный тест__… но это не особо практично (пока), так что просто видим, что упало и разбираемся глазами и руками 🙂 По крайней мере нарушение не уйдет на прод. ▪️Интеграционный компонент / proxy Порывался назвать его ACL, но рука не поднялась. Смысл в том, что если у вас размазанный по нескольким компонентам распределенной системы атомарный инвариант, вы его собираете в кучу и выводите в еще один компонент (что-то вроде proxy), где проверяете его целиком. Это избыточность, это неправильно, но это, опять же лучше, чем перевести систему в рассогласованное состояние. Работает только для тех инвариантов, которые можно проверить на границах (вот тут чуть мозг не разорвался говорить о границах и нарушении границ одновременно). В общем - это чтобы рассогласованные данные не распространились по другим системам. И важно понимать, что это все следствие деградации архитектуры. Люди могут договориться, провести аналитику, перестраховаться… LLM что видит, то и видит, обнажая архитектурные проблемы, которые ранее можно было закрыть процессными заплатками и избыточной координационной нагрузкой. Теперь это становится значительно сложнее и становится серьезным блокером при желании получить преимущества от LLM в полной мере.
Простые лайфхаки для локализации инвариантов Продолжение поста «Про…
Из этого канала
- #673Значимость этой схемы сравнима с числом 42 (по универсальности) =) К слову,…
Значимость этой схемы сравнима с числом 42 (по универсальности) =) К слову, Парнас еще в 1971 описал подход к модульности через сокрытие информации как более…
- #674Резюме в разных контекстах Не совсем мой профиль, но имею что сказать :) На…
Резюме в разных контекстах Не совсем мой профиль, но имею что сказать :) На изображении хорошая рекомендация при широкой входящей воронке кандидатов.
- #675Скоро мы вместо софта будем покупать промты/openspec’и и самостоятельно сами…
Скоро мы вместо софта будем покупать промты/openspec’и и самостоятельно сами под себя писать нужный софт.
- #671Пример RLHF :) (если поощрать за любые ответы, то - что? правильно! ответ будет…
Пример RLHF :) (если поощрать за любые ответы, то - что? правильно! ответ будет всегда, даже если не корректный или не в тему) Студент сдает зоологию.
- #670Журнал «Информационные процессы» Сегодня узнал о таком электронном научном…
Журнал «Информационные процессы» Сегодня узнал о таком электронном научном журнале: http://www.jip.ru/ Кому-то точно будет интересно ✍️