LLM-конспектировщики пропускают этап идентификации

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

Делиться

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

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

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

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

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

Недостающий шаг

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

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

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

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

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

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

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

Как выглядит идентификация для транскрипта

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

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

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

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

Конвейер, обеспечивающий соблюдение дисциплины.

Архитектура вытекает из каркаса. Три этапа LLM и детерминированный рендерер.

На первом этапе из стенограммы извлекаются структурированные факты. Речь идёт о репликах говорящих, явных обязательствах, явных решениях, явных количественных показателях. Этот этап намеренно консервативен. Допускается упущение некоторых моментов. Выдумывать их не разрешается.

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

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

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

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

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

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

Что производит дизайн, и что он отказывается производить.

Это не эталонный тест. Это небольшой стресс-тест на основе тестовых образцов, предназначенный для проверки того, обеспечивает ли архитектура то поведение, для которого она была разработана. Трех стенограмм недостаточно для того, чтобы делать общие заявления об обобщении LLM. Их достаточно, чтобы проверить, приводит ли конкретное проектное решение к тем последствиям, которые предполагались в проекте.

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

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

Что же произошло на самом деле? Результат, который мне кажется более интересным, — это процент воздержания.

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

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

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

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

Возражение со стороны потребителя

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

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

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

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

Обобщение модели

Архитектура переносится. Любой рабочий процесс LLM, который формирует структурированные утверждения из источника, может быть переформулирован как анализ наблюдений и дополнен слоем идентификации.

Анализ документов для целей юридического расследования. Резюмирование записей пациентов. Анализ звонков клиентов. Резюме результатов проверки кода. В настоящее время каждый из этих процессов используется как одноразовая задача генерации, при которой модель выдает структурированный результат из источника, а потребитель доверяет этому результату. Каждый из них имеет ту же самую проблему сбоя, что и программа для составления резюме совещаний, и каждый из них можно сделать более поддающимся аудиту с помощью аналогичной архитектуры: этап извлечения, консервативный в отношении того, что он извлекает из источника, этап синтеза, который создает помеченные утверждения с указателями на доказательства, и этап аудита, которому запрещено добавлять или усиливать что-либо. Реализация и профиль риска различаются в этих областях. Шаблон переносится. Специфика — нет.

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

Что это значит для людей, создающих эти системы?

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

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

Таким образом, методы, позволяющие сделать аналитические системы LLM заслуживающими доверия, могут исходить не столько из литературы LLM, сколько из дисциплин, которые уже разработали понятие честного анализа в условиях, когда источником является ограничивающее условие. Причинно-следственная связь — одна из таких дисциплин. Методология опросов — другая. Судебно-бухгалтерская экспертиза — ещё одна.

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

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

Несколько подводных камней в конце

1. Отношение к меткам как к чему-то косметическому. Если метки не соблюдаются на предыдущих этапах, они служат украшением. Их необходимо присваивать на этапе синтеза с указанием на подтверждающие данные и проверять на последующих этапах на соответствие этому указателю. Этап синтеза, который создает метку без указания на подтверждающие данные, не выполняет работу по идентификации. Он создает категорию, которая выглядит как идентификация.
2. Позволять этапу аудита быть полезным — это распространенная ошибка. Рецензент, который может добавить рекомендацию, предоставить недостающий контекст или переписать неуклюжее утверждение, чувствует себя полезным. Это также в точности тот же самый сбой, который уже есть на этапе синтеза, только замаскированный под контроль качества. Ограничьте аудит фиксированным набором ослабляющих операций. Все остальное — это спор системы самой с собой.
3. Смешивать воздержание с низким качеством. Система суммирования, которая возвращает в основном пустые разделы в ходе небольшого совещания, не является неисправной. Система суммирования, которая возвращает уверенные восемь разделов в ходе того же небольшого совещания, является неисправной, просто незаметной. Способ оценки таких систем заключается не в полноте суммирования, а в том, масштабируется ли уровень воздержания в зависимости от качества исходного сигнала.
4. Рассуждения от трех тестовых примеров к общим утверждениям. Трех стенограмм достаточно, чтобы проверить, приводит ли выбранный проект к желаемому поведению. Однако их недостаточно, чтобы делать выводы о суммировании LLM в целом. Если вы создадите свою версию этого кода, вам потребуется собственный набор тестовых примеров и собственное определение того, что считается правильным уровнем воздержания для вашего конкретного случая.

Асимметрия, которая имеет значение

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

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

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

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

Ведущий специалист по анализу данных, специализирующийся на причинно-следственном анализе, экспериментах и теории принятия решений. Я пишу о превращении неоднозначных бизнес-вопросов в готовые к принятию решения аналитические данные.

Больше подобных материалов на LinkedIn 👇

🔗 LinkedIn

Уильям Гиенг. Все работы Уильяма Гиенга.

Источник: towardsdatascience.com