AI-поиск с источниками должен сначала собрать проверяемые доказательства, а уже затем формулировать вывод. Надёжный ответ связывает каждое существенное утверждение с конкретной страницей, учитывает дату и сообщает, когда подтверждений недостаточно. Обычной передачи первых ссылок из выдачи в большую языковую модель для этого мало.
Почему «поиск плюс LLM» часто ошибается
Поисковая выдача оптимизирована для навигации, а не для готового ответа. Сниппет может быть обрезан, собран из разных частей страницы или уже не соответствовать актуальному тексту. Первые позиции могут повторять один первичный источник, пересказывать друг друга или отвечать на соседний вопрос.
Языковая модель сглаживает пробелы убедительным текстом. Если дать ей слабые фрагменты без правил, она способна соединить несовместимые даты, принять рекламное обещание за факт или приложить ссылку, где нужного утверждения нет. Поэтому система должна разделять поиск кандидатов, чтение документов, отбор доказательств и генерацию.
Базовый конвейер ответа
Практическая архитектура состоит из шести этапов:
- Нормализовать вопрос и выделить ограничения: период, регион, тип источника.
- Сформировать несколько поисковых запросов для разных формулировок намерения.
- Получить кандидатов, удалить дубли доменов и канонических URL.
- Прочитать страницы, извлечь основной текст, дату и метаданные.
- Пересортировать фрагменты по смысловой близости и качеству источника.
- Сгенерировать ответ только по выбранным фрагментам и вернуть ссылки рядом с утверждениями.
Такой конвейер делает ошибку наблюдаемой. Можно понять, не нашёлся ли документ, не извлёкся ли текст, потерялся ли важный фрагмент при rerank или модель вышла за пределы контекста.
LLMTOKENAPI предоставляет два уровня. POST /v1/search возвращает нормализованную выдачу для собственного конвейера, а POST /v1/answer формирует ответ с проверяемыми цитатами. Возможности, режимы глубины и scopes описаны в документации.
Формируйте несколько запросов
Один пользовательский вопрос не всегда совпадает с языком первоисточника. Запрос «сколько стоит API» может требовать официального прайса, страницы документации и условий тарифа. Разложите его на сущность, измерение и период. Для сравнительного вопроса добавьте отдельный запрос по каждому объекту, а затем запрос на официальное сравнение.
Ограничивайте расширение. Пять осмысленных вариантов полезнее двадцати почти одинаковых. Сохраняйте связь результата с исходным запросом: она пригодится при анализе того, какой вариант действительно принёс доказательство.
Если ответ зависит от текущего состояния, передавайте временной фильтр и проверяйте дату самой страницы. Дата публикации и дата события — не одно и то же. Новая статья может описывать старые данные, а давно созданная официальная страница может обновляться без смены URL.
Отбирайте источники, а не только фрагменты
Смысловая близость не равна достоверности. Документ может идеально повторять вопрос и при этом быть автоматически сгенерированным пересказом. Добавьте признаки качества:
- первичный ли это источник для утверждения;
- указаны ли автор, дата и метод получения данных;
- можно ли найти подтверждающий фрагмент на странице;
- совпадает ли регион и период;
- независимы ли источники друг от друга;
- нет ли явного конфликта интересов.
Для спецификации продукта предпочтительна официальная документация. Для научного вывода — исходная публикация. Для новости — заявление участника и независимое подтверждение. Пользовательские отзывы полезны для опыта использования, но не заменяют технические характеристики.
Привязывайте цитату к утверждению
Список ссылок внизу не показывает, какая из них подтверждает конкретную фразу. Храните для каждого доказательства URL, заголовок, извлечённый фрагмент и время доступа. Во время генерации разрешайте ссылаться только на выданные идентификаторы источников. После генерации проверьте, что каждый идентификатор существует, а существенные факты имеют опору.
Не заставляйте модель цитировать дословно большой фрагмент. Для проверки достаточно короткого подтверждающего текста, а пользователю лучше показать ясный вывод и прямую ссылку. Если два надёжных источника расходятся, ответ должен назвать расхождение, а не усреднять значения.
Научите систему отказываться от ответа
Корректный результат иногда звучит как «данных недостаточно». Введите минимальный порог: количество независимых подтверждений, качество источника, свежесть и смысловая близость. Для одного официального факта может хватить одного первичного документа; для спорного рыночного вывода потребуется несколько независимых материалов.
Отказ должен быть полезным. Сообщите, что именно не удалось подтвердить, какие ограничения применялись и какие найденные источники всё же релевантны. Это лучше, чем уверенная догадка с формально существующей ссылкой.
Измеряйте качество по слоям
Одна оценка финального текста не объясняет проблему. Соберите отдельные метрики:
- recall поиска: найден ли документ с ответом;
- качество извлечения: присутствует ли нужный фрагмент;
- precision rerank: сколько верхних фрагментов действительно полезны;
- citation correctness: поддерживает ли ссылка утверждение;
- citation completeness: все ли важные факты подтверждены;
- answer correctness: верен ли итоговый вывод;
- стоимость и задержка одной успешной операции.
Создайте небольшой набор вопросов с проверенными источниками и регулярно запускайте его после изменения запросов, модели или правил отбора. Дополните его реальными неудачными вопросами из эксплуатации, не сохраняя чувствительные данные.
Надёжный AI-поиск — это не один особенно удачный промпт. Это проверяемая цепочка, где каждый этап оставляет понятный результат, а финальный текст ограничен найденными доказательствами.
