Знания модели: что она знает и откуда

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

Откуда знания

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

Из этого следует главное свойство знаний модели: они пропорциональны частоте. Про Python, Git, REST, Agile написано очень много, и модель знает это надёжно, вплоть до нюансов. Про маленькую библиотеку с двумя сотнями звёзд на GitHub написано мало, и знания расплывчаты. Про ваш внутренний проект, вашего клиента, ваш регламент код-ревью не написано ничего, и модель не знает об этом вовсе — пока вы не положите это в контекст.

Знания не хранятся как записи в базе. Нет места, где лежит «версия Django 5.0 вышла тогда-то». Есть множество весов, которые делают правильное продолжение вероятным. Поэтому знание может быть частичным: модель помнит, что метод есть, но путает сигнатуру; помнит, что закон принят, но не помнит год.

Дата среза

Тексты для обучения собирают до определённой даты — её называют датой среза знаний (knowledge cutoff). Всё, что случилось позже — новые версии библиотек, изменения в API, события в индустрии, — модели неизвестно. У каждой версии модели своя дата, и она указана в документации Anthropic; заучивать её не нужно, но нужно помнить, что она существует.

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

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

Галлюцинации: почему модель не молчит

Когда человек не знает ответа, он это чувствует. У модели такого механизма нет: предсказание следующего токена работает одинаково и там, где знания есть, и там, где их нет. Если спросить о несуществующей функции, самое вероятное продолжение — описание функции, потому что тексты с вопросами о функциях обычно продолжаются описаниями. Так появляется галлюцинация (hallucination): правдоподобный текст, не соответствующий действительности.

Галлюцинации не случайны. Они чаще появляются:

• на редких темах, где знаний мало, а форма ответа известна (научные статьи с авторами и годом, номера версий, точные даты);
• на стыках известного: модель знает библиотеку A и библиотеку B и «дорисовывает» способ их совместить, которого нет;
• когда вопрос предполагает ответ («в какой версии добавили X», а X не добавляли);
• когда модель уже начала уверенно отвечать — продолжать в том же тоне вероятнее, чем оборвать себя.

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

Что можно доверять, а что проверять

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

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

Знания из контекста

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

Отсюда рабочее правило: если факт можно дать, дайте. Не спрашивайте «как у нас настроен CI» — вставьте конфиг. Не просите оценить сроки «по опыту» — приложите план прошлых спринтов. Не полагайтесь на то, что модель помнит API библиотеки, — дайте страницу документации. Продукты вокруг модели именно это и делают: поиск в интернете, MCP-серверы (см. «Что такое MCP») и открытые файлы в Claude Code — всё это способы положить нужное знание в контекст, а не надеяться на веса.

Граница между двумя источниками — тема отдельного урока «Когда свойства сталкиваются»: что делает модель, когда документ противоречит тому, что она «помнит».

→

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

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

1. Спросите Claude о технологии, которую вы знаете глубоко. Задайте пять вопросов от простых к узким и отметьте, на каком уровне ответы стали расплывчатыми или неверными. Это ваша личная граница зоны надёжного знания.
2. Спросите про что-то из вашего проекта, не давая контекста («какие эндпоинты есть в нашем API заказов»). Посмотрите, признает ли модель незнание или начнёт предполагать.

Подробные эксперименты — в уроке «Попробуйте сами: границы знаний».

Коротко

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