Почему «я пробовал с ИИ, всё плохо получается» — это не про ИИ

Фраза «я пробовал с ИИ, всё плохо получается» обычно описывает не качество искусственного интеллекта вообще, а один неудачный запуск конкретной системы. За словом «ИИ» в этот момент могут скрываться разные провайдеры, модели, инструменты, режимы рассуждения и наборы данных. Меняется любой из этих слоёв — и тот же самый запрос начинает вести себя иначе.

Удобнее мыслить не одной кнопкой, а цепочкой условий. Ответ формируется на пересечении технической платформы, доступного контекста и того, насколько точно определена задача. Ниже — семь переменных, которые чаще всего принимают за одну.

1. Провайдер

OpenAI, Anthropic, Google, DeepSeek и другие компании предлагают не «один и тот же ИИ под разными логотипами». У каждого провайдера собственные исследования, данные для обучения, способы донастройки моделей и продуктовые ограничения.

На практике это проявляется в разных сильных сторонах. Один сервис удобнее для кода, другой лучше удерживает длинный документ, третий увереннее работает с изображениями, четвёртый делает ставку на скорость и низкую стоимость. Кроме того, провайдер определяет доступные инструменты, лимиты, формат API и часть системных правил, которые пользователь может даже не видеть.

Поэтому сравнение «этот ИИ плохой» слишком широкое. Оно похоже на оценку всей мировой кухни после одного блюда в аэропорту: результат может быть реальным, но вывод сделан о слишком большом объекте.

2. Конкретная модель

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

У Anthropic это линейка Opus — Sonnet — Haiku, у OpenAI — старшие и mini-версии GPT и Codex, у Google — Pro и Flash. Названия здесь важны не сами по себе: разные модели отличаются тем, сколько условий они удерживают, как следуют инструкциям, насколько глубоко проверяют выводы и как часто ошибаются на длинной цепочке действий.

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

3. Harness вокруг модели

Модель почти никогда не работает в полном вакууме. Над ней есть harness — рабочая оболочка, которая связывает модель с интерфейсом, файлами, инструментами и правилами. Примеры такого слоя — Claude Code, Codex, OpenCode, Cursor и другие среды.

Harness решает, что именно модель увидит и что сможет сделать:

• какие файлы и сообщения попадут в контекст;
• какие команды, API и внешние сервисы ей разрешены;
• может ли она менять файлы или только предлагать текст;
• нужно ли ей самостоятельно запускать проверки;
• как устроены память, история и повторные шаги;
• какие системные инструкции добавляются к запросу.

Поэтому одинаковая модель в чистом чате и в агентной среде — это две разные рабочие конфигурации. В чате она чаще выдаёт ответ на основании одного сообщения. В harness она может изучить репозиторий, вызвать инструмент, увидеть ошибку, исправить решение и проверить его ещё раз. Качество здесь зависит не только от «ума» модели, но и от качества процесса вокруг неё.

4. Effort и thinking

Некоторые модели позволяют выбрать уровень усилий: low, medium, high, max. В других продуктах похожая настройка называется reasoning или thinking. Она влияет на то, сколько вычислений система готова выделить до формирования ответа.

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

Высокий effort не превращает ошибочную постановку в правильную. Если модели дали не те данные или не объяснили критерии приёмки, дополнительные вычисления лишь помогут тщательнее решать не ту задачу. Настройка усилий — один из параметров системы, а не универсальная кнопка «сделать лучше».

5. Контекст

Контекст — это не просто объём текста в окне. В него входят файлы, предыдущие решения, ограничения, примеры, определения терминов и критерии результата. Имеет значение не только наличие этих данных, но и их актуальность: старый документ или противоречивое правило способны направить ответ в неверную сторону.

В проекте контекстом становятся и служебные документы — AGENTS.md, CLAUDE.md, GEMINI.md, ссылки из них, доступные скиллы и коннекторы. Если важное правило осталось за пределами запроса, модель не знает, что его нужно учесть. Она заполнит пробел наиболее вероятным предположением.

Good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome.

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

6. Постановка задачи

Модель не может самостоятельно определить, что означает «нормально». Для одного человека это короткий текст, для другого — подробный анализ с источниками, для третьего — готовый файл, который проходит конкретную проверку.

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

Разница между расплывчатым и точным запросом выглядит так:

Сделай нормально.

и:

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

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

7. Нагрузка и доступные вычисления

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

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

Это не объяснение любой ошибки и не повод списывать всё на «серверы». Нагрузка — лишь дополнительная переменная, которую нужно учитывать, когда воспроизводимость важна: сохранять запрос, модель, режим, контекст, дату и полученный результат.

Как искать причину плохого результата

Один неудачный ответ не показывает, какой именно слой дал сбой. Для диагностики нужно менять по одной переменной и фиксировать остальные:

1. провайдера;
2. конкретную модель и её версию;
3. harness, доступные инструменты и системные инструкции;
4. effort и режим thinking;
5. состав и актуальность контекста;
6. формулировку задачи и критерии качества;
7. время, лимиты и возможную нагрузку на сервис.

После такой проверки «ИИ сделал плохо» превращается из общего впечатления в проверяемую гипотезу. Становится понятно, что менять: саму модель, оболочку, контекст или постановку задачи.

О двух слоях из этого списка есть отдельные разборы: промт-инжиниринг по правилам OpenAI и Anthropic и контекст-инжиниринг.