Один ответ, который придётся объяснить: как проектировать ИИ-поиск

Пользователь просит ChatGPT найти свежие правила для онлайн-платформ. Сервис обращается к вебу, выбирает источники, собирает ответ и показывает ссылки. На экране — чат-бот. Внутри — информационный поиск.

31 августа 2026 года Еврокомиссия признала ChatGPT очень крупной онлайн-поисковой системой по DSA. Поводом стала функция веб-поиска: ChatGPT сам выбирает источники и собирает из них ответ.

Я Антон Фокин, CEO Qtim. Мы проектируем ИИ-поиск и RAG-системы. В одном из наших проектов мы сделали RAG-консультанта для магазина дверей. Он работал только с каталогом: уточнял размеры и требования, подбирал товары и объяснял выбор. Сложные запросы передавал менеджеру вместе с собранным контекстом. Этот кейс показывает, какой контроль нужен даже закрытой системе — и что меняется, когда к ней добавляют поиск в интернете.

Один ответ скрывает четыре решения внутри продукта

Обычный поисковик показывает выдачу: человек сам открывает страницы и сравнивает информацию. ИИ-поиск проходит этот путь внутри продукта и отдаёт готовый текст со ссылками.

У этой цепочки как минимум четыре слоя:

1. система интерпретирует вопрос и решает, нужен ли поиск в интернете;
2. поисковый контур формирует запросы и отбирает документы;
3. модель выбирает фрагменты, разрешает противоречия и собирает ответ;
4. фильтры, правила продукта и персонализация меняют то, что увидит пользователь.

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

Проверяемость закладывают до релиза

DSA требует от крупнейших сервисов оценивать системные риски, проходить аудит и обеспечивать надзор. Для ChatGPT требования начнут действовать в январе 2027 года. Значит, журналы событий, версии компонентов и источники нужно связывать до релиза: восстановить ход ответа задним числом не получится.

Решение касается ChatGPT и не переносит обязанности DSA на все ИИ-продукты. Сам регламент применяется к посредническим сервисам, которые предлагаются пользователям в ЕС, независимо от страны провайдера.

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

Аудит начинается до релиза крупной функции

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

Перед крупной функцией нужно связать четыре объекта:

1. сценарий пользователя и группы, которых он затрагивает;
2. риск и измеримый сигнал, по которому его можно заметить;
3. меру снижения риска: ограничение, дополнительную проверку, изменение интерфейса или правил;
4. план выпуска: тестовую группу, мониторинг, условие остановки и откат.

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

Карточка риска должна ссылаться на версию релиза, метрика — на панель мониторинга, решение о запуске — на ответственного человека или роль. Функциональный флаг и сценарий отката надёжнее обещания «быстро выключим»: оно не исполняется через API.

Финальный текст не объяснит, почему система ответила именно так

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

Для расследования нужен общий идентификатор запроса. Он связывает последовательность событий:

1. какая версия модели и инструкции работала;
2. почему система запустила поиск или другой инструмент;
3. какие запросы отправила и какие источники получила;
4. какие политики и фильтры сработали;
5. какой ответ увидел пользователь и какие ссылки были показаны;
6. было ли вмешательство человека, повторный запуск или откат.

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

Доступ к данным нельзя достроить за выходные

Для крупнейших платформ DSA требует отдельного контура доступа к данным для надзора и исследований.

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

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

Такой контур редко создают за один спринт: его сложность зависит от истории данных в сервисе.

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

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

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

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

1. Контекст пользователя. Система работает только с тем, что человек передал в запрос. Нужны версия модели, базовый журнал ошибок и понятная граница хранения данных.
2. Закрытая база знаний. Появляются идентификаторы документов, контроль прав, ссылки на источники, тесты качества поиска и возможность удалить устаревший материал из индекса.
3. Открытый веб и публичная аудитория. Добавляются история поисковых запросов, состав источников, контроль разнообразия выдачи, сценарии вредных ответов, поэтапный выпуск и быстрый откат.
4. Большой масштаб или чувствительные последствия. Нужны формализованная оценка рисков, независимая проверка, воспроизводимые отчёты и отдельный контур доступа к данным.

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

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

Перед выпуском ИИ-функции мы задаём команде пять вопросов:

1. в каком информационном контуре работает система: запрос пользователя, корпоративные документы, партнёрские источники или открытый веб;
2. на каком этапе продукт выбирает источники и может сузить картину для пользователя;
3. можно ли восстановить цепочку от запроса до ответа с версиями модели, инструкций и правил;
4. какие группы пользователей и виды вреда затрагивает функция, а по какому сигналу команда заметит проблему;
5. кто сможет проверить решение через месяц и какие данные ему будут доступны.

Эти ответы показывают объём продукта. Закрытой базе достаточно идентификаторов источников и версионирования. Открытый веб потребует журнала решений, контура проверок и плана остановки функции.

Пользователь видит диалог. Команда должна видеть цепочку решений

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

Мы разрабатываем ИИ-чатботы, RAG-системы и интеграции языковых моделей. На разборе ИИ-проекта можем определить уровень контроля, который нужен вашему сценарию, и заложить его в архитектуру до масштабирования.