Обоснованные ответы

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

От файла к фрагменту

Ингест: один раз для документа

Запрос: один раз на вопрос

Загруженный документ преобразуется в текст, разбивается на фрагменты, встраивается и сохраняется в зашифрованном виде. Два момента при разбивке важнее, чем кажется.

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

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

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

Рисунки, а не только текстовый слой

Большая часть извлечения документов останавливается на текстовом слое. Загрузите техническое описание, руководство по установке или отчёт, и типичный конвейер вытянет прозу и молча опустит всё, что было нарисовано, а не набрано — схему подключения, макет платы, диаграмму посередине страницы. Файл был «обработан»; половина того, что в нём говорилось, никогда не была прочитана. Спросите "какой заголовок у вентилятора процессора", и ответа не будет в индексе, потому что он был только на картинке.

Эта платформа читает и их.

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

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

Заголовок контекста

Фрагмент, встраиваемый сам по себе, теряет факт того, что он происходит из конкретного документа. "Пункт 7.2 применяется, когда заёмщик находится в дефолте" плохо извлекается, когда запрос звучит как "что произойдёт, если я пропущу платёж по продукту моста" — фрагмент никогда не говорит, к какому продукту он принадлежит.

Перед встраиванием каждый фрагмент префиксируется контекстным заголовком — названием документа и, опционально, ситуационной заметкой, сгенерированной LLM, — чтобы вектор отражал как отрывок, так и то, к чему он относится. Сохранённый текст не изменяется; только входные данные для встраивания несут заголовок.

Переписывание запроса: часть, которую пропускают большинство систем

Качество поиска обычно обсуждается как проблема ранжирования. Часто это не так — часто запрос просто не содержит информации.

Клиент спрашивает "и какова ставка по тому?". Местоимение относится к чему-то, сказанному двумя репликами ранее. Встраивание этого предложения производит вектор, который близок ни к чему конкретному, и поиск для этой реплики близок к случайному. Никакое переупорядочивание не исправит это, потому что сигнала никогда не было.

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

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

Поиск и порог релевантности

Затем лучшие совпадения фильтруются по максимальному расстоянию. Это та часть, которая отделяет полезного агента от уверенного:

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

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

Когда поиск успешен, но всё равно терпит неудачу

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

Измерено на собственном предпродажном агенте этого сайта. Запрос "если я на Starter и мой рост использования составляет 30% в месяц, сколько я заплачу через шесть месяцев", поиск вернул три отрывка: страница плана Starter, руководство по использованию токенов и условия обслуживания. Все релевантные. Ни один из них не указывает цену — страница плана — это страница о том, для кого предназначен план. Получив документ с названием "Starter" без числа в нём, модель предоставила одно. За пять запусков она выдала $5, $250, $99, $0 и $29, каждый с маркером цитирования прикреплённым. Реальная цифра — $49.

Ничего не потерпело неудачу таким образом, который можно было бы обнаружить. Расстояния были в порядке, поэтому не было промаха поиска для отчёта. Цитирование указывало на отрывок, который действительно был извлечён. Только ответ был неверным.

Второй проход, решённый в коде

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

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

Есть ли сторона того, о чём спрашивают? Это та половина, которую пропускает первая проверка, и та половина, на которую указало измерение выше: Starter был в извлечённом тексте; цены не было. Поэтому каждый вопрос также сопоставляется с тем, о чём он спрашивает для. Некоторые из них имеют жёсткие форматы — цены имеют знак валюты, длительности имеют единицу времени, контактные данные выглядят как email или URL — и материал, который действительно охватывает эту сторону, почти никогда не пропускает формат. Другие (возвраты, соответствие требованиям, пробные периоды, интеграции) не имеют формата, поэтому сигнал — это слово темы само по себе, прописанное на каждом языке, а не оставленное на усмотрение векторного сходства для моста.

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

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

Когда вопрос называет номер статьи

Семантическая близость — неподходящий инструмент для ссылки. «Статья 18», «Часть 9», «ISO 9408» — они ничего не значат; они опознают. Две строки таблицы стандартов, различающиеся одной цифрой, для эмбеддинга — одно и то же предложение.

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

Из обращения с идентификатором как с тождеством, а не значением, следуют два вывода:

Когда идентификатор встречается в большем числе мест, чем помещается в контекст, ссылка больше не отбрасывается. Раньше отбрасывалась: если «Статья 18» совпадала с бо́льшим числом фрагментов, чем влезало, вся группа выкидывалась по логике «выборка — не ответ». Это верно, если брать первые попавшиеся в порядке файлов. И неверно, если брать ближайшие к вопросу. В одном измеренном случае при такой сортировке два фрагмента с ответом оказались на косинусном расстоянии 0,27 и 0,31, а шум начинался с 0,51 — так что сам разрыв говорит, где остановиться, и порог угадывать не нужно. Когда расстояния образуют плавный склон, а не ступеньку, не спасается ничего: равномерный разброс означает, что фрагменты неразличимы, и это действительно выборка.

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

Когда модель сама просит больше материала

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

Следующая порция уже на руках. Поиск достаёт более широкий пул кандидатов, чем показывает, ранжирует его один раз и показывает верх; остальное придерживается ровно для этого момента. Отдать её не стоит ни второго поиска, ни второго ранжирования, ни второй проверки релевантности — только тот вызов модели, который и так происходил. Первая реализация всё же перезапускала поиск, и на одном вопросе это превратило 22 секунды в 71; так измеряется цена «посмотреть ещё раз», а не предполагается.

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

Расшифровка происходит последней

Содержимое фрагментов хранится в зашифрованном виде для каждого пространства. Только те фрагменты, которые действительно совпали, расшифровываются, с шифром, загруженным для этого арендатора и пользователя — поиск работает с векторами, а открытый текст появляется только для отрывков, которые вот-вот будут использованы.

Число — не значение

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

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

Эта строка появилась в 1 480 из 1 500 фрагментов в реальном каталоге клиента:

Reading level: 1 · Age: 5 · Words: 1951

И "какие книги подходят для ребёнка, только начинающего читать самостоятельно" вернули книгу о музыкальных вундеркиндах. 1 не имеет никакого сходства с beginner reader так же, как одно слово напоминает другое.

Добавление одного предложения рядом со значением исправило это, измеренное на этой записи:

Reading level: 1 · Age: 5
Suitable for around age 5, for children just starting to read on their own.

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

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

Одна вещь, которая не стоит усилий, потому что мы измерили это: экспорты часто повторяют себя ( summary и description с идентичной прозой). Удаление дублирования изменило расстояние встраивания на +0.002 across 60 records — ничего. Встраивание — это направление, а не бюджет, который использует повторяющийся текст.

Расстояние — не оценка, и оно не сопоставимо между моделями

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

Два практических следствия:

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

Что поиск не может сделать, и что отвечает на эти вопросы вместо этого

Всё выше — о нахождении отрывка, который отвечает на вопрос. Три вида вопросов не касаются отрывка вообще, и никакая настройка не заставит поиск сходства ответить на них:

• Подсчёт — "сколько у вас есть", "сколько из них нехудожественные"
• Числовая фильтрация — "какие из них меньше 200 слов", "между 1000 и 2000"
• Группировка — "сколько на категорию", "какой автор встречается чаще всего"

Они терпят неудачу таким образом, который легко упустить. Спросив "есть ли какие-то около 500 слов", агент с только векторным поиском сообщит о том, какая запись случайно оказалась в его топ-нескольких — истинное утверждение о четырёх документах, представленное как утверждение о коллекции.

Структурированный индекс

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

С ним агент выбирает инструмент, который подходит для вопроса:

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

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

Почему ссылка в ответе раньше принадлежала неправильному элементу

Есть второй, более тихий сбой, который исправляет та же таблица.

Поиск возвращает фрагменты, но заголовок, код продукта, ссылка и изображение живут в документе заголовке — то есть, в фрагменте 1, в то время как отрывок, ответивший на вопрос, может быть фрагментом 7. Так что модель получает четыре или пять фрагментов из трёх или четырёх документов и должна выяснить, какая ссылка принадлежит какому заголовку.

Когда она делает это неправильно, ничто не выглядит неправильно. Ссылка реальна, она открывается, изображение рендерится — оно просто принадлежит другому элементу. В каталоге из 4 500 документов 11 из 20 тестовых ответов сопоставили заголовок со ссылкой другого документа.

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

Какую ссылку отправить клиенту — это бизнес-факт, который ваши данные не указывают, поэтому вы называете эти поля сами; всё остальное предлагается вам. Подробнее в Structured index.

Когда ваши материалы действительно не имеют ответа

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

Он выключен, пока вы его не включите, и три вещи верны, когда он включён.

Чтение страницы — это часть этого, а не дополнительное. Результат поиска — это заголовок и двухстрочное резюме, и значимые цифры — период действия, комиссия, срок — обычно только в теле. Одна страница в нашем наборе оценки гласит "действительно в течение пяти лет" в своём фрагменте и "продление до: 9 месяцев" только на самой странице. Получив только резюме, модель имеет подсказку без факта, и заполняет пробел из памяти. Так что один переключатель включает как поиск, так и чтение; включение только поиска измеримо является худшей конфигурацией, а не более консервативной.

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

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

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

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

Что записывается при вашем утверждении — свежая запись, переписанная из вопроса и материала — а не ответ, который получил посетитель. Ответ был адресован одному человеку и сформирован этим разговором: он открывается с их именем, ссылается на "ваши продуктовые линии" и заканчивается призывом к действию. Зафиксированный дословно, частный контекст одного посетителя становится ответом для всех. Так что запись регенерируется без любого из этого, с заголовком, написанным из материала, а не из вопроса — вопрос, сформулированный "…о моём продукте", — это заголовок, который тихо переносит чей-то контекст в место, где заголовки имеют большой вес в поиске. Email-адреса и телефонные номера маскируются перед тем, как что-либо сохраняется. Вы видите переписанную запись, редактируете её, если хотите, и утверждаете это.

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

Число, о котором мы хотели бы, чтобы вы знали

Измерено на 24 вопросах, которые база знаний действительно не могла ответить, запущенных три раза: ответы, прослеживаемые к реальному источнику, увеличились с 8% до 33%, и цифры, которые мы не могли отследить ни к какому источнику, упали с 13 до 6. Это второе число не ноль. Примерно один ответ из двенадцати всё ещё несёт цифру, которую мы не можем учесть, поэтому проверка факта поставляется вместе с функцией, а не после неё, и почему очередь проверки существует вообще.

Что это означает на практике

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