Комфортный AX для поиска агентами

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

Что должен получить ваш агент, когда запускает поиск?

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

А теперь посмотрите, что большинство инструментов возвращает на тот же поиск агенту. Список ID. Может быть, полный текст каждого совпадения. Проектировать то, что получает агент, — такое же ремесло, как проектировать экран, и именно эту часть большинство инструментов пропускает.

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

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

Пройдёмся по неправильным ответам

Начнём с очевидного: вернуть только ID. Технически агент может с этим работать, но только подтягивая содержимое по каждому ID, по одному вызову за раз. Вы не сэкономили контекст, а отложили его, и проценты по этому долгу платит агент. Прежде всего результат должен быть пригоден к делу сразу, как есть.

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

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

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

Результат, который работает

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

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

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

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

Одномерный UX

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

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

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

Проектировать для агента как для настоящего пользователя

Отнестись к этому всерьёз — это больше, чем красиво отформатировать вывод. Это контракт, и он действует в обе стороны.

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

А ещё он должен оставлять эти леса у себя, а не выносить их наружу. Отвечая человеку, агент переводит всё на обычный язык. Структуру читает агент, так же как браузер читает дерево доступности, чтобы решить, что показать; человек её никогда не видит. Прочитай структуру, действуй по ней и оставь её при себе.

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

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

Самый наглядный случай, но не единственный

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

Пропустите проектирование, и вы сразу это почувствуете: агент открывает сорок сообщений ради одной строчки, цитирует знак обрезки как факт или буксует на результате, который так и не дочитал.

Любой вывод, который вы отдаёте агенту, — это интерфейс, проектировали вы его или нет. Результаты инструментов, ошибки, статусы, списки: всё это информация, которую агент должен понять и по которой должен действовать. Вопросы не меняются. Может ли он использовать то, что видит? Знает ли он, что делать дальше?

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