Точность подсказки: измерение того, насколько эффективно ИИ-агент выполняет ваши намерения.

Какая часть результатов работы вашего ИИ-агента основана на реальных данных, а какая — на уверенных предположениях?

Делиться

Крюк

Spotify только что запустил бета-версию «Плейлистов по запросу». Я создал несколько плейлистов и обнаружил, что LLM, лежащий в основе агента, пытается выполнить ваш запрос, но терпит неудачу, потому что ему не хватает знаний, но он не хочет этого признавать. Вот что я имею в виду: один из моих первых запросов для плейлиста был «песни в минорной тональности в стиле рок». Плейлист был быстро создан. Затем я добавил оговорку: «и ни одна песня не должна иметь более 10 миллионов прослушиваний». ИИ-агент выдал ошибку, объяснив, что у него нет доступа к общему количеству прослушиваний. Он также неожиданно объяснил, что у него нет доступа к некоторым другим данным, таким как музыкальные тональности, хотя он утверждал, что использует их при создании плейлиста. Агент использовал знания своего LLM о тональности той или иной песни и добавлял песни в соответствии со своей памятью. При внимательном рассмотрении плейлиста обнаружилось несколько песен, которые вообще не были в минорной тональности. Студент магистратуры, разумеется, получил эту информацию в результате галлюцинаций и с гордостью продемонстрировал ее как достоверное соответствие подсказке плейлиста.

Очевидно, что создание плейлиста — это довольно несложная функция ИИ-агента. Плейлист получился отличным! Проблема в том, что он использовал в качестве проверенных входных данных только около 25% моих ограничений. Остальные 75% ограничений были просто угаданы LLM, и система не сообщила мне об этом, пока я не углубился в анализ. Это не проблема Spotify; это проблема всех агентов.

Три утверждения

Чтобы продемонстрировать концепцию оперативной верности более широко, я должен выдвинуть следующие три утверждения:

1. Проверенный слой данных любого ИИ-агента имеет ограниченную или конечную емкость. Агент может запрашивать только те инструменты, которые ему предоставлены, а эти инструменты предоставляют фиксированный набор полей с конечной детализацией. Можно перечислить каждое поле в схеме и измерить, насколько каждое из них сужает поиск. Показатель популярности исключает определенную долю кандидатов. Дата выпуска исключает другую. Жанровый тег исключает еще больше. Суммируя, насколько сужают поиск все поля вместе взятые, вы получаете точное число: максимальный уровень фильтрации, который агент может подтвердить. Я назову это число I_max.
2. Намерения пользователя, выраженные на естественном языке, по сути, безграничны. Человек может написать запрос произвольной детализации. «Создайте плейлист с песнями в стиле пост-панк из Манчестера, с басовой партией в минорной тональности, записанными в студиях с аналоговым оборудованием в период с 1979 по 1983 год, которые повлияли на готический рок, но так и не попали в чарты». Каждое условие сужает поиск. Каждое прилагательное добавляет точности. Нет предела детализации запроса пользователя, потому что естественный язык не был разработан с учетом схем баз данных.
3. Из первых двух следует: для любого ИИ-агента существует точка, когда запрос пользователя требует больше информации, чем может проверить слой данных. Как только запрос требует более узкого определения, чем могут предоставить проверенные поля, оставшаяся работа должна откуда-то взяться. Этим «куда-то» являются общие знания, сопоставление с образцом и вывод LLM. Агент все равно выдаст уверенный результат. Он просто не сможет доказать все. Не потому, что модель плохо построена, а потому, что математические вычисления не позволяют ничего другого.

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

Проблема: Агенты не сообщают о своем коэффициенте сжатия.

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

Такое разложение запроса на действие фактически стирает смысл между тем, что вы запрашиваете, и тем, что отвечает ИИ-агент. Слой повествования ИИ-агента сводит ваш запрос и его вывод к одному единственному ответу.

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

Нам нужен показатель для его измерения. Я назову его «Точность подсказки».

Показатель: Точность воспроизведения.

Точность выполнения запроса для агентов ИИ определяется ограничениями, которые вы задаете агенту, когда просите его выполнить какое-либо действие. Каждое ограничение в запросе сужает возможные пути, по которым может пойти агент, на определенную измеримую величину. Наивный подход к расчету точности заключался бы в подсчете каждого ограничения, суммировании проверяемых и предполагаемых. Проблема такого подхода в том, что каждое ограничение имеет одинаковый вес. Однако данные в реальных наборах данных часто сильно искажены. Ограничение, которое исключает 95% каталога, выполняет гораздо больше работы, чем ограничение, которое исключает 20%. Подсчет каждого ограничения одинаково неверен.

Следовательно, нам необходимо правильно взвесить каждое ограничение в соответствии с той работой, которую оно выполняет при фильтрации набора данных. Логарифмы позволяют выполнить это взвешивание. Биты информации в запросе можно определить как «-log2(p)», где p — это доля сохранившейся информации из примененных ограничений или заполнителей.

В каждом действии агента каждое ограничение может быть только а) проверено с помощью вызовов инструментов или б) выведено с помощью LLM. Точность подсказки измеряет соотношение ограничений между этими двумя вариантами.

Показатель точности запроса (Prompt Fidelity) находится в диапазоне от 0 до 1. Идеальное значение 1,0 означает, что каждая часть вашего запроса была подкреплена реальными данными. Точность 0,0 означает, что весь результат работы ИИ-агента был обусловлен его внутренними рассуждениями или интуицией.

Система Spotify, описанная выше, всегда выдает идеальный результат 1,0 в этой ситуации. В действительности же точность подсказок при создании плейлиста составляла около 25% — два ограничения (менее 4 минут и запись до 2005 года) были выполнены агентом, остальные были выведены из имеющихся (и потенциально ошибочных) знаний и памяти агента. В больших масштабах и при решении более серьезных проблем ложное сообщение о высокой точности подсказок становится серьезной проблемой.

Что на самом деле означает (и чего не означает) понятие «верность»?

В аудиосистемах «точность воспроизведения» — это мера того, насколько точно система воспроизводит исходный сигнал. Высокая точность воспроизведения не гарантирует, что сама музыка хороша. Высокая точность воспроизведения гарантирует лишь то, что музыка звучит так, как звучала в момент записи. То же самое относится и к точности воспроизведения: насколько точно система воспроизвела ваше первоначальное намерение (сигнал).

Высокая точность выполнения запроса означает, что система сделала то, что вы просили, и вы можете это ДОКАЗАТЬ. Низкая точность выполнения запроса означает, что система, вероятно, сделала что-то близкое к тому, что вы хотели, но вам придется перепрослушать весь плейлист, чтобы убедиться в этом.

Показатель соответствия подсказке НЕ является оценкой точности. Он не может сказать вам, что «75% песен в плейлисте соответствуют вашей подсказке». Плейлист с показателем соответствия 0,25 может быть на 100% идеальным. LLM может точно определить каждую добавленную песню. Или же половина песен может быть неверной. Вы этого не знаете. Вы не сможете узнать, пока не прослушаете все песни. В этом и заключается смысл измеримого показателя соответствия подсказке.

Вместо этого, показатель оперативности и достоверности измеряет, насколько вы можете ДОВЕРЯТЬ результату БЕЗ ПРОВЕРКИ. В финансовом аудите, если 25% позиций подтверждены квитанциями, а 75% — приблизительными оценками, общая сумма счета может быть на 100% точной, но ваша УВЕРЕННОСТЬ в этой сумме принципиально отличается от аудита, в котором каждая позиция подтверждена квитанцией. Это различие важно, потому что есть области, где «просто доверяйте интуиции» допустимо (музыка), и области, где это недопустимо (медицинские консультации, финансовые рекомендации, соблюдение законодательства).

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

На практике, в нашем примере со Spotify: по мере добавления новых ограничений к запросу на создание плейлиста, точность запроса снижается, плейлист становится не столько точным отчетом, сколько рекомендацией. Это совершенно нормально, но пользователь должен быть информирован о том, какой именно плейлист он получает. Соответствует ли этот плейлист моим запросам? Или вы создали что-то, что позволило достичь поставленной мной цели? Предоставление этой информации пользователю крайне важно для укрепления доверия к таким системам, основанным на взаимодействии с пользователями.

Пример из практики: обратное проектирование ИИ-агента для создания плейлистов в Spotify.

Функция «Плейлисты с подсказками» в Spotify положила начало этому исследованию точности воспроизведения подсказок. Давайте подробнее рассмотрим, как это работает и что я сделал, чтобы изучить эту возможность, используя только стандартное поле ввода подсказок.

В плейлистах с подсказками вы можете описать желаемое естественным языком. Например, в этом плейлисте подсказка звучит просто: «рок-песни в минорных тональностях, продолжительностью менее 4 минут, записанные до 2005 года, с басовыми партиями в качестве ведущего мелодического элемента».

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

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

Однако, используя простой метод, мне удалось составить карту того, что, как я считаю, является полным контрактом на данные, доступным агенту, за один вечер (естественно, не вставая с дивана и не смотря «Клан Сопрано»).

Методика: Невозможные ограничения как функция воздействия

В результате того, как Spotify спроектировал этот агент для создания плейлистов, когда агент не может выполнить запрос, сообщения об ошибках могут быть скорректированы таким образом, чтобы раскрыть архитектурные детали, которые иначе недоступны. Когда вы обнаруживаете ограничение, на основе которого агент не может создать плейлист, он выдает ошибку, и вы можете использовать это, чтобы понять, что он МОЖЕТ сделать. Я буду использовать это как константу для исследования системы.

В приведенном выше примере плейлиста «Minor Keys & Bass Lines» добавление фразы разблокировки «с менее чем 10 миллионами прослушиваний» действует как автоматический выключатель для агента, сигнализируя о невозможности выполнения запроса пользователя. С помощью этой фразы вы можете исследовать возможности, многократно изменяя другие аспекты запроса, пока не увидите, к чему у агента есть доступ. Сбор ответов, задавание пересекающихся вопросов и анализ ответов позволяют сформировать базовое понимание того, что доступно агенту.

Что я обнаружил: Трехуровневая архитектура

Агент Spotify Prompted Playlist располагает огромным объемом данных. Я разделил их на три уровня: музыкальные метаданные, данные о пользователях и результаты анализа LLM. Помимо этого, похоже, что Spotify исключил различные источники данных из своего агента либо по собственному выбору, либо в целях ускорения процесса.

• Уровень 1
  • Проверенные метаданные трека: продолжительность, дата выпуска, популярность, темп, энергия, нецензурная лексика, жанр, язык.
• Уровень 2
  • Проверенные данные о поведении пользователей: количество воспроизведений, количество пропусков, временные метки, флаги давности, количество сыгранных миллисекунд, источник, анализ периода (всего более 40 полей).
• Уровень 3
  • Умозаключения в рамках программы LLM: тональность/лад, танцевальность, валентность, акустические свойства, настроение, инструментарий — все это выводится из общих знаний и излагается так, как если бы было подтверждено.
• Преднамеренное исключение:
  • В общедоступном API Spotify есть аудиофункции (возможность танцевать, валентность и т. д.), но у агента к ним нет доступа. Возможно, это особенность продукта, а не техническое ограничение.

Полный список доступных полей приведен в конце этого сообщения.

Результаты поведенческих исследований

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

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

Похоже, существует «порог уверенности», который агент не решается переступить. Например, всё это исследование основывалось на фразе разблокировки «менее 10 миллионов игр». В этом случае агент каждый раз раскрывал лишь несколько полей, к которым у него был доступ. Этот список полей менялся от запроса к запросу, даже если сам запрос оставался тем же. Это классический пример недетерминизма в LLM. Чтобы повысить доверие к системе, необходимо прямо и ясно показать, к чему агент ИМЕЕТ доступ, и сообщить человеку, о чём он может и не может спрашивать.

Наконец, когда эти два типа данных смешиваются, агенту неясно, для каких песен он использовал проверенные данные, а для каких — выведенные. Как проверенные, так и выведенные решения смешиваются и представляются с одинаковой достоверностью в музыкальных нотах. Например, если вы создадите плейлист с подсказками, основанный на вашей собственной пользовательской информации («песни, которые я пропускал более 30 раз, с энергичной басовой мелодией»), агент добавит реальные данные («вы пропускали эту песню 83 раза в прошлом году!») прямо рядом с выведенными знаниями («басовая партия Джона Дикона привлекает внимание на протяжении всей этой песни»). Чтобы было понятно, я, насколько мне известно, не пропускал ни одной песни Queen 83 раза. Но у ИИ-агента нет поля «bass_player» в доступных данных для запроса. ИИ знает, что в песнях Queen часто присутствует сильная басовая партия, и знание о том, что Джон Дикон — бас-гитарист Queen, позволяет его логическому модулю сделать вывод, что именно его басовая партия привела к добавлению песни в плейлист.

Применение математики: два плейлиста, две оценки качества звука.

Давайте применим эту концепцию точности воспроизведения к примерам плейлистов. У меня нет полного доступа к музыкальному каталогу Spotify, поэтому я буду использовать примеры показателей выживаемости из наших критериев фильтрации в вычислениях битов точности. Формула одинакова на каждом шаге: биты = −log₂(p), где p — это предполагаемая доля каталога, которая сохраняется после применения фильтра.

«Мелодии минорного баса» — Уверенная Иллюзия

Этот плейлист — тот, где играет Queen. «Плейлист рок-музыки, вся в минорной тональности, продолжительностью менее 4 минут, выпущенный до 2005 года, с ведущей басовой партией». Я применю нашу формулу и использую информацию, полученную на каждом этапе, чтобы рассчитать точность воспроизведения подсказки.

Продолжительность < 4 минут

• Оценка: ~80% треков короче 4 минут → p = 0,80

• Это практически ничего не сужает, поэтому и вносит столь незначительный вклад.

Дата выпуска до 2005 года

• Оценка: ~30% каталога Spotify составляют релизы, выпущенные до 2005 года (каталог в значительной степени состоит из недавних релизов) → p = 0,30

• Более избирательный подход — исключает 70% каталога.

минорная тональность

• Оценка: ~40% популярной музыки написано в минорной тональности → p = 0,40

• Умеренная избирательность, но это лишь предположение — подтвержденный агентом ключ/режим не является проверенным полем.

Мелодический элемент, в котором доминирует басовая линия

• Оценка: примерно в 5% треков бас является ведущим мелодическим элементом → p = 0,05

• Это, безусловно, самое избирательное ограничение. Этот единственный фильтр выполняет больше работы, чем остальные три вместе взятые. И это на 100% интуитивно понятно.

Итого:

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

«Пропущенные песни» — Честный плейлист

Этот запрос очень прост: «Плейлист песен, которые я пропускал более 5 раз». Проверить это очень легко, и агент будет использовать имеющиеся у него данные.

Количество пропусков > 5

• Оценка: примерно 10% треков в вашей библиотеке были пропущены более 5 раз → p = 0,10

• Это единственное ограничение, и это проверенное поле (user_skip_count).

Итого:

Структурный анализ

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

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

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

Валидация: контролируемый агент

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

https://github.com/Barneyjm/prompt-fidelity

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

Скучное задание (F = 1,0)

Начнём с «скучного» запроса: «Боевика 1980-х годов с рейтингом выше 7.0». Это предоставляет агенту три ограничения: жанр, диапазон дат и рейтинг. Все эти ограничения соответствуют проверенным значениям данных в базе данных.

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

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

Подсказка по атмосфере (F = 0,0)

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

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

Главный вывод

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

«Граница верности»

Чтобы было понятнее: каталог Spotify содержит примерно 100 миллионов треков. Объём информации, который должен содержать ваш запрос, чтобы сузить каталог до нужного вам плейлиста, я обозначу как I_required.

Для выбора плейлиста из 20 песен из этого каталога вам потребуется приблизительно 22 бита избирательности (log₂ от 100 миллионов, деленный на 20).

Проверенные поля (длительность, дата выпуска, популярность, темп, энергия, жанр, флаг нецензурной лексики, язык и полный набор данных о поведении пользователя) имеют суммарную емкость, которая достигает примерно 10–12 бит, в зависимости от того, как вы оцениваете избирательность каждого поля. После этого слой проверенных полей исчерпывается. Каждый дополнительный бит специфичности, требуемый вашим запросом, должен быть получен из вывода LLM. Я назову это максимумом, I_max.

Это устанавливает верхний предел точности для любого запроса:

А также предельный уровень качества любого плейлиста:

Для агента Spotify максимально конкретная подсказка, полностью определяющая плейлист, не может превышать примерно 55% точности. Остальные 45% гарантированно являются результатом логического вывода. Для более простых подсказок, не выходящих за рамки возможностей проверяемого слоя, точность может достигать 1,0. Но по мере того, как подсказки становятся более конкретными, точность снижается, не постепенно, а неизбежно.

Это определяет то, что я называю границей точности: кривая максимально достижимой точности как функция специфичности подсказки. У каждого агента есть такая кривая. Ее можно вычислить заранее на основе схемы инструмента. Простые подсказки находятся слева от кривой, где точность высока. Креативные, конкретные, интересные подсказки находятся справа, где точность структурно ограничена значением ниже 1,0.

Неприятный вывод заключается в том, что именно те запросы, которые наиболее важны для пользователей (те, которые кажутся личными, конкретными и адаптированными под их потребности), выходят за рамки возможностей уровня проверки. Наиболее интересные результаты получаются при наименее точном выполнении запроса. А самые скучные запросы — самые заслуживающие доверия. Этот компромисс заложен в самой математике. Он не исчезает с масштабированием, улучшением моделей или увеличением баз данных. Он лишь меняется.

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

Более широкое применение: Эта проблема встречается у каждого агента.

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

Рассмотрим системы генерации дополненных и дополненных данных (Retrieval Augmented Generation, RAG), которые сегодня лежат в основе большинства корпоративных баз знаний на основе ИИ. Когда сотрудник задает внутреннему помощнику вопрос о политике компании, часть ответа поступает из найденных документов, а часть — от модели LLM, которая синтезирует информацию из них, заполняя пробелы и сглаживая формулировки, делая текст читаемым. Поиск проверяется. Синтез выводится. И ответ читается как один цельный абзац без указания на то, где находятся швы. Сотрудник отдела комплаенса, читающий этот ответ, никак не может определить, какое предложение взято из корпоративного документа с политикой компании, а какое модель придумала для соединения двух абзацев, которые не совсем подходят друг к другу. Вопрос о точности идентичн вопросу о плейлисте, только с более высокими ставками.

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

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

Общая формула оперативной верности применима ко всем этим случаям:

Точность = количество битов ответа, основанных на вызовах инструментов / общее количество битов ответа

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

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

Потолок сложности

У каждого агента есть предел сложности. Простые запросы (сколько прослушиваний у этого трека?) по сути бесплатны. Фильтрация каталога по набору предикатов на уровне полей (показать все треки продолжительностью менее 4 минут, до 2005 года, популярность ниже 40) масштабируется линейно и выполняется быстро. Но как только запрос требует сопоставления сущностей друг с другом (появляется ли этот трек более чем в трех моих плейлистах? был ли где-то годовой перерыв в моей истории прослушиваний?), стоимость возрастает квадратично, и агент либо сразу отказывается, либо молча выполняет приблизительный поиск.

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

Этот потолок не является уникальным для Spotify. Любой агент, построенный на основе поиска по индексированной базе данных, столкнется с тем же самым. Граница проходит там, где запросы перестают быть разлагаемыми на независимые условия WHERE и начинают требовать объединений, полного сканирования или агрегирования по всей истории. Ниже этой линии агент — это инструмент точной обработки. Выше — это система рекомендаций, облеченная в оболочку инструмента точной обработки. Вопрос для любого, кто создает такие системы, заключается не в том, существует ли потолок (он всегда существует), а в том, знают ли ваши пользователи, где он находится.

Что с этим делать: рекомендации по дизайну

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

• Сообщайте о точности воспроизведения, пусть даже приблизительно. Spotify уже отображает качество звука в виде простого индикатора (низкое, нормальное, высокое, очень высокое) при потоковой передаче музыки. Тот же принцип работает и для точности воспроизведения по запросу. Вам не нужно показывать пользователю десятичную оценку. Простой метки («этот плейлист точно соответствует вашему запросу» против «этот плейлист вдохновлен вашим запросом») будет достаточно, чтобы правильно сформировать ожидания. Разница между инструментом точного воспроизведения и системой рекомендаций незначительна, если пользователь понимает, что именно он держит в руках.
• Различайте обоснованные утверждения от предположений в пользовательском интерфейсе. Это может быть тонко. Небольшая иконка, незначительное изменение цвета, сноска. Когда в примечаниях к плейлисту Spotify написано «86 пропусков», это факт из базы данных. Когда они говорят «басовая линия Джона Дикона задает ритм всему треку», это общеизвестный факт. Сегодня оба варианта представлены одинаково. Даже минимальное визуальное различие позволило бы пользователям оценивать степень доверия к каждому утверждению отдельно, а не доверять или не доверять всему результату целиком.
• Четко указывайте на возможные замены. Если агент не может точно выполнить запрос, но может приблизиться к нему, он должен об этом сообщить. Фраза «Я не смог отфильтровать по статусу загрузки, поэтому нашел песни из альбомов, которые вы сохранили, но которые вам не понравились» гораздо лучше сохраняет доверие, чем молчаливое предоставление близкого результата и описание его так, как будто первоначальный запрос был выполнен. Пользователи снисходительны к ограничениям. Но они гораздо менее снисходительны к тому, что их вводят в заблуждение.
• Обеспечьте детерминированное обнаружение возможностей. Когда я попросил агента Spotify перечислить все поля, по которым он может выполнять фильтрацию, он каждый раз выдавал разный ответ в зависимости от контекста запроса. LLM восстанавливал список полей из памяти, а не считывал его из фиксированной ссылки. Любой агент, предоставляющий пользователям возможности фильтрации или запросов, должен иметь стабильный, детерминированный способ обнаружения этих возможностей. Команда «покажи мне, что ты можешь сделать», которая каждый раз возвращает один и тот же ответ, является обязательным условием для доверия пользователей.
• Проведите аудит собственного агента с помощью этой методики, прежде чем это сделают ваши пользователи. Методика, описанная в этой статье (сопоставление невыполнимых ограничений с целевыми полями для принудительного получения информативных отказов), представляет собой универсальный метод аудита, который работает с любым агентом, имеющим доступ к инструментам. На составление полного контракта данных Spotify ушло один вечер и около дюжины запросов. Ваши пользователи сделают то же самое, независимо от того, пригласите вы их или нет. Вопрос в том, понимаете ли вы границы своей системы раньше, чем они.

Закрытие

У каждого ИИ-агента есть показатель точности. У большинства он ниже, чем можно было бы ожидать. Ни один из них его не сообщает.

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

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

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

Вопрос не в том, будет ли измерена добросовестность вашего агента. Вопрос в том, измерили ли вы её первыми.

Бонус: Подсказки, которые стоит попробовать (если у вас есть Spotify Premium)

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

Анализ взаимоотношений

• «Песни, в которых количество пропусков превышает количество прослушиваний»
• Предупреждение: эта песня может вызвать экзистенциальный дискомфорт (вы же пропускаете эти песни не просто так!).

Любовь с первого прослушивания

• «Песни, которые я сохранил в течение 24 часов после первого прослушивания, отсортированы по дате добавления (от самых старых к самым старым)»
• Хронологическая последовательность треков, которые сразу же вас зацепили.

Жизненный цикл

• «Песни, которые я впервые сыграл, отсортированные по количеству прослушиваний»
• Ваша история появления на платформе

Марафон

• «Песни, для которых общее время воспроизведения (ms_played) является максимальным, перевести в часы».
• Не большинство игр — а общее время, проведенное за игрой. Другой, зачастую неожиданный список.

Самые долгие отношения

• «Песни с наименьшим интервалом между первым и последним прослушиванием, с не менее чем 50 прослушиваниями, упорядоченные по дате первого прослушивания».

Навязчивые идеи на одну неделю

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

Капсула времени

• «По одной песне из каждого года, что я на Spotify — песня с наибольшим количеством прослушиваний за этот год».

До и после

• «Два набора: 10 моих самых часто проигрываемых песен за 6 месяцев до [дата достижения] и 10 моих самых часто проигрываемых песен за 6 месяцев после»
• Введите любую важную дату — переезд, новая работа, расставание или даже карантин из-за COVID-19.

Саундтрек к году

• «Выберите год, когда общее количество воспроизведенных мной песен (ms_played) было максимальным. Создайте плейлист из моих лучших песен этого года».

Что не сработало (и почему)

• История возвращения (возвращение после годичного перерыва): «Песни, которые я заново открыл для себя после годичного перерыва в прослушивании».
  • Агент не может просканировать всю историю воспроизведения на наличие пробелов. Запросы на основе снимков работают, сканирование временной шкалы — нет.
• Сезонные особенности (играл только в декабре): «Песни, которые я играл только в декабре, но никогда в другие месяцы».
  • Для доказательства универсального отрицания требуется полное сканирование. То же самое фундаментальное ограничение.
• Вычисления (ms_played / play_count): «Песни, среднее время прослушивания которых составляет менее 30 секунд».
  • Агент испытывает трудности с вычисляемыми полями. Лучше использовать сравнения по исходным данным.
• Эти сбои напрямую связаны с пределом сложности — они требуют операций O(n²) или операций полного сканирования, которые агент не может или не имеет права выполнять.

Советы

• В случае неправильной интерпретации естественного языка агент может ссылаться непосредственно на названия полей.
• Начинайте с широких ограничений и постепенно ужесточайте их. Более мягкие ограничения чаще приводят к успеху.
• «Если вы не можете сделать X, скажите, что вы МОЖЕТЕ сделать» — это универсальный вопрос для аудита.

Метаданные отслеживания

Аудиофункции (частично)

Данные о поведении пользователей

Источник и контекст

Периодический анализ (с временным окном)

Поля запроса/поиска

Подтверждено, что недоступно

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