Возможности и ограничения ИИ

Одна операция, из которой следует всё остальное

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

Текст режется не на слова, а на токены — куски по несколько символов. Кириллица дробится мельче латиницы, поэтому одна и та же мысль по-русски занимает заметно больше токенов: русские тексты быстрее упираются в лимиты и дороже обходятся при работе через API. Отсюда же знаменитый провал с буквами — на вопрос «сколько букв „о“ в слове „обороноспособность“» ответ будет наугад, потому что модель видит куски, а не отдельные символы. Считать символы её лучше не просить или просить сделать это кодом.

Следующий токен не обязан быть самым вероятным: за разброс отвечает параметр temperature. Ноль даёт почти повторяемые ответы, значения выше — более разнообразные; диапазон и умолчания у разных API свои, их стоит посмотреть в документации. В чат-интерфейсе параметра не видно, но последствие заметно: два одинаковых запроса дают разные ответы. Один удачный прогон не доказывает, что промпт надёжен, — прогоните его два-три раза, прежде чем ставить в работу.

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

Откуда берутся выдумки

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

Зоны риска предсказуемы — вот что проверяется всегда, каким бы гладким ни был ответ:

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

Что реально снижает выдумки — принести источник самому: вставленный в запрос текст закона, кусок документации, выгрузка из вашей базы. Задача превращается из «вспомни» в «найди в этом тексте», а это модель делает надёжно. Второй рычаг — явно разрешить отказ; рабочая формулировка звучит так: «Отвечай только по тексту ниже. К каждому утверждению приводи цитату из него. Если ответа в тексте нет, напиши: нет данных». Третий — инструменты (tool use): веб-поиск, чтение файлов, запуск кода, если они вам доступны.

• точные цитаты, номера и даты документов, формулировки пунктов договора
• авторы, годы и названия статей, DOI, судебная практика
• биографии малоизвестных людей и внутренние подробности компаний
• проценты, курсы, цены и условия тарифов
• имена методов и параметров в библиотеках, флаги командной строки

Граница знаний и дата отсечки

Модель обучена на данных, собранных до определённого момента, — это дата отсечки (training cutoff). Всё, что случилось позже, ей неизвестно, пока вы сами не принесёте это в диалог. Спрашивать у модели её собственную дату отсечки бесполезно: ответ генерируется теми же вероятностями и легко промахивается на месяцы.

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

Дыру закрывают инструментами: веб-поиск, доступ к файлам и репозиториям, коннекторы по протоколу MCP (Model Context Protocol) дают читать актуальные данные вместо того, чтобы вспоминать. Но и без них работает самый надёжный приём — скопировать нужный фрагмент свежей документации прямо в запрос. Это даёт больше, чем просьба «отвечай по последней версии»: такая просьба меняет тон ответа, а не содержимое весов.

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

Рабочая память: контекстное окно

Между запросами модель не помнит ничего. Каждый раз ей заново подаётся вся переписка целиком, и «память» о начале разговора живёт ровно до тех пор, пока этот текст помещается в контекстное окно (context window) — общий бюджет токенов на инструкции, историю, приложенные файлы и сам ответ.

Окна у современных моделей большие, порядок величин — сотни тысяч токенов, но точная цифра зависит от модели и тарифа, и смотреть её надо в документации, а не спрашивать у самой модели. Отдельно ограничена длина одного ответа: в API это параметр max_tokens, а причину остановки возвращает stop_reason. Упёршись в этот предел, текст обрывается на середине фразы — и длинный код тоже. Для русского закладывайте запас: токенов на тот же объём уходит больше.

Внимание внутри окна распределяется неравномерно: начало и конец промпта учитываются лучше, чем середина, — эффект известен как lost in the middle. Практический вывод: длинный документ кладите в начало запроса, а вопрос, инструкции и критерии — в самый конец. В затянувшемся диалоге ключевые ограничения повторяйте, а не рассчитывайте, что модель держит их с двадцатого сообщения назад.

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

Почему инструкциям следуют не буквально

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

Работают положительные формулировки, а не запреты: «пиши предложениями до 15 слов» надёжнее, чем «не пиши длинно». Работает явно заданный формат — перечисленные поля JSON, колонки таблицы, «только код, без пояснений». Работают один-два примера нужного результата прямо в запросе (few-shot). Работают критерии приёмки: по чему вы поймёте, что ответ годится.

Сравните. Слабо: «напиши хороший текст про наш сервис». Сильно: «Ты пишешь блок для страницы тарифов. Аудитория — владельцы небольших интернет-магазинов. Дай три варианта заголовка до 60 знаков и абзац до 400 знаков. Не используй слова „инновационный“ и „уникальный“. Опирайся только на факты из блока ниже; если факта не хватает, поставь [уточнить]». Второй промпт длиннее в несколько раз и экономит несколько кругов правок.

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

Как проверить ответ за пару минут

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

Дальше — приёмы по типу материала:

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

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

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

Куда ставить модель, а куда нет

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

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

Рабочая схема выглядит так: вы приносите контекст и критерии, модель делает объём, вы проверяете и отвечаете за итог. Такое распределение экономит часы и не создаёт скрытого риска. Обратная схема, где модель приносит факты, а человек подписывает их не глядя, рано или поздно заканчивается разбором ошибки — и разбирать её будет человек.

Практика

Проверьте себя

Частые вопросы

Похожие уроки