Гайд · TNWS AI

Как добавить веб-поиск в OpenAI Responses API и сохранить источники

OpenAI APIPythonNode.jsChatGPT#OpenAI API #веб-поиск #источники

12 сентября 2026 5 мин—

Практическая настройка web_search в Responses API: запрос, список источников, проверка цитат и обработка неполных данных.

Что даст этот гайд

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

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

Что подготовить до начала

Понадобятся ключ OpenAI API в переменной окружения, тестовый проект и вопрос, для которого известен официальный первоисточник. Работайте сначала на тестовой копии. Удалите пароли, ключи, персональные данные и закрытые документы, если их обработка не согласована. Секреты храните в переменных окружения или менеджере секретов.

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

Пошаговая настройка

Создайте запрос через Responses API и добавьте в массив tools инструмент типа web_search. В инструкции задайте стандарт источников: приоритет официальным страницам, дата каждого изменяемого факта, отдельная пометка для противоречий. Не полагайтесь только на готовый текст ответа.

Чтобы получить полный список использованных страниц, запросите включение данных web_search_call.action.sources, если этот параметр доступен в вашей версии SDK. Обработчик должен сохранить URL, заголовок и связь с конкретным утверждением. Ограничьте число вызовов инструмента через max_tool_calls, когда процесс должен иметь предсказуемую границу. После ответа откройте минимум два источника вручную и убедитесь, что дата публикации и смысл совпадают с выводом.

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

Готовый промпт

Замените значения в квадратных скобках и сохраните получившуюся версию рядом с тестами:

Найди актуальный ответ на [ВОПРОС]. Используй прежде всего официальные первоисточники. Для каждого изменяемого факта укажи дату и URL. Если источники расходятся, покажи обе версии. Не делай вывода по одному сниппету поисковой выдачи.

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

Практический пример

Вход

Вопрос: «Какие форматы файлов сейчас поддерживает функция загрузки в сервисе X?» Известна официальная страница справки производителя.

Ожидаемый результат

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

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

Проверка результата в три прохода

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

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

Чек-лист

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

Как сделать процесс полезнее

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

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

Минимальный журнал качества

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

Ограничения

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

FAQ

Можно ли сразу подключать рабочие данные?

Нет. Сначала прогоните сценарий на обезличенной копии, проверьте ошибки и права. Рабочие данные подключайте только после согласования режима обработки.

Почему недостаточно успешного статуса API?

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

Что делать, если ответ меняется между запусками?

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

Как обновлять такой процесс?

После изменения SDK, модели, схемы или источника повторите весь набор тестов. Сравните результаты построчно и сохраните причину принятого изменения.

Первоисточник и дата проверки

Функции и названия параметров сверены 11 сентября 2026 года: документация OpenAI по Web Search. Численные тарифы и лимиты намеренно не приведены: их следует проверять на официальной странице непосредственно перед использованием.

Частые вопросы

Можно ли использовать рабочие данные сразу?

Сначала проверьте сценарий на обезличенной копии и согласуйте обработку данных.

Достаточно ли статуса 200?

Нет. Он подтверждает обработку запроса, но не корректность фактов и действий.

Как тестировать обновления?

Повторяйте одинаковый набор обычных, пустых, противоречивых и запрещённых сценариев.

Где хранить ключ API?

В переменной окружения или менеджере секретов, но не в коде и промпте.