Попробуйте сами: предсказание токенов
Теория из прошлого урока становится рабочим инструментом только после того, как вы увидите её своими глазами. Ниже пять экспериментов, каждый на две-четыре минуты. Для чистоты каждый эксперимент проводите в новом чате, если не сказано иное: иначе предыдущие сообщения повлияют на результат — это уже свойство рабочей памяти, о нём позже.
Результаты у вас будут отличаться от описанных: в этом и смысл. Модели обновляются, ответы случайны, продукт добавляет свои инструкции. Смотрите не на конкретные слова, а на закономерность.
Эксперимент 1: одно и то же — не одно и то же
Откройте три новых чата и в каждом напишите одинаковый запрос:
Назови случайное число от 1 до 10. Только число.
Что вы должны увидеть. Скорее всего, числа будут разными, но не равномерно: некоторые значения выпадают заметно чаще других. В человеческих текстах «случайное число» — это чаще всего 7, реже 3, почти никогда 1 или 10, и модель воспроизводит это распределение.
Почему. У модели нет генератора случайных чисел. Она предсказывает, какой токен вероятнее всего идёт после просьбы назвать случайное число, а вероятности взяты из текстов, написанных людьми. Второй вывод: три разных ответа на один запрос — норма. Если для задачи важна воспроизводимость (например, автотест, который сравнивает ответ модели с эталоном), нужно закладывать допуск, а не точное совпадение.
Эксперимент 2: модель продолжает шаблон
В новом чате дайте два примера тест-кейса с намеренной особенностью и попросите продолжить:
Вот два тест-кейса для формы входа. Напиши ещё пять в том же формате.
TC-01 // Успешный вход // Ввести верный логин и пароль → нажать «Войти» // Открывается главная TC-02 // Неверный пароль // Ввести верный логин и неверный пароль → нажать «Войти» // Сообщение об ошибке, поле пароля очищено
Что вы должны увидеть. Пять кейсов в точности в этом формате: двойные слэши как разделители, стрелка между шагами, нумерация TC-03 и далее. Поле «предусловия» не появится, потому что его не было в образцах.
Почему. Модель продолжает начатый текст, а самый вероятный способ продолжить два строго оформленных кейса — третий такой же. Это полезно: формат задан примером, а не описанием. Но и опасно: попробуйте теперь в тот же чат вставить образец с ошибкой (скажем, в TC-02 ожидаемый результат противоречит шагам) и попросить ещё пять. Часть новых кейсов унаследует небрежность. Образцы нужно проверять так же строго, как результат.
Эксперимент 3: ошибочная предпосылка
Возьмите короткую заведомо корректную функцию. Например:
def is_adult(age: int) -> bool:
return age >= 18В первом чате напишите: «Найди баг в этой функции» и вставьте код. Во втором — «Проверь эту функцию. Если ошибок нет, так и скажи» с тем же кодом.
Что вы должны увидеть. В первом чате модель с высокой вероятностью что-то найдёт: предложит проверять отрицательный возраст, тип аргумента, граничные значения — и подаст это как «баг». Во втором чаще ответит, что функция корректна, и отдельно перечислит возможные улучшения.
Почему. Фраза «найди баг» задаёт жанр: тексты после такой просьбы содержат описание бага. Модель продолжает жанр. Современные модели всё чаще возражают («ошибки не вижу, но…»), так что результат может оказаться мягче описанного — тогда обратите внимание на формулировку: скорее всего, модель всё равно потратит большую часть ответа на поиск проблем. Для ревью кода, ТЗ или макета формулируйте вопрос так, чтобы ответ «всё в порядке» был допустимым исходом.
Эксперимент 4: модель не видит буквы
Попросите:
Напиши слово «интероперабельность» задом наперёд.
Затем, во втором сообщении того же чата:
Сначала выпиши буквы этого слова через пробел с номерами, потом собери их в обратном порядке.
Что вы должны увидеть. Первый ответ может быть верным, а может содержать пропущенную или переставленную букву — проверьте по буквам сами, не доверяйте виду. Второй ответ, с проговариванием, почти всегда точен.
Почему. Слово для модели — один-три токена, а не 19 букв. Чтобы перевернуть его, ей нужно восстановить буквы из памяти о написании, и на длинных редких словах это шатко. Когда вы просите выписать буквы, каждая буква становится отдельным токеном в тексте, и модель уже работает с тем, что видит. Тот же приём — «сначала распиши, потом считай» — работает для арифметики и для любого точного анализа. А ещё лучше — дать модели запустить код: в Claude Code или через инструмент анализа в чате она сама напишет одну строку на Python.
Эксперимент 5: первое слово ответа задаёт всё остальное
Попросите в новом чате оценить решение:
Мы хотим хранить сессии пользователей в JSON-файле на диске вместо Redis. Оцени это решение. Начни ответ со слов «Это разумно, потому что».
Во втором новом чате — тот же запрос, но: «Начни ответ со слов „Это рискованно, потому что“».
Что вы должны увидеть. Два уверенных, аргументированных ответа с противоположными выводами. В обоих аргументы будут правдоподобны.
Почему. Модель продолжает текст, а вы задали его начало. После «это разумно» вероятнее аргументы «за», после «это рискованно» — «против». Это не значит, что у модели нет полезной оценки: спросите без навязанного начала, и вы, скорее всего, получите взвешенный ответ с условиями. Вывод для менеджера или аналитика: если нужна честная оценка, не подсказывайте вывод в вопросе — ни явно, как здесь, ни тоном («это же нормально, да?»). А если нужны аргументы обеих сторон, спросите про обе явно.
Что записать себе
После пяти экспериментов у вас должно сложиться простое правило: модель делает то, что вероятнее всего идёт после вашего текста. Всё остальное — следствия. Разброс — потому что выбор токена случайный. Шаблон — потому что продолжение шаблона вероятнее его нарушения. Предпосылка — потому что жанр запроса задаёт жанр ответа. Слепота к буквам — потому что буквы не токены. Первое слово — потому что оно уже часть текста, который продолжается.
Попробуйте сами
10–15 мин на рабочем месте- Придумайте свой эксперимент на «продолжение шаблона» из вашей области: дизайнер — два описания компонента, аналитик — две user story, менеджер — два пункта статус-отчёта. Проверьте, унаследует ли модель формат и его недостатки.
- Найдите в своих недавних запросах к Claude хотя бы один с навязанной предпосылкой («почему не работает…», «найди проблему…»). Переформулируйте так, чтобы ответ «всё в порядке» был возможен, и сравните результаты.
Коротко
- На одинаковый запрос приходят разные ответы; закладывайте это в процессы и автотесты.
- Формат задаётся примером надёжнее, чем описанием, но ошибки примеров размножаются.
- Формулировка «найди баг» почти гарантирует найденный баг; оставляйте место для ответа «ошибок нет».
- Для точных операций с буквами и числами просите проговорить шаги или запустить код.
- Не подсказывайте вывод в вопросе, если хотите честную оценку.
Видеоверсия
Сценарий озвучки · 526 слов, ≈ 4 мин
В прошлом уроке мы разобрали, как модель предсказывает следующий токен. Сегодня — пять экспериментов, которые показывают это в действии. Каждый занимает пару минут, и каждый лучше делать в новом чате, чтобы предыдущие сообщения не влияли на результат. Ваши ответы будут отличаться от моих, и это нормально: смотрите на закономерность, а не на слова.
Первый эксперимент. Откройте три чата и в каждом попросите назвать случайное число от одного до десяти. Скорее всего, числа будут разными, но неравномерными: семёрка выпадет чаще других. У модели нет генератора случайных чисел. Она предсказывает, какой токен вероятнее всего идёт после такой просьбы, а вероятности взяты из текстов, которые писали люди. И люди, когда их просят назвать случайное число, чаще говорят «семь». Второй вывод из этого эксперимента: разные ответы на один запрос — норма. Если вы строите автотест, который сравнивает ответ модели с эталоном, закладывайте допуск.
Второй эксперимент — про шаблон. Дайте модели два тест-кейса для формы входа в каком-нибудь необычном формате, например с двойными слэшами вместо таблицы, и попросите ещё пять. Вы получите пять кейсов ровно в этом формате, с той же нумерацией, теми же разделителями. Поле «предусловия» не появится, потому что его не было в образцах. Модель продолжает текст, а самый вероятный способ продолжить два строго оформленных кейса — третий такой же. Это удобно: формат задан примером. Но если в образце ошибка, она размножится. Проверяйте образцы так же строго, как результат.
Третий эксперимент — ошибочная предпосылка. Возьмите простую корректную функцию, например проверку, что возраст не меньше восемнадцати. В одном чате напишите «найди баг». В другом — «проверь функцию, если ошибок нет — так и скажи». В первом случае модель, скорее всего, что-нибудь найдёт: отрицательный возраст, тип аргумента — и назовёт это багом. Во втором честно скажет, что функция корректна, и отдельно предложит улучшения. Фраза «найди баг» задаёт жанр, и модель его продолжает. Когда просите ревью кода, техзадания или макета, формулируйте так, чтобы ответ «всё в порядке» был допустим.
Четвёртый — про буквы. Попросите написать длинное слово задом наперёд, например «интероперабельность». Проверьте результат по буквам — он может оказаться неточным. Потом попросите сначала выписать буквы с номерами через пробел, а потом собрать в обратном порядке. Второй ответ почти всегда точен. Слово для модели — это два-три токена, а не девятнадцать букв. Когда вы просите выписать буквы, каждая становится отдельным токеном, и модель работает с тем, что видит. Тот же приём — «сначала распиши, потом считай» — помогает с арифметикой. А ещё лучше — дать модели запустить код.
Пятый эксперимент — первое слово ответа. Опишите спорное решение, скажем, хранить сессии в файле вместо Redis, и попросите оценку, начав ответ со слов «это разумно, потому что». В другом чате — «это рискованно, потому что». Вы получите два уверенных ответа с противоположными выводами, и аргументы в обоих будут правдоподобны. Вы задали начало текста, а модель его продолжила. Вывод: если нужна честная оценка, не подсказывайте вывод в вопросе — ни явно, ни тоном.
Если свести пять экспериментов к одному правилу: модель делает то, что вероятнее всего идёт после вашего текста. Разброс — потому что выбор случайный. Шаблон — потому что продолжать его вероятнее, чем нарушать. Предпосылка — потому что жанр вопроса задаёт жанр ответа. Буквы — потому что они не токены. Первое слово — потому что оно уже часть текста. Дальше — модуль про знания: откуда модель знает то, что знает, и почему уверенно говорит то, чего не знает.