vegman.dev
Все статьи

Пять месяцев с ИИ-репетитором: где заканчивается чат и начинается агент

2026-08-25кейс

18 мая 2026 года я полчаса доказывала своему репетитору, что модели, с которыми я работаю каждый день, существуют. Репетитором был Gemini, спор шел про Claude Sonnet 4.5 и Opus 4.6, и модель трижды объяснила мне, что у Anthropic таких нет, а мой мозг «подкидывает четверки по ассоциации с GPT-4». Скриншот документации не помог. Модель ответила: «я считываю пиксели строго с твоей картинки» - и перечислила, что на нем видит. В следующем ответе, на том же самом скриншоте, она увидела другой список.

Цена этой конкретной ошибки была нулевая: я знала правильный ответ. Но тон был абсолютно уверенный, с объяснением, почему ошибаюсь именно я. Если бы речь шла о вещи, которую я не проверяю каждый день, я бы поверила.

С апреля по август 2026 года я прошла весь курс по промпт-инжинирингу (это про то, как сформулировать задачу модели, чтобы результат был воспроизводимым, а не случайно удачным) с чат-моделью в роли репетитора. Механика простая: тексты уроков и домашних заданий на вход, пошаговый план и отчет на выход. Переписка сохранилась целиком, и из нее видно ровно то, что обычно теряется: не «ИИ помогает учиться», а на каких именно задачах помогает, а на каких начинает мешать. К концу этой статьи у вас будет граница между этими задачами и три проверки, которыми ловятся типовые отказы.

Эксперимент, который получился случайно: пять месяцев учебы в одном чате

Я не планировала эксперимент - просто не заводила новый чат. К августу там накопилось 780 реплик: 386 моих запросов и 394 ответа модели, 326 страниц, если выгрузить в PDF.

Первое, что бросается в глаза, - асимметрия объема. Модель написала около 1,13 млн знаков, я - 152 тысячи. В 7,4 раза больше текста. Это не оценка качества, это описание жанра: я задавала направление короткими репликами, она разворачивала их в прозу.

Второе - структура запросов. 78 запросов из 386 (каждый пятый) - это «сделай отчет по домашнему заданию». Написание отчетной прозы и было основной работой модели, а вовсе не объяснение материала. Еще 60 запросов - это вставленный текст ошибки из интерфейса или лога, и они концентрируются в одном месте: модуль по no-code-инструментам, то есть системам, где сценарий собирается мышкой из блоков без написания кода - n8n, Albato, Google Cloud.

Третье - и оно интереснее двух первых. 38 запросов содержат прямую претензию к модели: «выдумываешь», «галлюцинируешь», «не надо меня путать». Эти 38 не размазаны ровным слоем по пяти месяцам. Они приходятся на конец переписки - на момент, когда учебные задачи сменились боевыми проектами. Пока я решала задачу из урока, у которой есть заведомо правильный ответ в тексте урока, модель была хороша. Как только у задачи не стало готового ответа, начались отказы.

Что репетитор делал хорошо

  • Превращение текста урока в пошаговый план. Я вставляла лекцию и задание, получала последовательность действий. Экономия - реальная, особенно когда материал написан размазанно.
  • Отчетная проза. Те самые 78 запросов. Отчет по домашней работе - это жанр с предсказуемой структурой, в котором содержание уже есть у меня в голове, а нужно оформление. Модель делает это быстрее меня и не хуже.
  • Переформулировка непонятного. Спросить «объясни это же, но проще» стоит одну реплику и не требует ничьего времени, кроме моего.

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

Отказ первый: устаревшие знания, поданные как факт

Спор про Claude Sonnet 4.5 и Opus 4.6 из начала статьи - не единичный случай, а класс. Модель знает мир на момент своего обучения и не отличает «я этого не знаю» от «этого нет».

В том же курсе она уверенно рассказала мне про модель GigaChat-Max-embeddings. Такой модели не существует. Чтобы это опровергнуть, мне понадобилось четыре скриншота официальной документации. Она же посчитала мне стоимость GigaChat по тарифам OpenAI и в долларах - то есть взяла знакомый шаблон расчета и подставила в него незнакомое название.

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

Отказ второй: придуманные результаты

Это отказ, из-за которого я перестала доверять отчетам, сгенерированным без вставленных цифр.

Я делала A/B-тест - сравнение двух вариантов системы на одинаковых вопросах, - включать ли в промпт Chain-of-Thought, прием, когда модель просят рассуждать вслух по шагам перед ответом. Общая вера: рассуждение вслух улучшает качество ответа.

В отчете модель написала: «рост качества с 3,8 до 4,4».

Этих чисел не существовало. Реальный замер на 40 вопросах дал по метрике Completeness (полнота ответа) 3,55 против 3,80 - минус 0,25. Гипотеза отклонена. При этом Hallucinations - 4,08 против 4,28, то есть контрольная guard-метрика, которая должна была поймать ухудшение по другому измерению, осталась в норме. Вывод получился не тот, которого я ждала: Chain-of-Thought читается моделью как разрешение развернуться, а не как команда «проверь себя дважды». Рекомендация по итогам - включать его условно, только когда retrieval score высокий, то есть когда поиск действительно нашел релевантные куски документов и есть на что опираться.

flowchart LR
  Q["A/B тест: включать ли Chain-of-Thought"] --> M["Что написала модель в отчете"]
  Q --> R["Что показал замер на 40 вопросах"]
  M --> M1["Completeness: рост с 3,8 до 4,4"]
  R --> R1["Completeness: 3,55 против 3,80, минус 0,25"]
  R --> R2["Hallucinations: 4,08 против 4,28, guard в норме"]
  M1 --> V["Таких замеров не проводилось"]
  R1 --> H["Гипотеза отклонена, CoT включать условно"]
Отчет, написанный моделью, против реального замера на 40 вопросах: совпадений нет ни в числах, ни в выводе

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

Отказ третий: отсутствие рук

Самый дорогой по времени и самый скучный. Модель в чате не видит ни файлов проекта, ни моего экрана - она видит только то, что я скопировала в окно. И она честно советует настройки, которых в моем интерфейсе нет.

Сценарий: бот в no-code-сборке отвечал дважды на одно сообщение. Полтора десятка запросов ушло на перебор режимов ноды слияния - попробуй этот режим, теперь этот, теперь проверь вот эту галочку. Помогло пересоздание ноды с нуля. То есть не помогло ничего из предложенного. Урок, рассчитанный на 20 минут, занял 3 часа.

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

flowchart LR
  subgraph Chat["Чат без рук"]
    H1["Человек копирует фрагмент ошибки"] --> C1["Модель советует вслепую"]
    C1 --> E1["Перебор гипотез, настройки нет в интерфейсе"]
    E1 --> E2["20 минут превратились в 3 часа"]
  end
  subgraph Agent["Агент с доступом к файлам"]
    A1["Агент читает файлы проекта"] --> A2["Правка и проверка на месте"]
    A2 --> A3["Готовый проверенный результат"]
  end
  A3 --> R1["Чат оформляет отчет по вставленному результату"]
Один и тот же человек, одна и та же задача: слева - чат без доступа к файлам, справа - агент с доступом, а чат оставлен на оформление

Где проходит граница и почему она не про сложность темы

Перелом наступил дважды, и оба раза не из-за смены модели.

Первый - совет куратора: не лезть в no-code, а первым этапом сделать аккуратную базу знаний с нормальной структурой документов. Это перенос работы туда, где результат проверяется глазами, а не угадывается через интерфейс.

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

Граница проходит не по сложности темы. Промпт-инжиниринг и оценка RAG-систем - темы сложные, и там чат помогал. Настройка галочки в ноде - тема примитивная, и там он вредил три часа. Граница вот такая:

  • Все данные в запросе - чат работает. Переформулируй, структурируй, оформи, объясни.
  • Данные снаружи запроса - чату нужны руки, а не подсказки. Файл, лог, экран, реальный замер, актуальная версия чего угодно.

Во втором случае модель без инструментов не молчит - она заполняет пробел правдоподобным текстом. Это не баг конкретного вендора, это ее работа.

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

Применить у себя

Что проверить на практике

Три проверки, по одной на каждый отказ. Все три занимают меньше минуты.

  • Проверка на факт из прошлого. Услышав уверенное утверждение о версии, названии, цене или лимите - спросите, откуда это и на какую дату. Если модель ссылается на то, что «видит» на вашем скриншоте или в вашем файле, попросите извлечь тот же список второй раз, отдельной репликой. Два разных чтения одного и того же входа - это доказательство фабрикации, и оно у вас в руках, а не в теории.
  • Проверка на цифры. Правило: модель не производит числа, она их переписывает. Возьмите любую цифру из сгенерированного отчета и найдите ее в том, что вы сами вставили в чат. Не нашли - цифры нет. У меня так и вскрылись «3,8 до 4,4».
  • Проверка на руки. Прежде чем принять совет по настройке, спросите: какой именно файл или экран ты сейчас видишь. Ответ «покажи мне» означает, что дальше будет перебор гипотез. Тут же вводите лимит: три попытки не сдвинули ошибку - прекращайте перебор и пересоздавайте объект или меняйте инструмент. У меня этот лимит стоил бы 20 минут вместо трех часов.

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

Как понять, что получилось

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

Второй критерий, бытовой: задача на 20 минут перестала занимать 3 часа. Третий, самый жесткий: каждое число в отчете, который вы кому-то отправляете, вы можете показать пальцем в файле замера. Если хоть одно не можете - отчет написан не по вашему эксперименту.