TL;DR
Когда нужно проверить, не потерялся ли смысл при переводе или пересказе технического текста, один запрос к LLM с 6 примерами разных типов ошибок работает точнее, чем сложная система из восьми "агентов", которые по очереди переводят, извлекают структуру, сверяют и критикуют друг друга. Исследователи сравнили 6 разных архитектур — от простого сопоставления по правилам до полноценной многоагентной системы — и самый простой вариант с примерами обошёл все остальные.
Боль конкретная: при переводе технических требований смысл может "потечь" незаметно. Фраза "должен ответить за 50 миллисекунд" легко превращается в "желательно ответить за 50 микросекунд" — грамматика чистая, звучит гладко, а требование изменилось в тысячу раз и стало другой модальностью (обязательно → желательно). Обычные метрики сравнения текстов (типа BLEU) такую подмену не видят, потому что слова похожи.
Метод простой: дать модели оба текста сразу и 6 заранее подобранных примеров, которые показывают разные виды "смыслового дрифта" — перефраз без изменений, смена числа, смена полярности (не должен → должен), подмена объекта, ослабление обязательности, пропуск условия. Модель за один запрос выдаёт: есть дрифт или нет, уверенность и объяснение — без всякой многоступенчатой архитектуры.
Схема метода
ОДИН ЗАПРОС К LLM:
Вход: [текст А] + [текст Б] + [6 примеров разных типов смыслового расхождения]
Выход: дрифт есть/нет → уверенность (0-1) → объяснение какое поле изменилось
Все 6 примеров идут прямо в промпт как few-shot (примеры перед задачей). Никаких отдельных вызовов, ролей или этапов — один запрос.
Пример применения
Задача: Российская студия разработки отправила зарубежному фрилансеру техническое задание (ТЗ), переведённое на английский через переводчика. Нужно проверить, не потерялись ли критичные цифры и формулировки — сроки, лимиты, обязательность требований.
Промпт:
Сравни два технических требования — оригинал и перевод.
Определи, изменился ли технический смысл (не стиль, а именно смысл:
числа, единицы измерения, обязательность, условия).
Вот 6 примеров того, что считать расхождением, а что — нет:
1. НЕТ РАСХОЖДЕНИЯ (просто перефраз):
Оригинал: "Система должна сохранять данные каждые 5 минут"
Перевод: "Каждые 5 минут система обязана выполнять сохранение данных"
→ Дрифт: НЕТ. Смысл идентичен, изменился только порядок слов.
2. РАСХОЖДЕНИЕ (число):
Оригинал: "Отклик должен быть менее 50 мс"
Перевод: "Response should be under 50 seconds"
→ Дрифт: ДА. Единица изменена с миллисекунд на секунды — критично.
3. РАСХОЖДЕНИЕ (полярность):
Оригинал: "Функция не должна отправлять данные третьим лицам"
Перевод: "The function may send data to third parties"
→ Дрифт: ДА. "Не должна" превратилось в разрешение — противоположный смысл.
4. РАСХОЖДЕНИЕ (подмена объекта):
Оригинал: "Модуль авторизации проверяет токен пользователя"
Перевод: "The logging module validates the user token"
→ Дрифт: ДА. "Модуль авторизации" заменён на "модуль логирования".
5. РАСХОЖДЕНИЕ (ослабление обязательности):
Оригинал: "Резервное копирование обязательно выполняется ежедневно"
Перевод: "Backup is recommended to be performed daily"
→ Дрифт: ДА. "Обязательно" стало "рекомендуется" — требование ослаблено.
6. РАСХОЖДЕНИЕ (пропуск условия):
Оригинал: "При превышении лимита в 100 запросов система блокирует IP на час"
Перевод: "The system blocks the IP address for an hour"
→ Дрифт: ДА. Пропало условие "при превышении лимита в 100 запросов".
Теперь сравни эти два требования:
Оригинал: {текст на русском}
Перевод: {текст на английском}
Ответь:
1) Дрифт: ДА/НЕТ
2) Уверенность (низкая/средняя/высокая)
3) Что именно изменилось (если изменилось)
Результат: Модель выдаст короткий вердикт по трём пунктам — есть расхождение или нет, насколько уверена, и если есть — какое конкретно поле "поплыло" (число, обязательность, объект, условие). Для проверки десятков пунктов ТЗ можно прогонять этот промпт построчно.
Почему это работает
LLM плохо справляется с задачей "в лоб", если её попросить абстрактно: "есть ли разница в смысле". Модель без ориентиров склонна либо цепляться за стилистику, либо пропускать тонкие смысловые сдвиги, потому что не знает, какие именно категории изменений считать важными.
Зато LLM отлично обобщает по образцу. Если показать 6 разных типов ошибок явно — модель считывает паттерн "что считается расхождением" и применяет его к новой паре текстов, даже если конкретный случай не совпадает буквально ни с одним примером.
Многоагентные системы (перевод → извлечение структуры → сверка → критика → финальный вердикт) кажутся логичным усилением, но на практике каждый этап может внести свою ошибку, а промежуточные шаги теряют часть контекста, который был бы виден при прямом сравнении двух текстов целиком. Ошибка на одном этапе тащится дальше по цепочке — специализация агентов не окупает эту потерю.
Рычаги управления: - Количество и разнообразие примеров — если задача не про технические требования, а про, скажем, юридические формулировки или маркетинговые тексты, замени 6 примеров на свои категории расхождений (для контракта — деньги, сроки, ответственность; для маркетинга — цифры, обещания, гарантии). - Просить объяснение, а не только вердикт — заставляет модель явно указать, ЧТО изменилось, а не просто угадать "да/нет". - Не доверять цифре уверенности буквально — в исследовании модель систематически завышала уверенность в своей правоте. Лучше просить словами ("низкая/средняя/высокая"), чем числом, или явно уточнять причину сомнений.
Шаблон промпта
Сравни два текста — оригинал и {перевод/пересказ/версию}.
Определи, изменился ли смысл в критичных для меня аспектах: {что важно — цифры, обязательность, условия, объекты}.
Вот примеры того, что считать расхождением, а что нет:
1. НЕТ расхождения: [пример перефраза без потери смысла]
2. РАСХОЖДЕНИЕ ({тип 1}): [пример]
3. РАСХОЖДЕНИЕ ({тип 2}): [пример]
4. РАСХОЖДЕНИЕ ({тип 3}): [пример]
5. РАСХОЖДЕНИЕ ({тип 4}): [пример]
6. РАСХОЖДЕНИЕ ({тип 5}): [пример]
Теперь сравни:
Текст А: {оригинал}
Текст Б: {версия для проверки}
Ответь:
1) Расхождение: ДА/НЕТ
2) Уверенность: низкая/средняя/высокая
3) Что изменилось (если есть)
Подставляй в {тип 1-5} категории расхождений, важные для твоей задачи (числа, обязательность, полярность, объекты, условия — или свои, если сравниваешь не технические тексты).
🚀 Быстрый старт — вставь в чат:
Вот шаблон для проверки, не изменился ли смысл при переводе/пересказе текста.
Адаптируй под мою задачу: {опиши какие тексты сравниваешь и что важно не потерять}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие типы расхождений критичны именно для твоей задачи (юридические тексты, техническая документация, маркетинговые формулировки) — потому что без конкретных примеров под твой домен метод не сработает так же точно.
Ограничения
⚠️ Не работает на общих текстах: метод обучен через технические паттерны (числа, единицы, обязательность). На обычном тексте без чётких формальных признаков (например, литературный перевод) точность падает резко.
⚠️ Не различает направление смысла: если задача не "изменился смысл или нет", а "текст Б логически следует из текста А" — метод путается. Он хорошо видит "тексты разные", но не всегда понимает, в какую сторону разница важна.
⚠️ Число уверенности не надёжно само по себе: модель почти всегда завышает уверенность в своей правоте. Доверять голой цифре "уверенность: 92%" не стоит без дополнительной проверки.
⚠️ Для адверсариальных случаев (специально похожие, но разные по смыслу тексты) чистый few-shot немного хуже, чем подход с явным структурным разбором на составляющие — если тексты специально маскируют разницу под похожесть, помогает разложить их на компоненты перед сравнением.
Как исследовали
Исследователи создали 300 технических требований в 10 инженерных областях (от медтехники до кибербезопасности) и сгенерировали 890 вариантов с контролируемыми искажениями — намеренно испортили числа, полярность, обязательность и так далее. Затем прогнали 6 разных архитектур: от простого сопоставления по правилам до полноценной системы с восемью специализированными "агентами" (переводчик, извлекатель структуры, критик, судья и так далее).
Самый простой вариант — один запрос с 6 примерами — обошёл все остальные с большим отрывом, при этом заняв 17 минут вместо 181 для сложной альтернативы. Это удивило исследователей: ожидалось, что специализация агентов даст лучший результат, но ошибки на промежуточных этапах "накапливались" и портили финальный вердикт больше, чем помогала специализация.
Дополнительно метод проверили на двух чужих датасетах — с адверсариальными парафразами (PAWS-X) и с логическим следованием (XNLI). На адверсариальных примерах структурный разбор чуть обогнал прямое сравнение — то есть для "хитрых" похожих текстов явная разбивка на составляющие помогает. На датасете с логическим следованием все методы показали слабый результат — потому что задача там принципиально другая (направленная логика, а не взаимная эквивалентность).