Атрибуция источников, которая сохраняется при переписывании ответа ИИ

Почему цитаты ломаются после переписывания

Большинство сбоев с цитатами начинается с очень обычного процесса. Одна модель пишет ответ. Другая переписывает его, чтобы он звучал короче, понятнее или больше соответствовал голосу бренда.

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

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

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

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

Пользователи замечают это быстро. Они видят цитату, но не понимают, что именно она доказывает. Она подтверждает всё предложение, только первое придаточное или лишь число в конце? Как только появляется такое сомнение, доверие падает.

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

Отслеживайте утверждения, а не предложения

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

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

Само утверждение держите простым и нейтральным. Сохраняйте исходную мысль, а не финальную подачу. «Выручка выросла на 18% в Q2» — это факт. «Компания показала сильный квартал с заметным ростом» — это уже стиль.

Доказательство должно быть точным. Сохраняйте поддерживающий фрагмент, ячейку таблицы, цитату или абзац. Одного названия документа мало. Если хранить только «годовой отчёт», следующая модель легко прикрепит эту цитату не к тому предложению. Точный фрагмент даёт стабильную опору на все последующие переписывания.

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

Команды, которые делают это хорошо, часто держат рядом с черновиком небольшой fact sheet. Он не должен быть сложным. Он просто даёт каждому утверждению стабильную точку опоры, чтобы атрибуция продолжала работать после изменений тона, структуры и формулировки.

Подготовьте fact sheet до переписывания

Прежде чем что-либо переписывать, разберите ответ на утверждения и положите их в простую таблицу. Достаточно обычной таблицы.

Каждая строка должна содержать только одно утверждение. Это правило важнее, чем кажется. Если в предложении сказано: «Компания запустилась в 2021 году и набрала 50 000 пользователей за первый год», разделите это на две строки. Позже вторая модель может превратить одно предложение в два, объединить два в одно или удалить половину. Одна строка на одно утверждение делает всё это безопаснее.

Полезный fact sheet обычно включает формулировку утверждения простым языком, название источника, дату источника, точный цитируемый фрагмент, который это подтверждает, и короткую заметку для проверки, если что-то вызывает сомнение.

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

Жёстко относитесь к слабой опоре. Если источник только намекает на утверждение, не оставляйте его как факт. Уберите его или перепишите как оценку или мнение, если это честно. Этот один шаг убирает много тихих ошибок ещё до того, как они расползутся дальше.

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

Десять аккуратных минут здесь могут сэкономить час правок после переписывания.

Держите факты и цитаты вместе во время переписывания

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

Начните с извлечения утверждений. Достаньте каждое фактическое заявление из первого черновика и сделайте его достаточно маленьким, чтобы его можно было проверить. «Выручка выросла на 18% в Q2» — одно утверждение. «Выручка выросла на 18% в Q2, и число тикетов поддержки снизилось» — это уже два, значит, их нужно разделить.

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

После этого дайте модели переписывания работать со стилем, но не с доказательствами. Чётко скажите, что она может сокращать, менять порядок и сглаживать текст, но должна сохранять привязку каждого ID к тому же факту. Если она делит одно предложение на два, нужный ID должен перейти в обе части, где это нужно. Если она объединяет два подтверждённых утверждения, она должна перенести вперёд оба ID.

Короткий пример хорошо показывает суть. Допустим, первый черновик говорит: «Система сократила время ответа на 32% [C021] и уменьшила облачные расходы на 18% [C022].» Модель переписывания может превратить это в: «Время ответа снизилось на 32%. Облачные расходы тоже упали на 18%.» Такое переписывание нормально только если C021 остаётся у первого предложения, а C022 — у второго.

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

Простой пример с двумя проходами модели

Команда поддержки получает вопрос от клиента: «Могу ли я отменить подписку в середине цикла, и что будет с моими данными?» У команды есть документ с политикой и точными формулировками, но они хотят отправить короткий и дружелюбный ответ, а не тяжёлый юридический текст.

Первая модель делает только одну работу. Она читает политику и извлекает утверждения с указателями на источник:

• C1: Клиенты могут отменить подписку в любое время. Источник: строки политики 12–13.
• C2: Сервис остаётся активным до конца текущего расчётного периода. Источник: строки 14–16.
• C3: Компания удаляет данные аккаунта через 30 дней после отмены, если только закон не требует хранить их дольше. Источник: строки 21–24.

На этом этапе формулировка не обязана быть красивой. Нужна только чистая связь между утверждением и источником. Если проверяющий откроет C3, он точно увидит, откуда оно взялось.

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

Финальный ответ может выглядеть так:

«Да, вы можете отменить подписку в любое время [C1]. Ваш сервис останется активным до конца текущего расчётного периода [C2]. После отмены мы удалим данные аккаунта через 30 дней, если не обязаны хранить их по юридическим причинам [C3].»

Тон изменился. Формулировка стала короче. Порядок теперь удобнее для клиента. Но каждый факт сохранил свой ID, поэтому система по-прежнему может показать нужные строки политики в панели проверки или под ответом.

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

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

Когда одно предложение превращается в два

Переписывание часто разбивает предложение на два ради ясности. Это выглядит безобидно, но цитаты, привязанные к предложениям, ломаются очень быстро.

Предложение — это всего лишь упаковка. Утверждение — это единица, которую нужно подтверждать.

Возьмём строку из fact sheet: «Команда сократила облачные расходы на 30% в Q2 и удержала uptime выше 99,9%.» В этом предложении два утверждения. Если вторая модель перепишет его как «Облачные расходы снизились на 30% в Q2. Uptime остался выше 99,9%», каждое новое предложение должно сохранить нужный ID. Не создавайте новые ID только потому, что изменилась формулировка.

Иногда одно исходное утверждение делится на два предложения. В этом случае один и тот же ID может понадобиться дважды. «Сбой длился 14 минут, потому что неудачный deploy заполнил диск» может превратиться в «Сбой длился 14 минут. Неудачный deploy заполнил диск». Если оба факта относятся к одному отчёту об инциденте и входят в одну утверждённую единицу, оба предложения должны сохранить ID этого отчёта.

Бывает и наоборот. Переписывание может объединить два подтверждённых утверждения в одну более плавную фразу. Тогда одному предложению может понадобиться два ID. Это нормально. «Выручка выросла на 12% после изменения цен, а число тикетов поддержки осталось прежним» может нести один ID из финансового отчёта и другой из панели поддержки.

Граница здесь простая: менять тон можно. Добавлять новый смысл — нельзя. «Облачные расходы снизились на 30%» подтверждается, если источник именно это и говорит. «Команда стала эффективнее» — это уже новое утверждение, если источник его не доказывает.

Именно здесь процесс либо работает, либо ломается. Если вы сопоставляете утверждения с источниками до переписывания, вторая модель может менять тон и структуру, не теряя доказательства. Если вы сопоставляете источники с предложениями, даже аккуратная правка способна всё перепутать.

Ошибки, которые ломают атрибуцию

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

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

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

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

Путаные метки тоже скрывают проблему. Если одна цитата относится к прямой цитате, пересказу того же источника и мнению автора, читатель не поймёт, что откуда взялось. Держите это раздельно. Цитатам нужен точный фрагмент. Пересказам нужна опора на источник. Мнениям цитата не нужна, если только в них нет фактического утверждения.

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

Перед публикацией проверьте несколько базовых вещей. Каждое фактическое утверждение должно указывать на источник, а не просто на абзац рядом. Переписывание не должно добавлять новых чисел, дат, имён или причин. Утверждения, зависящие от времени, всё ещё должны содержать свои даты. Цитаты, пересказы и мнение должны оставаться раздельными. И кто-то должен сравнить финальную версию с источником, а не только с первым черновиком.

Если после переписывания предложение звучит лучше, отлично. Но если цитата по-прежнему соответствует каждому факту, вот что действительно важно.

Быстрая проверка перед публикацией

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

Начните с ID. Каждое утверждение, которое сообщает факт, должно иметь свой ID, даже если читатель его никогда не увидит. Если в предложении сказано, что компания запустилась в 2021 году, сократила расходы на 18% или обслуживает 4000 пользователей, каждая часть должна иметь свой ID, указывающий на запись с фактом.

Затем сделайте короткую проверку:

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

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

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

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

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

Что делать командам, которые используют ответы ИИ

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

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

Достаточно лёгкого набора правил. Дайте каждому факту стабильный ID. Сохраните точную цитату или ячейку таблицы, которая его подтверждает. Не снимайте ID на этапах черновика, переписывания и финального форматирования. Блокируйте публикацию, если в финальном предложении нет связанного источника.

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

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

Если этот процесс важен для вашего продукта или команды поддержки, внешняя проверка может сэкономить недели проб и ошибок. Oleg Sotnikov at oleg.is работает со стартапами и небольшими компаниями над AI-first системами разработки, и такой аудит потока ответов естественно вписывается в эту работу.

Начните с десяти реальных ответов, а не с сотни. Так вы быстрее увидите точки поломки, напишете лучшие правила и получите процесс, которому команда сможет следовать и на следующей неделе.