Модель vs Контекст

В работе с LLM я всё чаще прихожу к довольно простому выводу: самая сильная модель не обязательно даёт самый сильный результат.

На одном из моих проектов я постепенно обложил систему документацией, архитектурными правилами, примерами, ограничениями и описанием того, как разные части приложения должны взаимодействовать. И в какой-то момент обнаружил, что для большого класса задач вполне недорогой модели уже хватает. Более мощная модель, конечно, способна сделать больше, но прирост качества от смены модели оказался не таким большим, как прирост от качества контекста, в котором она работает.

Модель сама по себе — это только часть системы. Результат зависит ещё и от того, какую информацию ей дали, какие правила задали, какие ограничения существуют и насколько хорошо этот контекст соответствует конкретной задаче.

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

Например, в судебном процессе есть арбитр — судья. Перед ним оказываются две стороны, каждая из которых формирует свою картину дела. Защита и обвинение не просто выкладывают набор фактов: они отбирают обстоятельства, связывают их между собой, расставляют акценты и пытаются сформировать у арбитра определённый контекст, на основании которого будет принято решение.

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

Получается довольно любопытная конструкция: несколько моделей работают с одним делом, но каждая получает свою часть контекста и пытается повлиять на итоговую картину.

Именно поэтому в юридических AI-системах мне кажется гораздо интереснее не просто дать модели доступ к тексту дела, а построить вокруг неё специализированную среду: определить её роль, дать нужные источники, нормы права, факты, историю процесса и ограничения, в которых она должна работать.

По сути, мы делаем то же, что и хороший инженер при проектировании сложной системы: не просто выбираем более мощный компонент, а создаём для него условия, в которых его возможности действительно раскрываются.