Введение: Иллюзия общего языка в мире ИИ

Пока ваш тимлид в сотый раз переписывает промпт для генерации миграций, а джун пытается прикрутить нейросеть к копеечному скрипту на бэкенде (надеясь, что она сама пропатчит его легаси-код), бизнес уже ждет автономного ИИ-сотрудника к следующему понедельнику. Технологический мир переживает странный исторический момент. С одной стороны, большие языковые модели (LLM) стали неотъемлемой частью повседневной разработки, DevOps-пайплайнов и аналитики. С другой стороны, разрыв в понимании того, что именно эти модели способны делать на самом деле, стремительно увеличивается. Эту тенденцию точно описывает индустриальная метрика: «The gap in shared understanding of LLM capability is widening».

Еще недавно казалось, что у нас сформировался базовый консенсус: LLM — это продвинутые автокомплиты текста, способные писать код на Python, переводить логи и суммировать техническую документацию. Сегодня этот консенсус трещит по швам. Инженеры видят в моделях вероятностные машины с жесткими архитектурными ограничениями, продуктовые менеджеры — автономных агентов, а бизнес — волшебную таблетку для сокращения костов. Этот разрыв в восприятии порождает серьезные проблемы: от завышенных ожиданий стейкхолдеров до архитектурных провалов в продакшене. Давайте разберем анатомию этого разрыва и найдем общий язык для оценки LLM.

Анатомия разрыва: три взгляда на одну технологию

Чтобы осознать масштаб бедствия, достаточно послушать митинг, где бэкендер спорит с проджектом о сроках интеграции AI-фичи. Каждый из них буквально живет в своей мультивселенной, где законы физики кремния работают по-разному. Давайте заглянем в карты участников этого спора:

  • ML-инженеры и исследователи: смотрят на модели сквозь призму линейной алгебры, токенизации, весов внимания (attention weights) и ограничения контекстного окна. Для них LLM — это стохастический агрегат, максимизирующий вероятность следующего токена.
  • Backend-разработчики: используют LLM как внешние API-сервисы. Часто они ошибочно пытаются относиться к модели как к детерминированной функции (пытаясь заставить её работать надежнее, чем утренний кофе на сервере), получая на выходах плавающий JSON и непредсказуемое поведение при изменении промптов.
  • Бизнес-лидеры и продкт-менеджеры: под влиянием маркетинга верят в «мини-AGI». Они ставят невыполнимые задачи вроде «подключить модель к базе знаний, чтобы она полностью заменила саппорт», не понимая разницы между RAG-архитектурой и реальным рассуждением.

Технические последствия коммуникационного сбоя

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

  • Иллюзия детерминизма: попытки захардкодить логику вокруг недетерминированного выхода модели без использования инструментов структурной генерации (например, Pydantic или Guidance).
  • Игнорирование дрейфа промптов (Prompt Drift): обновление базовой модели провайдером ломает существующий пайплайн обработки данных, к чему команда оказывается не готова.
  • Неэффективный RAG: попытки решить архитектурные проблемы базы данных простым увеличением контекста модели, что ведет к деградации качества ответов («lost in the middle» феномен) и росту latency.
# Пример наивного подхода, ведущего к багам в продакшене (и к незабываемым ночным дежурствам)
response = openai.ChatCompletion.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "Верни JSON с пользователями"}]
)
# Ожидание валидного JSON без использования JSON Mode или схем
data = json.loads(response.choices[0].message.content)

Как выработать единый язык в команде

Синхронизация словаря — это не гуманитарная блажь, а жесткая инженерная необходимость, к