Галлюцинации ИИ — это не баг, а фича разработчика. Почему вайб-кодинг не заменит программистов

Знаете, что общего у ChatGPT, моего студенческого кода в три часа ночи и выступлений некоторых экспертов? Все они периодически галлюцинируют. Разница только в том, что от ИИ мы почему-то ждём идеальной точности, а от людей — нет.

Недавно провели стрим, где собрались специалисты, у которых ИИ не в презентациях, а в production: Сергей Спиренков (KODE), Александр Константинов (Cloud.ru), Михаил Ларкин (Сбер, ВТБ, S7), Иван Будник (ИИ-стартапы, e-commerce) и Константин Чуйков (Vibe Coding Community). Провели разговор про галлюцинации моделей и про будущее разработки с ИИ.

Контекст у меня такой: мы в «Диасофт» развиваем  Экосистему low code разработки нового поколения Digital Q и встраиваем ИИ буквально на всех этапах процесса производства: генерация тестов, написание  документации, проверка уязвимостей, генерация кода и скриптов, генерация процессов, проектирование логических диаграмм в различных вариациях и прочее. По факту сегодня уже команда из четырех человек выполняет работу пятнадцати. Звучит как магия, но на деле это результат той большой работы по оптимизации и цифровизация процесса ИТ производства

В дискуссии один из участников категорично заявил: «Модели никогда не заменят программистов, это игрушка для новичков». Другой парировал: «У нас уже production на 10 миллионов клиентов работает с ИИ». Третий предложил радикальную идею: «А давайте просто забьём на галлюцинации и подождём три месяца — модели сами станут лучше».

Ниже основные мысли — получился материал про три уровня работы с ИИ (вайб-кодинг, ИИ-ассистированная разработка и промышленный конвейер), про экономику вопроса и про то, почему галлюцинации — это не приговор, а управляемый риск.

Полную версию дискуссии можно посмотреть на видео, если хочется услышать, как эксперты спорят вживую. А после прочтения — буду рад обсудить в комментариях или в телеграм-канале Dev Q&A — там как раз формируется тусовка разработчиков, которые не верят в магию ИИ, но активно используют его в работе. Подпишитесь.

«Это игрушка для новичков»: где заканчивается магия вайб-кодинга

Есть популярное мнение: современные ИИ-модели работают лучше любого программиста — дай задание, получи идеальный результат. Достаточно описать, что нужно, и через минуту у вас готовое приложение. Но правда ли это?

Сергей Спиренков, евангелист ИИ-продуктов KODE, подходит к вопросу с позиции практика.

«ИИ сейчас — это как Excel 30 лет назад. То есть это революция в упрощении труда, которая ещё не до всех дошла. И ИИ не может быть самоцелью — это инструмент, который имеет множество применений. Я постоянно использую вайб-кодинг для исследования продуктовых гипотез, создания прототипов, небольших и средних продуктов. Он действительно позволяет закрыть примерно 90% задач, которые не требуют сложной разработки или высоконагруженных систем. То есть это подходит для проектов, которыми будете пользоваться вы сами, может быть, пара ваших друзей или десяток незнакомых людей. Желательно асинхронно, потому что иначе система рискует упасть под нагрузкой — сколько бы вы ни вкладывались в архитектуру и проектирование  Даже на одном из самых продвинутых инструментов, которым я пользуюсь (думаю, всем здесь известен V0 от Vercel — это инструмент для быстрого создания веб-прототипов), я регулярно сталкиваюсь с проблемой: модель сама генерирует код, а потом сама же не может его отладить и починить. Я трачу огромное количество токенов на то, чтобы разобраться с проблемой, и без погружения в сам код, в логику, в зависимости — иногда просто невозможно понять, что там происходит. Приходится наводить модель на решение, подсказывать ей», — делится опытом он.

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

Вайб-кодинг vs настоящая разработка: в чём разница

Пока одни эксперты говорят об ограничениях ИИ в разработке, другие уже используют его для создания production-систем. Разница — в подходе. И она принципиальная.

Александр Константинов, технический эксперт Cloud.ru считает, что проблема не в ИИ, а в том, как его используют. Для начала нужно разобраться с терминологией.

«Нужно четко ввести понятие — что такое вайб-кодинг. Андрей Карпатов, директор по ИИ в Tesla, говорил: это программирование на вибрациях, когда мы просто программируем «как чувствуем» — даём задачи на естественном языке и получаем ответ. Собственно, здесь инженерное знание не требуется. Есть и другой подход, который я не стал бы называть вайб-кодингом. Я называю это ИИ-Assisted Engineering — ИИ-ассистированная разработка. И это глубоко технический подход, в котором разработчик использует ИИ-инструмент для построения своих сервисов. На вайб-коде мы отлично можем сделать POC или MVP — proof of concept или минимально жизнеспособный продукт, протестировать гипотезы, много сил не прикладывать, может даже разработчика не привлекать. До поры до времени — до большой нагрузки или до первого серьёзного инцидента — это работает окей. Но если мы делаем что-то серьёзное — highload-систему или критичное для бизнеса решение — то здесь подход с разработкой с использованием ИИ вполне себе работает, если разработчик ставит корректный контекст. Он выбирает нужные файлы, предоставляет архитектуру, даёт полную задачу — как user stories, deliverables, прорабатывает, какие должны быть эндпоинты, какие схемы данных. Тогда риск галлюцинации практически минимальный, и решение будет хорошо работать. Здесь нюанс: нужен именно эксперт-разработчик. И риск в том, что порог входа в разработку становится выше. То есть с вайб-кодингом можно войти в разработку ПО практически без знаний, а когда мы говорим про ИИ-assisted engineering справится, я бы сказ��л, нужен архитектор или тимлид — человек высокого экспертного уровня. И если начинать с нуля, до этого уровня нужно расти лет десять, причём если писать код своими руками. Те, кто сейчас уже достаточно прокачались в разработке, у них производительность растёт в десятки раз при использовании ИИ. А те, кто только начинает, у них производительность сильно отстаёт, они ловят много галлюцинаций. Для того чтобы улучшить вайб-кодинг, я недавно рассказывал о подходе, который сам так назвал — «контролируемый кодинг». Когда мы профессионально создаём правила работы модели, прописываем все правила, делаем MCP-серверы (это Model Context Protocol — протокол для управления контекстом модели), которые хранят историю взаимодействия и четко выставляем задачи, то получаем хороший результат».

От хаоса к системе: как не дать разработчикам наступить на грабли дважды

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

Александр Сахаров, директор по партнёрствам «Диасофт», смотрит на проблему галлюцинаций через призму бизнес-процессов. 

«Галлюцинирует не только искусственный интеллект, но и аналитики, бизнес-лидеры. Иногда они придумывают всякую ерунду, которая на поверке оказывается вообще никак не связанной с реальным бизнесом. Поэтому существуют A/B-тесты, пилоты — чтобы по��учить объективную информацию. Существуют фреймворки — чтобы если ты один раз наступил на грабли, система запретила тебе наступить на них второй раз. Хотя человек, как мы знаем, очень любит наступать на грабли несколько раз подряд. Мы считаем, что искусственный интеллект — это колоссальный инструмент, колоссальное преимущество. Это примерно как если раньше собирали машину руками на конвейере, то сегодня роботы закручивают гайки, а не люди. Разумеется, робот закрутит гайку гораздо эффективнее, чем любой джун или мидл, который это делал вручную. Наша цель — не закрыться в своей песочнице, а сделать систему открытой. Мы не говорим: «Пользуйтесь только нашей моделью ИИ». Наоборот, мы делаем максимально гибкую интеграцию. Да, у нас есть и собственная модель, обученная на наших практиках — она встроена в конвейер и работает бесшовно. Но при этом ребята могут использовать open-source, разворачивать свои модели у себя или в облаках партнёров. Всё открыто — это и есть наша сила. Мы даём свободу, и именно в этом видим силу. Ведь сегодня, условно говоря, GigaChat работает отлично, а завтра — не очень. Сегодня Яндекс сделал что-то новое, а другие ещё не успели. У каждого разработчика свои предпочтения: кто-то больше любит одно, кто-то другое. Поэтому, конечно, мы разрабатываем и собственную модель — она встроена в систему и будет доступна бесплатно. Но если командам удобнее использовать внешние решения, мы, наоборот, только за.Именно в этом сила конвейера — он позволяет подключать новые механизмы. Сегодня, например, конвейер собирает Mercedes: заменили одну „руку“ — и уже полный привод, д��бавили кнопку — стал передний».

От статистики к реальности: сколько ИИ врёт на самом деле

А насколько вообще можно доверять тому, что генерирует модель? И здесь начинается игра с цифрами и методологией их подсчёта.

Михаил Ларкин, корпоративный Gen-ИИ консультант в Сбере, ВТБ, S7 делится неожиданными выводами.

«Я посмотрел статистику, какой процент галлюцинаций актуален на текущий момент. Если мы говорим про большие коммерческие модели — типа ChatGPT, Claude и тому подобных — то галлюцинации у них составляют порядка 5%. Галлюцинации у локальных open-source моделей — от 20% до 40% в зависимости от размерности и других параметров. И вот эти 5%, которые выдают большие модели, — это уже с учётом того, что в неё подали нужный контекст, подключили RAG (Retrieval-Augmented Generation — технология, когда модель получает доступ к базе знаний для уточнения ответов), ещё какие-то дополнительные инструменты сверху. И даже при этом 5–10% галлюцинаций всё ещё присутствуют. Какие ещё есть методы борьбы с галлюцинациями в рамках этих 5%? Когда мы уже дали в модель много контекста — разные репозитории, RAG, актуальные документации и всё остальное. Эти 5% всё равно присутствуют. Может, не 5%, но хотя бы 2–3% есть даже при большом контексте и хороших больших моделях с большим контекстным окном. Ну, стандартно — это, например, в Cursor есть подключение веб-поиска: когда можно на основании нашей задачи и контекста идти гуглить актуальную документацию по нужной технологии, чтобы модель не выдумывала. Плюс, как уже говорили коллеги, — Human-in-the-Loop (участие человека в процессе) или перепроверка отдельными агентами. А также, если мы говорим не про использование Cursor как инструмента, а про то, как сам Cursor и подобные инструменты подходят к созданию кода, что они внутри у себя делают, чтобы снизить процент галлюцинаций своего приложения. V0, Replit, Cursor — какие они используют подходы? Ну, по ощущениям, там 100% есть отдельные агенты, которые они сами для себя написали: агенты проверяют код, как-то его тестируют. Агенту, который написал плохой код, передают суть ошибки, какие-то дополнительные правила, промпты. То есть существует какая-то перекрёстная проверка. Туда же — актуальная документация. Ещё один интересный тезис, который я буквально недавно увидел: в августе 2024 года в Сбере — возможно, кто-то слышал, кто-то нет — изобрели, нашли какой-то ещё один способ борьбы с галлюцинациями. Когда сравнивают ответы модели в двух состояниях: когда она галлюцинирует и когда не галлюцинирует. Условно говоря, задают вопрос «Почему небо голубое?» — в одном случае она выдала галлюцинацию, в другом случае нет. И смотрят на те паттерны поведения, те характеристики внутри модели на уровне эмбеддингов (векторных представлений данных) и глубже — в чём отличие между ответами с галлюцинациями и без. И вот на этих парах примеров идёт дообучение, чтобы модель меньше галлюцинировала. Ещё один метод, ему уже, наверное, полгода — это научили модель говорить «Я не знаю» или подсвечивать уровень уверенности в тех или иных ответах. Чтобы человек, когда видел какой-то результат, понимал: «Ага, вот здесь, в этом блоке кода, она более уверена, а здесь — менее уверена». И таким образом обращать больше внимания на блоки, где уверенность пониже.

Контекст — наше всё: как правильные правила убивают галлюцинации

Александр Константинов считает, что ключ к решению проблемы галлюцинации ИИ лежит не в совершенствовании самих моделей, а в правильной организации работы с ними.

«Такие подходы, как правила разработки, очень хорошо помогают бороться с галлюцинациями, потому что галлюцинации возникают обычно там, где не хватает контекста. Мы говорили про то, что 5% галлюцинаций остается даже при идеальном контексте. Но ведь 95% тоже надо добиться — сделать хороший контекст. Во-первых, нам нужно прописать правила разработки: дать структуру проекта, дать паттерны, которые мы используем в нашем проекте, дать бизнес-контекст, описать, как правильно писать функции, как правильно именовать переменные. Если мы это не прописываем, то модель сама начинает придумывать. И она может придумать по-разному: в одном месте кода она сделала так, в другом иначе — и выглядит так, как будто писала команда из 10 джунов, и каждый по-своему. Другое дело, если мы зададим единые правила: в Cursor это Cursor Rules, если кто-то работает с open-source инструментами вроде Roo — там это Roo Code Rules. В принципе, такие механизмы есть во всех платформах. Во-первых, эти правила должен прописывать человек, хорошо разбирающийся в разработке, желательно архитектор. Он определяет, как правильно применять принципы SOLID (набор принципов проектирования в программировании) и как корректно использовать язык. И именно это уже кратно снижает количество галлюцинаций. Потом, как Константин говорил про статические анализаторы — здесь я полностью согласен. Но не обязательно проверять статическими анализаторами только вручную. Мы можем попросить модель самостоятельно запускать их. Модель же имеет доступ к консоли, и после того, как она сделала изменения, она может пойти запустить тесты, запустить сборку, запустить линтеры (инструменты статического анализа кода) и всё это сразу поправить. Не придётся самостоятельно ничего делать. Это тоже снижает галлюцинации, так как все вот эти статические инструменты направлены на то, чтобы программа компилировалась и была корректной. Кроме того, через MCP (Model Context Protocol — протокол управления контекстом модели) мы можем подключить дополнительные инструменты. Если это backend — можно с помощью curl (утилиты для выполнения HTTP-запросов) отправлять запросы и просить модель самостоятельно протестировать то, что она написала. Если это frontend — есть MCP-серверы, которые интегрируются прямо в браузер: модель пишет код, запускает его, открывает страницу, делает скриншот, анализирует результат и сразу вносит правки. Таким образом мы максимально снимаем нагрузку с разработчика и получаем наилучший результат от модели».

Зависимость от импорта: когда конвейер может остановиться

Разговор о галлюцинациях неизбежно упирается в более серьёзный вопрос: а что, если завтра доступ к западным моделям прекратится? Можно ли строить критически важные системы на инструментах, которые могут исчезнуть по геополитическим причинам?

Сергей Спиренков поднимает тему, которую многие предпочитают не замечать.

«Здесь мы говорим про LLM, которые мы используем внешние, готовые — будь то Claude, ChatGPT, Grok, всё что угодно. Но здесь всплывает следующая особенность. Если мы говорим про критически важные многомиллионные продукты — допустим, банкинг — то кто такую модель пустит в свой контур безопасности? Соответственно, мы здесь находимся в прямой зависимости от внешней модели. Мы здесь находимся в прямой зависимости от поставщика. Мы все прекрасно знаем, что случилось с возможностью приобрести даже самую элементарную западную модель сейчас на территории Российской Федерации. И что мы будем делать вот с этой зависимостью от импортных моделей? Мне кажется, что вот это на самом деле более важный вопрос — как больше работать с организацией искусственного интеллекта на собственных моделях, собственно разворачиваемых, нежели чем обсуждать галлюцинации в тех моделях, которые там общедоступны и общеизвестны. Потому что, на мой взгляд, проблема этой зависимости, проблема вот этих решений, когда мы разбираемся с собственным кодом на собственной модели, которую мы на чём-то научили, как-то мы там напильником допилили — open-source, не open-source… Чаще open-source, да. Хотя многие сейчас очень любят использовать китайскую модель DeepSeek. Ну вот, DeepSeek — и говорят, что она и по ресурсам хороша, и всячески хороша, и коробка бесплатная у неё, и всё. Всё очень здорово. Куда утекают данные? Тут очень много вопросов возникает касаемо информационной безопасности со всех сторон. И, на мой взгляд, вот как конвейер (о котором выше говорил Александр Сахаров) может работать на западных моделях — если вдруг поставка этих западных моделей прекратится, что делать-то будем?»

Open-source как альтернатива: догнали ли мы GPT-4o?

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

«Мы разворачиваем модели, и у нас большой упор на модели для разработки. Собственно, современные open-source модели, которые есть — это Qwen Coder и GLM-4 — они достаточно большие, где-то там 450–500 миллиардов параметров. Они требуют очень много ресурсов — минимум 8 GPU-карт, чтобы одну LLM запустить. Но по качеству они уже сравнялись с GPT-4o, с Claude Sonnet 4.5. Если посмотреть бенчмарки, они показывают такое же качество. При этом их можно развернуть у себя. И, собственно, сейчас я все исследования делаю на этих моделях. И качество генерации сравнимо с тем, что у меня получается в Cursor на тех же самых GPT-4o и всех остальных. Поэтому эта проблема решается: чтобы данные не утекали, можно развернуть или у себя, или арендовать сервер, или купить доступ по токенам».

Философия запасного плана: когда фура без руля — это плохая идея

Александр Сахаров смотрит на проблему зависимости от моделей под другим углом — через призму управления рисками.

«Нужно понимать, что в любом случае, условно говоря, Китай и Америка просто из-за количества разработчиков и из-за количества задач будут обгонять, например, Россию, в которой их просто в 10 раз меньше. И нужно понимать, что так или иначе, что бы там ни было на этой планете — может, и инопланетяне прилетят, какую-нибудь там модель изобретут — всегда нужно делать некоторый запас прочности — понимать, что у тебя может что-то сломаться. Вот, например, автомобили, фуры могут быть сегодня полностью электронными — ездить по GPS. И, в принципе, там не нужны ни руль, ни педали — они могут двигаться от склада к складу, и это уже не фантастика. Но проблема в том, что если вдруг сейчас спутники упадут — они ведь все встанут. А там нет ни руля, ни педалей. Мы все умрём с голода, потому что человек на фуре не сможет доехать: фура „забыла“, что, оказывается, люди раньше как-то ею управляли. Поэтому вопрос на самом деле философско-методологический: если кто-то полностью пересаживается на какую-то технологию и не имеет, скажем так, плана Б ��а случай её отказа, значит, он просто плохо управляет своими рисками. Нам всем нужно это понимать. Именно поэтому конвейер важен. Почему он играет такую роль? Потому что он позволяет отслеживать подобные ситуации.

Главный вопрос: «How much?»

Теория теорией, но любая дискуссия об ИИ в разработке упирается в экономику.  

«У меня возникает закономерный вопрос: How much? Сколько всё это вообще будет стоить? Чтобы купить определённое количество токенов… Я недавно проводил сравнительный анализ. Gemini — самая простая и самая дешёвая модель: миллион токенов обходится примерно в 20 центов. Самый мощный режим ChatGPT, если не ошибаюсь, сейчас называется Pro — там около 3 долларов за миллион токенов. 400 строк кода — это примерно 0,75 слова на токен, плюс-минус. За одну сессию можно потратить и 200, и 300 тысяч токенов», — приводит расчёты Сергей Спиренков.

«Это очень оптимистичный вариант. Потому что я делаю замеры, и на реализацию небольшой пользовательской истории обычно уходит 2–3 миллиона токенов на чтение», — уточняет Александр Константинов.

«Насколько это повлияет на конечную стоимость готового продукта? И насколько сильно скажется на экономике? Ведь, по моей информации, железо — опять же, не берусь судить, думаю — сейчас стоит недёшево, если разворачивать у себя в компании Qwen или любую другую модель. Плюс её ещё нужно сопровождать. И в итоге может оказаться, что дешевле снова нанять программистов. На мой взгляд, основной тезис в следующем: если переходить к более детальному уровню, то цена строки готового кода, написанного разработчиком уровня middle, пока выигрывает у строки кода, созданной ИИ. Вот так», — говорит Сергей Спиренков.

Ставка на будущее: а что, если просто подождать?

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

«Раньше какое-то количество результативного кода стоило — если мы использовали GPT-3.5 в 2023 году, в 2022 — оно стоило X денег. Сейчас этот же объём результативного кода на других моделях, на более классных, умных и всё такое прочее, стоит уже X делить на 1000. И через год ещё это будет X делить на миллион. То есть стоимость результативного кода и продукта сильно уменьшается. То есть за те же деньги мы получаем более сложный код. В какой-то момент мы с командой продумывали архитектуру одного из продуктов, где нужно было внедрять ИИ-модули. И столкнулись с тем, что модель просто не справлялась с контекстом и постоянно галлюцинировала. Тогда мы подумали: а что, если пока просто забить на это? Именно в текущей версии продукта можно какое-то время пожить с тем, что он галлюцинирует. Мы действительно так и сделали — сознательно закрыли глаза на факт галлюцинаций, исходя из того, что через некоторое время, судя по скорости развития технологий, их станет заметно меньше. Через один-два, максимум три месяца процент ошибок снизится, и по всем юнит-экономикам продукт уже выйдет в норму. Ресурсы, которые мы сейчас потратили бы на борьбу с галлюцинациями и другими временными проблемами, через три месяца уже потеряли бы актуальность — потому что, грубо говоря, всё и так начнёт работать нормально. Поэтому те же ресурсы логичнее направить на развитие продукта, конвейера или других задач, не зависящих от моделей. В какой-то момент я именно так и посмотрел на ситуацию: можно проектировать LLM-продукты с расчётом на будущее — исходя из того, что через какое-то время всё станет лучше. И пока не видно никаких признаков, что развитие замедлится».

«Кнех» — новая/старая реальность разработки

Проблема галлюцинаций — не уникальная особенность ИИ. Это проблема любого интеллекта, работающего с неполной информацией.

«Галлюцинирует, конечно. Раньше у нас только люди галлюцинировали, а теперь ещё и искусственный интеллект. Поэтому мы к этому морально были всегда готовы — ведь от человечес��их галлюцинаций никто не застрахован. Ещё раз повторюсь: галлюцинируют не только разработчики. Я и сам когда-то студентом «вайб»-кодил, как не в себя, — а потом утром приходил и думал: «Кто это вообще написал? Кто тот человек, который придумал всю эту ерунду? И как это вообще работает?» И, собственно, единственное, что защищает от этого — это такое скучное, очень-очень-очень скучное слово, которое мы все очень не любим, но которое правильное: методология. То есть если ты хочешь, чтобы у тебя получилось хорошо, ну, сначала рекомендуется всё-таки помыть руки, а потом этими руками есть булочку. В принципе, ты, конечно, можешь есть булочку и не помыв руки, но возможны последствия. Хотя есть шанс, что повезет. Но когда мы говорим о 10 тысячах программистов, 5 тысячах программистов, сотнях команд, которые работают в ежедневном режиме и должны создавать что-то большое, работающее — типа, например, портал Госуслуг или какие-то более сложные системы — то если кто-то один не помыл руки и заболел, это выключает целое боевое соединение и приводит к поражению в войне. Поэтому мы, конечно, ни в коем случае не против вайб-кодинга. На каждом этапе у нас подключены модели: можно писать скрипты, рисовать картинки, готовить документацию — LLM всё делает и сама себя проверяет. Ребята работают в полной свободе действий, но каждый — в своём участке процесса. Потому что если полностью отдать всё на самотёк и не контролировать этапность разработки, мы просто не сможем удерживать качество. А качество для наших продуктов — это выживание, потому что написать, создать продукт — это хорошо, ты молодец. А потом тебе нужно этот продукт сопровождать. И от тебя зависит очень часто боевая ситуация. Я знаю, что такое «кнех» — это то, что мы сейчас называем галлюцинацией. Какая-то неведомая ерунда. В наше время, когда мы программировали в 90-е и 2000-е, это и называлось „кнех“. И когда в промышленной среде что-то сбоит — ну, например, недавно падал сайт Аэрофлота — нужно быстро поднять систему, разобраться. Если никто не понимает, что там навайб-кодили и где искать, это практически нерешаемая задача. А решать её нужно за минуты — за минуты локализовать место сбоя, увидеть все юнит-тесты и логи. Причём логи должны быть организованы единым образом, а не как попало „навайб-кодили“. Только тогда инженеры могут быстро разобраться и за считанные минуты найти проблему. И если мы говорим о создании какой-нибудь курсовой работы или простого агента, который в TikTok постит посты — то вопросов нет. А если мы говорим про сложные B2B-решения, то, к сожалению, без конвейера не обойтись», — говорит Александр Сахаров.

Что почитать по теме

Если тема галлюцинаций и надёжности генеративных моделей вас зацепила, вот несколько действительно стоящих книг для разработчиков и инженеров, которые работают с LLM и AI-системами.

• Building Reliable AI Systems — практическое руководство от Manning о том, как проектировать устойчивые AI-решения, снижать количество галлюцинаций и контролировать поведение моделей.

• AI Engineering: Building Applications with Foundation Models — книга Чип Хьюен о том, как превращать большие модели в работающие продукты. Есть разделы про валидацию ответов и минимизацию ошибок генерации.

• Prompt Engineering for Generative AI: Future-Proof Inputs for Reliable AI Outputs — о том, как создавать устойчивые промты и обучать модели отвечать осмысленно, не скатываясь в фантазии.

• Software Testing with Generative AI — о тестировании и контроле качества в генеративных продуктах: как выявлять галлюцинации, неадекватные ответы и сбои в логике.

• AI Snake Oil: What Artificial Intelligence Can Do, What It Can’t, and How to Tell the Difference — критический взгляд на ИИ-хайп. Помогает понять, где заканчиваются реальные возможности технологий и начинаются иллюзии.

• The Alignment Problem: Machine Learning and Human Values — глубокая книга о том, как согласовать машинное обучение с человеческими ценностями и почему «галлюцинации» — это не просто баг, а симптом проблемы выравнивания.