TL;DR
Исследование показывает, что бывает, когда LLM получает готовый ответ от специализированного инструмента (классификатора, скоринга, детектора) и должна выдать итог, сопоставив его со своим чтением данных. Схема простая: модель сначала решает кейс сама, потом решает его же с подсказкой инструмента. Затем итог сравнивают с каждым источником отдельно.
Главная находка неприятная. Подсказка инструмента улучшает LLM, поэтому кажется, что всё работает. Но итог всё равно хуже самого инструмента. Основная потеря не в том, что модель верит неверным подсказкам, это случается редко. Она не принимает верные поправки: в упрямстве и пропуске правильных подсказок ошибок было заметно больше, чем в слепой вере. Поэтому «LLM + инструмент» оказывается слабее «просто инструмента», хотя в сравнении с LLM без помощи выглядит победителем.
Практический вывод из статьи один: сравнивай связку не только с LLM без подсказки, но и с сильнейшим отдельным компонентом. Второй вывод: вместо просьбы «не доверяй слепо» лучше давать модели конкретные, привязанные к задаче данные (что значит каждый признак, какие признаки указывают на какой класс). Это снижало число случаев, когда неверная подсказка перебивала верный ответ. А повышение «усилия рассуждения» и прямая инструкция арбитража проблему не решили.
Схема метода
Это протокол проверки, а не техника генерации. Шаги идут отдельными запросами, тексты кейса везде одинаковые:
ШАГ 1: Кейс без подсказки → метка LLM (A)
ШАГ 2: Тот же запрос ещё раз, ничего не меняя → метка LLM (A′)
(показывает, как часто модель сама меняет ответ без причины)
ШАГ 3: Тот же кейс + одна строка «внешний инструмент считает: X» → метка (B)
ШАГ 4: Сравнить точность: A, инструмент отдельно, B
Смотреть: B лучше A? B лучше инструмента?
ШАГ 5: Разобрать ошибки B: «не принял верную подсказку» или «принял неверную»
Пример применения
Задача: Вы руководите поддержкой маркетплейса. Классификатор тикетов (обычная модель, обученная на истории) ставит категорию: «возврат», «доставка», «брак», «мошенничество». Вы хотите добавить LLM, которая читает текст обращения и «подтверждает или поправляет» метку. Хочется понять, не стало ли хуже.
Промпт для шага 3 (с подсказкой, с предметными признаками):
Ты разбираешь обращения покупателей в поддержку маркетплейса.
Выбери одну категорию из списка: возврат, доставка, брак, мошенничество.
Справка по признакам:
- «Возврат»: покупатель просит вернуть деньги или товар без претензий к качеству.
Типичные маркеры: «передумал», «не подошёл размер», «хочу вернуть».
- «Доставка»: проблема со сроками, адресом, курьером или пунктом выдачи.
Маркеры: «не привезли», «курьер не позвонил», «пункт закрыт».
- «Брак»: заявлен дефект товара.
Маркеры: «сломан», «не включается», «трещина», приложены фото дефекта.
- «Мошенничество»: подозрение на обман продавца или подмену товара.
Маркеры: «вместо телефона кирпич», «продавец просит писать в мессенджер».
Текст обращения:
«Заказал кроссовки на Ozon, пришла коробка с чужими тапками.
Продавец в чате просит удалить отзыв и написать ему в Telegram.»
Признаки из текста: подмена товара — есть; требование уйти из чата площадки — есть;
фото дефекта — нет; претензий к срокам — нет.
Внешний классификатор предполагает: «возврат».
У тебя два неидеальных источника: твоё собственное прочтение текста
и предсказание классификатора. Реши, какая категория лучше подтверждается
самим текстом обращения. Не следуй автоматически ни за одним источником.
Ответ: категория и одна фраза обоснования.
Как проверить: Возьмите 100 размеченных обращений. Прогоните их через шаг 1, шаг 2 и шаг 3. Посчитайте точность LLM без подсказки, классификатора отдельно и связки.
Результат: Вы получите три числа. Скорее всего связка будет лучше «голой» LLM, но окажется на уровне классификатора или чуть ниже. Разбор ошибок покажет, чего больше: случаев, когда модель отвергла верную метку классификатора, или случаев, когда приняла неверную. В статье первых было заметно больше. Если связка не обгоняет классификатор, LLM лучше оставить для объяснений и разбора спорных случаев, а не для финальной метки.
Почему это работает
Слабость LLM. Когда в промпт добавляют «инструмент считает X», модель не взвешивает два источника по-настоящему. Она либо цепляется за своё первое прочтение и не принимает верную поправку, либо поддаётся подсказке. Обе ошибки происходят, но первая заметно чаще. Сравнение «связка против LLM без помощи» эту проблему скрывает: кажется, что инструмент помог, хотя часть его знания потеряна.
Сильная сторона LLM. Когда в промпте есть предметные факты (какие признаки о чём говорят, какие пороги и маркеры существуют), модель опирается на них и реже уступает ложной подсказке. В исследовании «привязанные к задаче» данные снижали число случаев, когда неверный совет перебивал верный ответ, у шести из семи моделей.
Как метод это использует. Протокол из трёх вызовов отделяет обычную нестабильность модели от эффекта подсказки. Сравнение с сильнейшим источником показывает реальную цену интеграции.
Рычаги управления: - Предметные данные в промпте: определения классов, маркеры признаков, пороги. Добавляй, это единственное, что реально сработало. - Повторный вызов (шаг 2): не убирай. Без него обычный разброс ответов принимают за эффект подсказки. - Формулировка подсказки: держи одинаковой во всех режимах, иначе сравнение теряет смысл. - Инструкция «не следуй автоматически ни за кем»: можно добавить, но не рассчитывай на неё. В исследовании она дефицит не устранила. - Режим «усиленного рассуждения»: на проблему в этом тесте не повлиял, не трать на него деньги в расчёте на улучшение.
Шаблон промпта
Задача: {описание_задачи}. Выбери одну категорию из списка: {список_категорий}.
Справка по признакам:
{определения_категорий_и_маркеры}
Данные кейса:
{текст_или_данные_кейса}
Ключевые признаки, найденные в данных:
{признаки_с_пояснением_что_они_значат}
Внешний инструмент предполагает: «{метка_инструмента}».
У тебя два неидеальных источника: твоё собственное прочтение данных
и предсказание внешнего инструмента. Реши, какая категория лучше
подтверждается данными кейса. Не следуй автоматически ни за одним источником.
Ответ: категория и одна фраза обоснования.
Плейсхолдеры:
- {список_категорий} — закрытый список, из которого модель обязана выбрать.
- {определения_категорий_и_маркеры} — одинаковый блок для всех кейсов, это главный рычаг.
- {признаки_с_пояснением} — не сырые данные, а выжимка «признак → на что указывает».
- {метка_инструмента} — ровно та формулировка, что в боевой схеме.
Для проверки запусти этот же шаблон без строки про инструмент (шаг 1) дважды (шаг 2 — повтор) и один раз с ней (шаг 3).
🚀 Быстрый старт — вставь в чат:
Вот шаблон интеграции LLM с внешним инструментом и протокол проверки.
Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про список категорий, признаки, формат метки инструмента и то, как вы будете проверять результат. Эти данные нужны, чтобы справка по признакам была конкретной, а сравнение трёх режимов было честным.
Ограничения
⚠️ Лабораторные условия: Данные — вибрация подшипников, симуляция химзавода, один станок. Реальных производственных развёртываний нет. Перенос на тикеты поддержки или финансы — по аналогии, авторы его не проверяли.
⚠️ Закрытый список классов: Модель выбирает метку из фиксированного набора. Для свободных текстов, рекомендаций и открытых задач вывод не доказан.
⚠️ Неявная интеграция: Проверена только подсказка одной строкой в промпте. Другие способы объединения (например, правило «по умолчанию верим инструменту, LLM лишь флагует сомнения») не тестировали.
⚠️ Малые выборки: В части наборов десятки кейсов. Интервалы широкие, а выводы про влияние предметных данных частично получены постфактум.
⚠️ Что не помогло: Прямая инструкция «не доверяй слепо», показ собственного первого ответа и повышенное «усилие рассуждения» дефицит не убрали. Не надейся, что эти приёмы сами исправят положение.
⚠️ Предметные данные — не панацея: Они снизили склонность поддаваться неверным подсказкам. Пропуск верных поправок отдельно этим приёмом не измеряли.
Как исследовали
Исследователь взял пять наборов диагностических данных: три про подшипники, симуляцию химического завода Tennessee Eastman и данные станка для травления пластин. Для каждого кейса модель вызывали три раза. Первый вызов был без подсказки. Второй был точной копией первого и показывал, как часто ответ меняется сам по себе. В третьем добавляли одну строку: «внешний инструмент считает X». Так подсказку отделили от обычной нестабильности модели.
Главный тест — завод: 150 прогонов, 6 типов неисправностей, 7 моделей. Протокол и выбор «специалиста» (простой классификатор) зафиксировали до запуска. Модели без помощи: 64,67%. С подсказкой: 77,43%. Сам классификатор: 83,33%. То есть подсказка помогла на 12,8 пункта, но связка осталась на 5,9 пункта ниже инструмента.
Теоретический «идеальный выбор» между двумя ответами дал бы 92,76%. Значит, источники дополняют друг друга, но модель этим не пользуется. Разбор ошибок показал картину: из 295 случаев, где классификатор был прав, а модель в одиночку нет, связка пропустила 140 (47,5%). А потеряла она из 99 изначально верных ответов только 15 (15,2%). Если бы авторы боролись только с «слепой верой», они бы лечили более редкую проблему.
Затем проверили, не виноват ли промпт: добавили прямую инструкцию арбитража, показали модели её собственный первый ответ, заменили классификатор на случайный лес. Дефицит остался. Это главный аргумент, что проблема не в формулировке.
Отдельно на подшипниках проверили вмешательства. Если вместо общей сводки дать «предметную» подачу (теоретические частоты, связь частот с типами дефектов), неверный совет перебивал верный ответ реже у шести из семи моделей. Среднее снижение — 24,6 пункта. Усиленное рассуждение надёжно не помогло ни на подшипниках, ни на заводе.
Удивило то, что подсказка помогает, а итог всё равно хуже. И что модели чаще не принимают верную подсказку, чем принимают неверную.
Адаптации и экстраполяции
🔧 Техника: добавить второй проход → видеть, где модель расходится с собой
Запусти шаг 2 (повтор без подсказки) не один раз, а три. Кейсы, где ответ «гуляет», это зона, где подсказка инструмента ничего не доказывает: вы не отличите эффект подсказки от шума. Для таких кейсов лучше не давать модели решающий голос.
Следующее — экстраполяция, в статье не проверялась:
Если связка не обгоняет сильный инструмент, не давай LLM права финального решения. Роль модели в системном промпте: «Ты не меняешь метку классификатора. Если тебе кажется, что она неверна, пометь кейс как "на ручную проверку" и объясни почему». Тогда модель не может отвергнуть верную поправку, а сомнительные случаи уходят человеку. Проверь на своих 100 размеченных кейсах, не потеряла ли такая схема в точности.
Ресурсы
- Работа: When LLMs Sit Above Diagnostic Tools: Unrealized Complementarity in Industrial Fault Diagnosis
- Автор: Donghwan Kim, независимый исследователь (donhkim9714@korea.ac.kr)
- Использованные данные: CWRU (Case Western Reserve University), Paderborn, XJTU-SY, Tennessee Eastman (Rieth et al., 2017; Downs and Vogel, 1993), Lam 9600 (Eigenvector Research; Wise et al., 1999), WM-811K
- Связанные работы: Vaccaro, Almaatouq, Malone (2024), команды человек–ИИ; Bansal et al. (2021); работы по learning-to-defer (Madras et al., 2018; Mozannar and Sontag, 2020)