Структурированный индекс: как ИИ-агент отвечает на вопрос «сколько» по вашим документам
Структурированный индекс — это небольшая таблица, которую агент формирует на основе полей, уже содержащихся в ваших документах (название, цена, уровень, ссылка, изображение), вместе с векторным поиском, используемым для понимания смысла. Векторный поиск находит фрагменты, которые по смыслу похожи на вопрос; он не умеет считать, фильтровать по числовым значениям или группировать. Структурированный индекс отвечает на такие вопросы и позволяет агенту точно цитировать ссылку или идентификатор, вместо того чтобы восстанавливать их из фрагмента.
Спросите «сколько у вас есть?», и агент ответит, опираясь на четыре отрывка, которые ему случайно попались. Попросите ссылку, и он может выдать настоящую ссылку на другой товар — она открывается, изображение отображается, никаких ошибок. Вот как это происходит и что этому мешает:
Каждый документ имеет свой цвет. На левой части — поиск по извлечению, как он работает сегодня — заголовок ответа берётся из одного документа, а ссылка из другого, и цвета мгновенно выдают несоответствие. На правой части каждый извлечённый фрагмент приносит с собой факты своего документа, и ссылка — это не ссылка: это заполнитель, который модель копирует, никогда не видя адреса. Реальное значение подставляется на выходе, поэтому перепутать нечего.
Поиск находит отрывки; он не видит коллекцию целиком
Векторный поиск работает по принципу сходства: ваш вопрос превращается в направление в пространстве, и возвращаются ближайшие к нему отрывки. Это совершенно верно для вопроса «что это говорит о X» и структурно бесполезно для вопросов «сколько всего», «какие из них короче 200 слов» или «сколько на категорию» — это вопросы о всей коллекции, а поиск рассматривает только ближайшие несколько отрывков.
Никакая настройка не исправит этого. Не существует порога, при котором поиск по сходству вернёт общее количество, потому что общее количество — это не отрывок.
Вторая, более тихая ошибка: чанк — это не документ
Длинные документы разбиваются на чанки, чтобы поиск мог найти нужный абзац. Но ваш заголовок, код продукта, ваша ссылка и изображение находятся в заголовке — а значит, они находятся в чанке 1, а отрывок, который фактически ответил на вопрос, может быть чанком 7.
Таким образом, модель оказывается с четырьмя или пятью фрагментами из трёх или четырёх разных документов, и ей нужно понять, какая ссылка какому заголовку принадлежит. Она догадывается. И когда она ошибается в догадке, ответ не выглядит ошибочным: ссылка реальна, она открывается, изображение отображается — просто она принадлежит другому товару. Ничего не выдаёт ошибку. Никто не замечает.
В каталоге из 4 500 документов 11 из 20 тестовых ответов сопоставили заголовок со ссылкой из другого документа. С описанным выше механизмом заполнителя те же 20 ответов вернулись правильными 20 раз из 20.
Что такое структурированный индекс
Это небольшая таблица, одна строка на документ, построенная на основе полей, которые уже содержат ваши документы. Ничего не придумано и ничего не переписано — значения копируются посимвольно.
С его наличием у агента появляется два способа ответить вместо одного:
| Вопрос | Отвечает |
|---|---|
| «У вас есть что-нибудь о динозаврах?» | векторный поиск |
| «Сколько у вас их?» | таблица |
| «Что-то о динозаврах, подходящее для пятилетнего ребёнка» | фильтрация таблицы, ранжирование векторным поиском |
| «Какая ссылка и обложка?» | таблица, дословно |
Вы не определяете поля, но у вас есть последнее слово
Платформа читает несколько ваших документов, предлагает поля, а затем проверяет каждое из них по всей вашей коллекции перед тем, как оставить. Поле, которое встречается только в одной пятой ваших документов, отбрасывается и сообщается об этом, потому что фильтрация по нему молча исключила бы остальные.
Два вида ввода, которые вы предоставляете:
Какие поля должны быть точными. Какая ссылка — та самая ссылка для отправки клиенту, какой из трёх кодов тот самый, который он процитирует вам — ваши данные этого не указывают, и это нельзя вывести. Назовите их заранее, и они будут извлечены дословно и процитированы дословно.
Исправления на обычном языке. «Также отслеживайте автора, чтобы люди могли находить другие его книги.» «Я хочу фильтровать по иллюстратору.» «Удалите ссылку на обложку.» Изменения предлагаются как патч к существующей таблице, а не как переписывание, поэтому запрос об одном поле не может повлиять на другое. Попросите то, чего нет в ваших документах — год публикации, которого никогда не было в экспорте — и она скажет вам об этом, а не добавит пустой столбец.
Что это также рассказывает вам о ваших собственных данных
Поскольку каждое поле измеряется по всей коллекции перед тем, как оно будет принято, отчет регулярно выявляет вещи, о которых никто не знал. В одном реальном каталоге из нескольких тысяч заголовков он обнаружил, что у десятой части из них количество страниц равно нулю — это не короткие книги, а отсутствующие значения, записанные как ноль, что снизило бы каждое среднее значение и создало бы большую ничью для «самого короткого».
Эта проверка должна происходить где-то. Сегодня она обычно происходит, когда клиент замечает неправильный ответ.
Когда это не применимо
Если ваши документы — это проза — статьи, стенограммы, переписка — нечего табличизировать, и платформа отказывается строить индекс, вместо того чтобы создавать один, состоящий из всех разных значений. Таблицу такого типа нельзя посчитать или сгруппировать каким-либо осмысленным образом, и её наличие только спровоцировало бы вопросы, на которые она отвечает плохо.
Векторный поиск остаётся правильным и единственным инструментом для такого материала.
Частые вопросы
- Почему мой агент не может сказать клиентам, сколько у меня товаров?
- Потому что векторный поиск возвращает несколько фрагментов, которые по смыслу похожи на вопрос, и несколько фрагментов нельзя посчитать. Это не проблема настройки — не существует параметра, который заставил бы поиск возвращать общее количество. Структурированный индекс отвечает на вопросы о подсчете, диапазонах и группировке, опрашивая небольшую таблицу, построенную на основе полей, уже содержащихся в ваших документах, в то время как векторный поиск продолжает отвечать на вопросы о смысле.
- Придумает ли агент ссылку или код продукта?
- Нет, если поле помечено как точное. Эти значения вообще не показываются модели: она получает заполнитель, а платформа подставляет сохраненное значение при выводе. Модель не может ошибиться в URL-адресе, который она никогда не видела. Это важнее, чем кажется — распространенная ошибка заключается не в выдуманной ссылке, а в реальной ссылке, принадлежащей другому товару, которая открывается и выглядит корректно.
- Из каких типов документов это можно построить?
- Из документов, имеющих машиночитаемый заголовок: таблицу метаданных, YAML-фронтматтер или строки вида «Поле: значение». Экспорты товаров, каталоги, инструкции к лекарствам, графики политик и списки курсов обычно подходят. Обычный текст не подходит, и платформа сообщит об этом, вместо того чтобы создавать бесполезную таблицу — таблицу значений, которые все разные, нельзя осмысленно посчитать или сгруппировать.
- Мне нужно определять поля самостоятельно?
- Нет. Платформа читает несколько ваших документов и предлагает поля, затем проверяет каждое из них по всей коллекции, прежде чем оставить. Вы можете добавлять, переименовывать или удалять поля впоследствии на обычном языке, а также можете заранее указать, какие поля должны извлекаться точно — название, ссылка, изображение, код — потому то, какую ссылку отправить клиенту, является бизнес-фактом, который ваши данные не указывают.
- Приведет ли добавление этого к повторной обработке моей базы знаний?
- Нет, эмбеддинги не пересчитываются. Поля считываются непосредственно из текста, уже содержащегося в ваших документах, поэтому создание или изменение индекса не требует повторной индексации и не нарушает работу векторного поиска, который уже функционирует.
- Как он остается актуальным, когда я добавляю или удаляю документы?
- Новые документы считываются по мере их импорта, используя уже установленные правила, поэтому ничто не зависит от модели. Сам индекс перестраивается по запросу перед следующим вопросом, который в нем нуждается — добавление тысячи документов не вызывает тысячи перестроек.
Почти всё, что агенту нужно знать, уже где-то записано — на вашем сайте и в тех PDF, которые ваша команда и так рассылает клиентам. Импорт по URL закрывает публичную половину, загрузка файлов — остальное.
Сюжет — это направленный граф, по которому агент ведёт каждого конечного пользователя: каждый узел — это шаг (со своей задачей, знаниями и инструментами), переходы несут условия, а прогресс, профиль и заметки по каждому человеку сохраняются и возобновляются между сессиями и каналами. Он превращает агента из ассистента, выполняющего отдельные задачи, в того, кто сам может оказывать многошаговую услугу.
Динамический планировщик следит за разговором и, когда пользователь решает действительно многошаговую задачу внутри предметной области агента и заметно не понимает, как к ней подступиться, предлагает развернуть эту задачу во временный сюжет — пошаговый план на чек-листах, который агент затем выполняет по одному сфокусированному шагу за раз, показывая пользователю прогресс. Планирование происходит один раз и проходит валидацию; выполнение детерминировано.
Длинное письмо — это агент, создающий полный многосекционный документ — заявление, отчет о выходе на рынок, меморандум по проверке благонадежности — путем предварительного планирования структуры, запроса всего необходимого перед началом, исследования каждой секции на основе ваших материалов и открытых источников и написания секции за секцией в рамках задачи, которая сохраняется после перезапуска. Вы редактируете его в холсте рядом с чатом, переписываете любой фрагмент, выделяя его, и каждая версия сохраняется.