Можно ли доверить ИИ разбор конфликта в команде: два эксперимента и четыре ошибки

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

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

А потом один из участников разбора прислал скриншот и сказал, что модель приписала ему то, чего он не говорил.

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

Зачем вообще отдавать это модели

Экономия времени здесь ни при чем. Аргумент в предвзятости и объеме.

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

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

С одной оговоркой. «Ей не важно, кто симпатичен» – правда про участников конфликта, но не про заказчика разбора. Модель систематически подстраивается под того, кто задает вопрос.

Исследование. Towards Understanding Sycophancy in Language Models (Sharma et al., 2023). Пять современных ассистентов на четырех разных задачах стабильно подыгрывают взглядам собеседника; и люди, и модели-оценщики заметную долю времени предпочитают убедительный угодливый ответ правильному. Для нас это значит: разбор заказывал администратор, он же формулировал три вопроса – и модель могла подстроиться под его рамку, а не под лог. Лечится нейтральным промптом без оценок.

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

Что модель нашла лучше человека

Три находки стоят того, чтобы их выписать отдельно от истории.

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

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

Разделение формы и содержания. По существу правой в первом конфликте была та сторона, которая вела себя хуже: у нее была методика, 1 000 референсных фраз, носители языка и цифра 74%. Модель это зафиксировала и предложила формулу, которая и есть главный практический вывод обоих разборов:

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

Рамочный вопрос. И самый полезный артефакт – переформулировка самой задачи:

Кто перевел разговор в состояние, где плохое поведение стало единственным доступным следующим ходом?

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

Аудит: четыре ошибки, которые нашлись при сверке

Претензия участника звучала так:

В этот раз у тебя модель как-то перепутала все. Андрею приписало много из того что он не говорил.

И следом:

Это хороший пример, когда модель пишет много, убедительно, но шизу.

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

Обратите внимание на первую строку. Это не галлюцинация: числа 161 и 77 существуют, они посчитаны правильно. Сломалось предложение вокруг них – окно эпизода названо сутками. Самый убедительный факт в отчете и самый неверный вывод из него – это одно и то же место.

У этой ошибки есть точное имя в литературе.

Исследование. On Faithfulness and Factuality in Abstractive Summarization (Maynez, Narayan, Bohnet, McDonald; ACL 2020). Авторы разделили ошибки суммаризации на два класса: faithfulness – утверждение не подтверждается исходным текстом, и factuality – утверждение ложно о мире. И показали, что нейросуммаризаторы массово галлюцинируют именно первое. Для нас это значит: строка про 94% – классическая ошибка faithfulness. Числа настоящие, они в логе есть, но рамка «за день» источником не подтверждена. Это не «модель выдумала факт», а «модель неправильно оформила факт». И чинится это по-разному: фактчек чисел не поможет, нужна сверка рамок и знаменателей.

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

Почему ошибки оказались не случайными

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

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

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

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

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

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

У длинного входа есть известная слабость.

Исследование. Lost in the Middle: How Language Models Use Long Contexts (Liu et al., TACL 2023). Модели неравномерно используют длинный контекст: лучше всего вспоминают начало и конец входа, заметно хуже – середину, даже в моделях, заявленных как длинноконтекстные. Применительно к нашему логу на 240 сообщений: середина – это ровно там, где две ветки переплетались, а ответы уходили через десять реплик. Ошибки атрибуции в таком месте ожидаемы, а не случайны.

Ловушка «суть верна, детали неверны»

Самый честный момент истории – ответ администратора на претензию:

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

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

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

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

Кстати, у истории есть рекурсивная ирония, ради которой ее стоит помнить целиком. Первый конфликт вырос из вопроса «ты это тестировал или просто веришь?». Неделя закончилась публикацией разбора, который не был протестирован.

Что с этим делать: протокол на шесть шагов

Развязка – не в том, чтобы отказаться от модели, и не в том, чтобы поднять усилие рассуждения. Усилие, кстати, обсуждали: разбор делали на среднем, и на максимальном он был бы точнее. Но точнее – это не то же самое, что проверено. И это не скепсис на ровном месте.

Исследование. Large Language Models Cannot Self-Correct Reasoning Yet (Huang et al., ICLR 2024). Модель не может надежно исправить собственный ответ без внешней обратной связи: «внутренняя самокоррекция» – перечитать и поправить себя без новых данных – часто не помогает, а иногда и ухудшает результат. Для нас это значит: максимальное усилие рассуждения не заменяет сверку. Атрибуционную ошибку модель сама не увидит – ее увидит только сверка с логом. «Точнее» и «проверено» – это разные вещи.

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

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

  Исследование. Chain-of-Verification Reduces Hallucination in Large Language Models (Dhuliawala et al., 2023). Модель пишет черновик, затем отдельно планирует проверочные вопросы и отвечает на них независимо от черновика – чтобы не подыгрывать себе, – и только потом собирает финальный текст; галлюцинаций становится меньше. Для нас это значит: дознание и приговор должны быть разными прогонами именно потому, что проверка, сделанная поверх готового вывода, ему подыгрывает. Близкая идея – Decomposed Prompting (Khot et al., ICLR 2023): сложную задачу разбивают на подзадачи с отдельными промптами, и каждая решается лучше, чем одна монолитная. Извлечение фактов и оценка – ровно такие разные подзадачи.

• Идентификатор на каждую цитату. Утверждение без ссылки на конкретное сообщение в отчет не попадает. И проверяйте идентификатор кодом, а не глазами: сообщение существует, текст реплики совпадает с цитатой. Это дешевле любой сверки: непроверяемые фразы просто не рождаются, а выдуманные – не проходят.

  Исследование. Enabling Large Language Models to Generate Text with Citations (Gao, Yen, Yu, Chen; EMNLP 2023). Первый крупный бенчмарк генерации с цитатами (ALCE): даже лучшие модели до половины времени дают ответ без полной поддержки цитатами. То есть «идентификатор на каждую цитату» – это защита, а не бюрократия. Без привязки к сообщению модель легко приписывает реплику не тому – и может выдать несуществующий идентификатор, поэтому проверяет его код.

• Агрегаты – из базы, не из модели. Сколько сообщений, у кого, в каком окне – это SQL, а не модель. И называйте окно в самом отчете: «06:30–08:40», а не «за день». Половина спора о цифрах – это спор о знаменателе.

  Исследование. Tokenization counts: the impact of tokenization on arithmetic in frontier LLMs (Singh, Strouse; 2024). Числовые рассуждения модели зависят от того, как числа разбиты на токены; ошибки при этом систематические, а не «примерные». Для нас это значит: считать сообщения, доли и окна должна база данных, а не модель. Цифры в отчете – из SQL, модель их только пересказывает.

• Проверка несущих фактов. Спросите себя: если убрать это утверждение, вывод изменится? Если да – сверяйте вручную. Проверить три несущие цитаты полезнее, чем двадцать случайных.

  Исследование. FActScore: Fine-grained Atomic Evaluation of Factual Precision (Min et al., EMNLP 2023). Текст разбивают на атомарные факты и считают долю подтвержденных надежным источником; так, ChatGPT в биографиях фактуален лишь на 58%. Для нас это значит: разбор надо раскладывать на атомы и проверять те, на которых держится вывод, – это и есть «несущие факты». Дешевле полной сверки, полезнее случайной.

• Черновик – участникам до публикации. Ровно те люди, о которых написано, найдут ошибку атрибуции за минуту и бесплатно. Именно так она и нашлась здесь – только после публикации. Оговорка: участники – заинтересованные лица и оспорят не только неверное, но и неудобное. Такой просмотр ловит фактические ошибки, но не заменяет решения о выводах.

• Роль модели – дознаватель, не судья. Механизм – ее сильная сторона: как спор стал статусным, где точка невозврата, почему замечание не сработало. Оценки людей и меры оставьте себе: это ответственность, которую нельзя делегировать тексту.

  Исследование. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., NeurIPS 2023). Модели-судьи соглашаются с людьми примерно в 80% случаев – на уровне человеческого согласия, – но имеют систематические смещения: позиция (кто отвечал первым), многословность (длиннее кажется лучше), предпочтение собственных ответов. То есть «модель рассудила» – не нейтральный вердикт. Механизм модель опишет хорошо, а взвешивать людей и назначать меры должен человек.

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

Где это выстрелит еще

Модерация чата – редкая задача. А вот класс задач – частый, и он у вас точно есть. Таблица ниже – гипотеза, перенос одного кейса на соседние задачи, а не измеренные риски. Но класс поломок в ней один и тот же: атрибуция.

Общее правило простое. Чем ближе задача к описанию механизма, тем надежнее модель. Чем ближе к суждению о человеке, тем дороже каждая непроверенная строка – и тем меньше стоит формула «суть верна, детали неверны».

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

А кто что сказал – проверяйте сами. Особенно если собираетесь это опубликовать.

Что из этого следует для Падавана

У сообщества уже есть бот – Падаван: анонимные вопросы, пасты, поиск по архиву. Он админ в чате и видит каждое сообщение. Протокол читается как ТЗ на его новую роль, и роль эта – дознаватель.

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

Модель при этом не читает поток: разбирать каждое сообщение – дорого. Работает порог. Падаван считает темп запросом к буферу – сколько сообщений за окно дали одни и те же участники, – и пока темп обычный, не происходит ничего. Порог пройден – появляется эпизод: окно сообщений, и вот его модель разбирает целиком. Триггер считается в базе, по правилу протокола: числа – из SQL, без модели.

Что модель ищет внутри эпизода – подсказывают сами разборы:

• эпистемический триггер: тезис, за которым попросили пруфы и получили «это же очевидно»;
• переплетенные ветки, где ответ прилетает через десять реплик;
• первое оскорбление – точка, после которой форма сломана;
• реплика нейтрального третьего – по обоим разборам самое дорогое свидетельство.

Алерты идут только в админский чат. Ни в общий, ни «ради прозрачности»: опубликованная ошибка атрибуции становится памятью сообщества, и один раз так уже было. Карточка собирается по протоколу: каждая цитата со ссылкой на сообщение, окно названо явно – «06:30–08:40», а не «за день», – точка невозврата помечена как кандидат, а не как факт.

Реакции – три уровня, и выше первого бот без команды не идет:

1. Маркеры копятся молча. Это данные, а не событие.
2. Порог пройден – модель разбирает эпизод, и в админском чате появляется карточка с таймлайном. Админ решает, был конфликт или показалось.
3. Действие только по кнопке: адресное напоминание правила, черновик мьюта, запрос разбора. Автоматических санкций нет: мьют – оценка человека, а оценки остаются у людей.

Команда /razbor – тот же протокол одним действием: два прогона, нейтральный промпт, черновик в админском чате, публикация только после сверки и только кнопкой человека. Здесь есть техническая деталь: бот не умеет читать историю чата задним числом, он видит только то, что приходит при нем. Так что буфер сообщений – не опция, а условие: последние несколько дней живут в базе, и /razbor работает внутри этого окна.

И то, что у бота получается без самообмана: мерить саму модерацию. Общее «не сворачивайте туда» в обоих разборах не изменило ничего. Падаван считает темп до вмешательства и после – и у админа появляется обратная связь, сработало замечание или нет.

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

Чего Падаван не делает никогда: не публикует разборы сам, не называет виноватых в общем чате, не мьютит без кнопки и не выдает «кто начал» без ссылок на сообщения. Модель собирает механизм конфликта, решения по людям остаются за админом.

Вы бы отдали модели разбор конфликта в своей команде – и на каком шаге у вас стоит проверка, прежде чем ее вывод станет чьей-то характеристикой?