llm

12 статей

Назад ко всем статьям

Seer от Sentry может читать ваши трейсы. Это не значит, что он всегда находит root cause.

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

LLM могут ранжировать предупреждения статического анализа. Они просто не могут объяснить почему.

Большие языковые модели могут помочь в триаже ложноположительных срабатываний статического анализа, но они не понимают семантику программ так, как это делает abstract interpretation. Вот как совместить оба подхода.

LLM не могут доказать корректность вашего кода, но они могут написать шаблонный код, который это делает

Верификация по методологии Cleanroom требует генерации и разрядки обязательств доказательства. Вот как LLM автоматизируют аннотации и генерацию VC, чтобы вы могли сосредоточиться на самых сложных доказательствах.

Ваш тред в Claude уже является документацией. Он просто умрёт через двенадцать часов.

Диалоги с LLM содержат намерения, отвергнутые альтернативы и работающий код. Именно это и должна представлять собой документация. Вот как превратить эфемерный чат в долговечные, доступные для поиска документы, не теряя повествования.

LLM может провести предварительную инспекцию кода. Но он не может провести собрание.

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

LLM могут генерировать код на Rust. Формальные доказательства — это совершенно другая проблема.

Большие языковые модели пишут удивительно хороший код на Rust, но когда вы просите их о формальном доказательстве, они галлюцинируют инварианты и изобретают синтаксис, который не принимает ни один верификатор. Вот что они на самом деле делают правильно, где ломаются и как их всё равно использовать.

Grammar-constrained decoding: заставляем LLMs выдавать валидный синтаксис на каждом токене

LLMs галлюцинируют синтаксис, потому что делают probabilistic sampling токенов. Grammar-constrained decoding фильтрует vocabulary на каждом шаге, так что эмитируются только те токены, которые сохраняют синтаксическую валидность.

Перевод с английского на тему — просто. Сделать его детерминированным — вот настоящая проблема.

Можно генерировать дизайн-токены из простых английских описаний, но только если рассматривать описание как DSL с ограниченным контекстом, со схемой-контрактом и снапшот-тестами.

Что делать, если мои варианты LLM не согласны? Какой из них прав?

Запуск нескольких LLM параллельно позволяет отлавливать ошибки, которые любая отдельная модель уверенно пропустит. Вот как построить систему разрешения разногласий, которая действительно работает.

Тот же LLM может написать пять версий вашей функции. Вот как сделать их по-настоящему разными.

N-version programming с LLM не требует нескольких моделей. Можно извлечь разнообразные, корректные реализации из одной модели, варьируя промпты, персоны и ограничения на рассуждения.