Работаю в компании «Сибинтек-Софт», занимаюсь поддержкой корпоративных информационных систем. Имею сертификат DevOps-инженера, в рамках задач отдела внедряю ИИ в рабочие процессы.
Как-то мой валидатор забраковал ответ, сославшись на статью, которой не существует. Причём отличился именно валидатор — тот компонент, который поставлен ловить галлюцинации генератора. LLM-судья — судья на большой языковой модели (large language model) — вынес вердикт «отклонить» и в поле обоснования (reason) подкрепил его несуществующей «теорией» с поддельным arXiv-идентификатором. Выглядело убедительно, и вручную я бы это, скорее всего, пропустил. Выручила проверка, добавленная когда-то на всякий случай: идентификатора нет в белом списке, а это флаг.
После этой истории я окончательно перестал верить в два популярных рецепта — «напишите промпт, чтобы модель не галлюцинировала» или «пусть вторая такая же модель перепроверит». У меня в итоге работает другое: конвейер из открытых пакетов, работающих последовательно в определенном порядке. Он неудобный, местами дорогой и может отклонить правильный код. Я считаю это нормальной ценой конструкции — и ниже покажу почему.
Примеры почти все будут про генерацию кода: там наглядней увидеть разницу между «выглядит правильно» и «работает» — код можно просто запустить. Для текстовых отчётов, ревью и других документов логика та же, меняются только конкретные судьи на шаге 4.
