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

Почему модель выдаёт ерунду

Я часто слышу одну и ту же историю: человек открыл чат, написал короткое «сделай мне стратегию», получил воду, закрыл. Через месяц повторил — снова вода. После третьей попытки появляется железный вывод: «AI не работает».

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

Обычно провал сидит в одном из трёх мест:

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

В этой части — про модели и контекст. Во второй части — про промпты как нормальное ТЗ.

Модели не одинаковые

Я не делю модели на «хорошие» и «плохие» в вакууме. Я делю их по работе, которую они тащат.

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

Gemini — сильный вариант для больших входов: длинные документы, записи встреч, видео, аудио, большие отчёты. Google открывал для Gemini 1.5 Pro контекст до 2 млн токенов для разработчиков, и это меняет класс задач: можно анализировать не кусок документа, а целый массив материалов.

“Today, we’re opening up access to the 2 million token context window on Gemini 1.5 Pro for all developers.” — Google Developers Blog

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

Perplexity — рабочая замена поиску, когда нужен быстрый ресёрч со ссылками. Я использую такие инструменты не как оракул, а как способ быстрее собрать карту источников.

Qwen / локальные модели — вариант для задач, где данные лучше не отправлять во внешний сервис: внутренние документы, черновики, персональный контекст, операционная рутина.

DeepSeek API и другие дешёвые API-модели — полезны для объёмных итераций: классификация, черновая обработка данных, массовые проверки гипотез. Там, где нужен не один идеальный ответ, а сотни недорогих прогонов.

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

Контекстное окно: память, но не совсем

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

Google в первом анонсе Gemini 1.5 объяснял масштаб длинного контекста так:

“This means 1.5 Pro can process vast amounts of information in one go — including 1 hour of video, 11 hours of audio, codebases with over 30,000 lines of code or over 700,000 words.” — Google Blog

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

Почему длинный чат деградирует

30–40 сообщений в одном чате часто уже превращают задачу в кашу. Там появляются старые версии решения, отменённые требования, случайные уточнения, эмоциональные реплики, куски, которые уже не актуальны. Модель всё это видит как часть входа.

Когда контекст переполнен, разные продукты начинают резать или сжимать историю. Что именно потерялось — вы обычно не видите. Могла исчезнуть первая важная инструкция, ограничение по формату или объяснение, почему нельзя использовать определённый источник.

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

Где это применимо в бизнесе

Подготовка к встречам. Загружаете контекст по клиенту: история переписки, прошлые решения, открытые вопросы, документы. На выходе — выжимка, риски и список того, что нужно спросить.

Документы. Договор, КП, письмо партнёру, ТЗ — модель может быстро собрать черновик, если вы дали шаблон, вводные, ограничения и желаемый формат.

Аналитика. Большой отчёт, таблица, исследование рынка, обратная связь клиентов. AI ускоряет первичную структуризацию, но выводы всё равно нужно проверять по источникам.

Прототипирование. Описали идею продукта — получили структуру MVP, риски, пользовательские сценарии и список вопросов, которые надо закрыть до разработки.

Как работать устойчиво

Мой минимум:

  • выбрать модель под тип входа: код, документы, поиск, локальные данные;
  • давать исходные материалы, а не просить «догадаться»;
  • явно писать критерии качества и формат ответа;
  • не вести все задачи в одном чате;
  • проверять факты и просить ссылки там, где речь о внешнем мире;
  • выносить повторяемые знания в RAG, базу знаний или проектную память.

Anthropic в своих документах по prompt engineering отдельно подчёркивает, что не каждую проблему стоит лечить промптом: иногда правильнее выбрать другую модель, изменить стоимость/латентность или построить оценку качества.

“Not every success criteria or failing eval is best solved by prompt engineering.” — Anthropic Claude Docs

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

Короткий вывод

AI не обязан работать от короткого запроса «сделай красиво». Он начинает работать, когда вы относитесь к нему как к рабочему инструменту: выбираете модель, даёте контекст, ограничиваете задачу и контролируете результат. Тогда это уже не игрушка, а часть операционной системы команды.