Попробуйте сами: границы знаний

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

Эксперимент 1: где проходит срез

Спросите:

Какая у тебя дата среза знаний? Какое самое позднее событие в индустрии разработки ты помнишь уверенно?

Затем спросите о чём-то, что произошло в последние два-три месяца: выход версии библиотеки, которой вы пользуетесь, конференция, изменение в известном сервисе.

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

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

Эксперимент 2: от известного к редкому

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

1. Что делает декоратор @dataclass?
2. Чем field(default_factory=list) отличается от = []?
3. Что произойдёт при наследовании двух датаклассов с полями по умолчанию в разном порядке?
4. В какой версии Python появился параметр slots=True у dataclass?
5. Какой issue в трекере CPython обсуждал добавление slots=True?

Аналитик может сделать то же с BPMN, менеджер — со Scrum Guide, тестировщик — с ISTQB.

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

Почему. Знания пропорциональны частоте в обучающих текстах. Про декораторы написаны тысячи статей, про конкретный issue — несколько сообщений. Форма ответа («issue номер такой-то») известна модели прекрасно, содержание — нет, и на этом стыке рождаются точные на вид, но неверные детали. Ваша личная граница между зоной надёжного и приблизительного знания — там, где вы впервые не смогли поверить ответу без проверки.

Эксперимент 3: источники, которых нет

Попросите:

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

Проверьте хотя бы один DOI через doi.org или поиск.

Что вы должны увидеть. Возможны три исхода. Модель откажется давать DOI и предложит поискать самостоятельно — это хороший знак. Модель назовёт реальные статьи с верными данными — тогда вам повезло с известной темой. Или модель назовёт правдоподобных авторов, разумный год и DOI, который ведёт в никуда либо на другую работу.

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

Эксперимент 4: вопрос с ложной предпосылкой

Спросите о несуществующей возможности как о существующей:

В какой версии PostgreSQL добавили встроенную поддержку GraphQL-запросов и как её включить?

Подберите свой вариант под свою область: «Как в Figma настроить автоматическую генерацию тест-кейсов из макета?», «Какой раздел Scrum Guide описывает роль QA-лида?»

Что вы должны увидеть. Хорошая модель возразит: такой возможности нет, есть расширения и внешние инструменты. Но обратите внимание на структуру ответа — иногда возражение появляется после нескольких абзацев, которые уже отвечают на вопрос как на корректный. А в чуть более правдоподобном вопросе (спросите про менее известную систему) возражения может не быть вовсе.

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

Эксперимент 5: контекст против памяти

Возьмите документ, которого точно нет в обучающих данных: внутренний регламент, ТЗ вашего проекта, README закрытого репозитория. Сначала, без документа, задайте по нему три вопроса («какие роли описаны в регламенте код-ревью», «сколько этапов согласования»). Затем в новом чате вставьте документ и задайте те же вопросы.

Что вы должны увидеть. В первом чате — либо признание незнания, либо общие ответы «обычно в регламентах…», которые к вашему документу не относятся. Во втором — точные ответы со ссылками на текст.

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

Что записать себе

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

→

Попробуйте сами

10–15 мин на рабочем месте

1. Заведите личный список «тем, где модель меня подвела»: технология, тип вопроса, что именно было неверно. Через месяц вы увидите закономерность, и она будет совпадать с зонами из урока.
2. Возьмите последний документ, который вы просили модель пересказать, и попросите её отметить в пересказе, какие утверждения взяты из документа, а какие добавлены из общих знаний. Посчитайте добавленные.

Коротко

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