LLMки хуже всего при программировании справляются с поиском багов и рефакторингом архитектуры.
Понятно почему – они учились на данных, которые очень последовательны. В интернете почти нет текстов, в которых автор прям по ходу рассуждает, почему его предыдущий абзац был не верный. Наоборот, обычно каждый следующий абзац является логичным продолжением предыдущего, дополняет или усиливает его.
И еще меньше примеров забагованного кода с объяснениями, что в нем не так и как это исправить. Большая часть кода на GitHub'е либо корректная, либо с багами, про которые никто не знает 🤷♂️
Поэтому, неверные шаги в архитектуре модель обычно закрывает локальными костылями, вместо того, чтобы сделать шаг назад и сделать нормально.
———
Один из паттернов, которые я все чаще использую, чтобы все-таки искать баги не вручную – прошу модель рассуждать по шагам. Но не как обычно (Chain of Thought), когда она просто делает логические шаги.
А так, как я предлагал искать баги своим студентам – когда они в уме делают работу дебаггера и мысленно проходят по флоу исполнения программы, наблюдая за состоянием переменных.
P.s. reasoning сети (типа o1 или нашумевшей DeepSeek R1) справляются сильно лучше, потому что как раз научились делать отход от своих предыдущих размышлений (RL + вероятно, дообучение на данных с рассуждениями такого типа)
Post #280
951
Nikolay Sheyko Если можно выделить часть системы (Ринат тут про это писал) с детерминированными ожидаемыми выходами, то на эту часть можно договариваться о классических ML метриках на тестовом датасете, разметку которого заказчик вам не отдает. На вторую часть (или если…
- 👍 10
- ❤ 5