Paraphrase Drift

Механика

Сжатие вынуждает выбрасывать, и первыми выбрасываются оговорки: они длинные, скучные и ослабляют вывод.

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

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

Проверка дешевле содержательной

Правильный вопрос не «правда ли это», а «не сильнее ли здесь сказано, чем в источнике».

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

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

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

Профилактика: у каждого утверждения указан класс опоры

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

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

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

Три правила рядом, каждое закрывает свой способ обмануться:

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

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

Повторный проход, находящий новое, — признак разных проверок

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

Правило не защищает своего автора

Абзац про механику был записан в базу, и в тот же день в соседней заметке (Structured Output) появилась формулировка «маска гарантирует ту часть схемы, которую понимает, а не ту, которую вы написали» — верная для уровня протокола и неверная для конечного результата, потому что официальные SDK переносят непокрытое ограничение в клиентскую валидацию. Источник говорил «removing them and validating them client-side»; в пересказе осталась первая половина, а вторая, ослабляющая вывод, исчезла.

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

Честная граница наблюдения

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

Поэтому здесь стоит утверждать направление и механику, но не соотношение. Счёт «16 находок, все в сторону усиления» — артефакт метода: искали только в одну сторону. Пока не будет прохода в обе, асимметрию считать измеренной нельзя.

Связано с

• Context Compaction — уплотнение контекста как место, где дрейф происходит в агентной системе штатно и постоянно
• Source Independence — почему пересказанное подтверждение не считается вторым подтверждением
• Overreliance — что происходит ниже по течению, когда усиленное утверждение принимают за проверенное
• LLM as Judge — судья оценивает текст, а не разницу с источником, и потому дрейф не ловит