Инструкция кричит: НЕ ПАРСИ ВРУЧНУЮ. Claude всё равно парсит вручную

Решение — не более удачный промт. Автор оборачивает модель в парсеры, сгенерированные Ragel, и даёт ей самой писать скрипты-страховки на JavaScript: в следующий раз, когда Claude потянется парсить руками, детерминированный инструмент уже сделает эту работу за неё.

Вкратце

Тезис поста: LLM — «блестящие, но неуклюжие», их непредсказуемость нужно обернуть в формальные инструменты. Ragel мгновенно выдаёт корректный парсер на 10 000 строк; Claude, которому капсом запретили парсить руками, всё равно это делает, а однажды дважды закоммитил каталог build/.

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

Модель «блестящая, но неуклюжая» между двумя слоями детерминизма

Иллюстрация: гаечный ключ и инструменты
Иллюстрация: гаечный ключ и инструменты

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

Сквозной пример: парсинг. Ragel способен выдать формально корректный парсер на 10 000 строк «мгновенно и детерминированно»; Claude, которому дали задачу для делегирования, всё равно тянется к ручному разбору строк, хотя инструкция капсом кричит: «НИКОГДА НЕ ПАРСИ РУКАМИ». Он всё равно пробует. Неуклюжесть проявляется и в вещах попроще: однажды модель дважды закоммитила каталог build/. Решение Beagle: дать Claude самому писать скрипты на JavaScript вокруг тяжёлой C-логики, а затем следить за повторами: если модель слишком часто повторяет какую-то последовательность действий, эта последовательность автоматизируется.

«Зачем мы отдаём детерминированные процессы вероятностным системам?»

Громче всего согласились, причём резче, чем сам пост.

«какого чёрта мы отдаём детерминированные процессы вероятностным системам, когда должно быть наоборот... LLM нужно выносить из процесса, как только это станет практически возможно... Иначе ты построил самый хрупкий процесс на свете, зависящий от цены токенов, враждебности вендора, геополитики и устаревания модели». — инженер, которому на прошлой работе навязали LLM

Идея из 1980-х, которой не хватало дешёвого исполнителя

Джон Нейгл поместил этот подход в более длинную историю: формальному доказательству корректности уже десятилетия, а узким местом всегда было терпение людей.

«Формальные методы, в смысле доказательства корректности, существуют уже десятилетия... По имеющимся данным, верификация seL4 заняла больше десяти человеко-лет. Идея в том, что если у тебя есть формальная спецификация того, что должно произойти, можно заставить LLM побороться с системой доказательств, чтобы добиться правильного результата. Это хорошая задача для LLM, потому что есть обратная связь от прувера».

Его оговорка стала рефреном треда: «Хотелось бы увидеть больше нетривиальных примеров этого. Люди всё время публикуют заново верификации наибольшего общего делителя или алгоритмов со стеком, а это было сделано ещё десятилетия назад».

Что пропустило эссе: а работает ли это вообще?

Самая частая претензия была не философской. Текст можно назвать сплошной завязкой без демонстрации.

«Это очень интересное вступление к посту в блоге, но... мне почему-то не хватает самого поста. Как это работает на практике? Какие есть конкретные примеры?» — читатель, который искал инструкцию к действию

«Сейчас кембрийский взрыв многообещающих ИИ-инструментов, которые вроде неплохо работают у своих авторов, но непонятно, какие из них пробовать... не хватает нам подробных обзоров продуктов?» — software-инженер на пенсии

Другие принесли недостающие примеры из собственных репозиториев. Разработчик на Elixir настроил тест так, чтобы он падал в тот же момент, когда кто-то импортирует Logger, выводя короткую лекцию о том, что вместо этого нужно отправлять события OpenTelemetry. Другой рефакторит C#, заставляя модель писать трансформацию Roslyn вместо прямого редактирования кода: неверный результат ломается громко, а не прячется незаметным багом.

А может, диагноз поставлен неверно

Самое резкое несогласие заявило, что вся рамка названа неверно.

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

А инженер из NCR лишь пожал плечами на всю эту новизну:

«Скрипты на bash в 20 строк, заменяющие целые корпоративные софтверные стеки, были мемом ещё в 90-х».

Это и есть тихое напряжение под тредом, который в основном кивает согласно. Приём, который заключается в том, чтобы обернуть модель и автоматизировать её повторяющиеся ошибки, превращается в консенсус: его поддержали и ops-ветеран, и Джон Нейгл, и любители Roslyn с Elixir. Но чего никто не предъявил, включая самого автора, так это нетривиального случая, где приём сработал бы не на игрушечном парсере или доказательстве наибольшего общего делителя. Технику канонизируют быстрее, чем демонстрируют.

Получайте такие разборы каждый день

Главные истории Hacker News — на email, в Telegram или RSS.

Следующая новость · 28 из 29 Читать дальше
🚀Tech

Блогер назвал ИИ-стенографа жутким третьим человеком за столом. HN: это секретарь

Автору сказали, что сеанс физиотерапии запишет ИИ, и он ответил, что против. Физиотерапевт кивнул и записал всё от руки, и, по мнению автора поста, если это было неловко, неловкость легла не на него.

★ 56 · 💬 87 · firesphere.dev · 4 мин