ИИ повсюду. Но никто не знает, будет ли он работать завтра так же, как сегодня.
ИИ захватил мир. Но есть проблема
Туристические приложения рекомендуют направления. Чат-боты обрабатывают жалобы. Ассистенты программирования пишут целые функции.
Но вот загвоздка: мы понятия не имеем, будут ли эти системы работать стабильно.
Большие языковые модели обеспечивают работу значительной части современных приложений. При этом они фундаментально непредсказуемы.
Код против черного ящика
В традиционном программировании вы точно знаете, что происходит с любыми входными данными.
Пишете функцию, которая складывает два числа? Можете проследить логику строка за строкой. Можете математически доказать, что она даст правильный ответ каждый раз без исключения.
С LLM все иначе.
Вы задаете вопрос - получаете ответ. Как модель пришла к этому ответу? Понятия не имеете.
Один запрос - два разных мира
Допустим, мы создаем туристическое приложение. Цель проста: показывать места для посещения на основе запроса пользователя.
Традиционный подход:
Разобрать запрос, извлечь ключевую информацию
Запросить базу данных с конкретными параметрами
Вернуть топ-2 результата
Все детерминировано. Если логика правильная - работает для любого запроса. Гарантированно.
Подход с LLM:
Модель читает промпт и генерирует ответ. Звучит просто. Но вот два запроса:
«Покажи мне топ-2 дождливых мест для посещения в марте»
«Покажи мне два лучших дождливых места, которые я могу посетить в марте»
Намерение идентично. Но LLM может выдать совершенно разные ответы.
Как доверять системе, которая нестабильна по своей природе?
Программисты ненавидят черные ящики
Фундаментальная проблема LLM: нет способа проверить «логику», потому что явной логики не существует.
Мы видим только вход и выход. Что происходит внутри - загадка.
С детерминированным кодом все просто. Что-то сломалось? Открываете код, находите точное место сбоя, исправляете.
С LLM этот подход не работает.
Как разработчики тестируют ИИ сегодня
Честный ответ: с помощью эвристик и надежды.
Вот что делает большинство:
Пробуют кучу возможных запросов
Вручную проверяют, что выдает LLM
Убеждаются, что результаты выглядят корректно
Надеются, что ничего не сломается для других запросов
Это похоже на бета-тестирование в традиционной разработке. Но с LLM такой подход буксует.
Порочный круг исправлений
Когда пользователь сообщает о проблеме, вы не можете найти «источник». Нет интерпретируемой логики. Непонятно, что именно пошло не так.
Что делают разработчики:
Меняют промпт и надеются, что это поможет
Тестируют снова
Проверяют, не сломалось ли что-то еще
Главный вопрос остается без ответа: как узнать, что изменение промпта исправило проблему в целом, а не просто залатало конкретный случай?
Свет в конце туннеля
Надежность LLM - большая область исследований прямо сейчас.
Над чем работают:
Понимание того, что происходит внутри моделей, для лучшей отладки
Математические фреймворки для доказательства свойств выходных данных
Ограничение моделей для генерации в определе��ных форматах
Систематические подходы к проектированию промптов
Но мы еще не там. Пока разработчики застряли с эвристическим тестированием и надеждой на лучшее.
Пока исследователи ищут решения, практики продолжают работать с тем, что есть. И лучший способ понять ограничения LLM - тестировать их самостоятельно на реальных задачах.
Делегируйте часть рутинных задач вместе с BotHub!
Для доступа к сервису не требуется VPN, и можно использовать российскую карту.
По ссылке вы можете получить 100 000 бесплатных токенов для первых задач и приступить к работе прямо се��час!
Честность - лучшая политика
Суть проблемы: детерминированный код дает логику, которую можно проверить. LLM дает черный ящик, который можно только прощупывать.
Разработчики не могут быть уверены, что исправление одной проблемы не сломает что-то другое. Не могут гарантировать, что приложение будет работать корректно для всех пользователей.
Если вы создаете что-то с LLM - будьте честны с пользователями об этих ограничениях. Это не слабость. Это зрелость.
