DeepSeek Search & Fetch API: что проверять перед подключением поиска к ассистенту
17 октября DeepSeek сообщил о запуске Search & Fetch API на базе собственного поискового движка. В описании указаны веб-поиск и получение содержимого страниц, многоязычная выдача, а также фильтрация части низкокачественных материалов. Это отдельный инструментальный слой: он не является новой языковой моделью и сам по себе не превращает ответ в проверенную справку.
Главный вопрос при выборе такого API — не «умеет ли он искать в интернете», а насколько предсказуемо он возвращает материалы для вашей задачи. Для пользовательского ответа важны свежесть, доступ к нужным сайтам, устойчивость к дублям, извлечение основного текста и понятная связь между утверждением и источником. Прежде чем подключать сервис к продукту, проверьте каждый пункт на собственном наборе запросов.
Поиск и извлечение — разные этапы
Поисковая часть находит кандидатов по запросу и ранжирует их. Fetch-часть пытается получить содержимое выбранной страницы. Ошибки могут возникнуть на любом этапе: выдача может не включить важный документ, ранжирование поставить выше похожую, но старую страницу, а извлечение — пропустить таблицу, примечание или блок с датой. Поэтому наличие URL в ответе ещё не означает, что ассистент корректно прочитал страницу.
Для ответа с фактами полезно хранить не только список ссылок, но и фрагменты текста, дату обращения, заголовок и причину выбора. Затем модель должна формулировать вывод только на основании этих фрагментов. Если в источниках расхождение, интерфейс должен показать его, а не сгладить до одного уверенного предложения. Так проще отделить факт документа от интерпретации модели.
Как устроить короткий пилот
Соберите 30–50 запросов из реальных сценариев. Добавьте простые вопросы, редкие термины, русский и английский варианты, запросы с названием организации и случаи, где страница недавно обновлялась. Для каждого запроса заранее отметьте ожидаемые первичные страницы, допустимый возраст материала и факты, которые должны попасть в ответ. Не используйте только популярные темы: они часто дают хорошую выдачу у любого поискового решения.
Сравните результаты по четырём отдельным критериям: нашёл ли сервис нужный документ, правильно ли извлёк его содержание, не потерял ли дату и можно ли восстановить путь от тезиса до исходного фрагмента. Отмечайте пустой результат отдельно от неверного. Пустой результат может безопасно остановить ответ; неправильный текст, поданный уверенно, опаснее.
Проведите тест не только на обычных страницах. Добавьте PDF, страницы с длинными таблицами, динамический контент и материалы, в которых есть обновлённая дата. Проверьте, как система ведёт себя при блокировке сайта, тайм-ауте и повторном запросе. Если внешняя страница недоступна, ассистент не должен незаметно подменять её пересказом из случайной выдачи.
Что измерять кроме «релевантности»
Полезно считать долю запросов, где первичный документ попал в первые результаты; долю извлечённых страниц с верным основным текстом; частоту устаревших дат; количество дублей; и долю ответов, где все проверяемые утверждения связаны с конкретным фрагментом. Отдельно оцените задержку и стоимость на полный сценарий: повторные поиски и длинное извлечение могут изменить экономику продукта.
Проверьте и качество отказа. На части запросов правильный результат — сказать «не нашёл достаточного подтверждения». Если система всегда выдаёт абзац, она может маскировать нехватку доказательств. В пилоте задайте минимальное число независимых подтверждений для значимых фактов и правила для конфликтующих дат или цифр.
Ограничения заявления разработчика
Поставщик описывает движок как масштабный, многоязычный и фильтрующий спам. Это полезные ориентиры, но они не заменяют независимую оценку на вашей тематике. Формулировка об индексации большого количества страниц не гарантирует доступность любой страницы, полноту региональной выдачи или корректность извлечённого текста. До включения в публичный продукт проверьте условия использования, лимиты, логирование запросов, хранение данных и доступность функции в нужном регионе.
Не отправляйте в веб-поиск конфиденциальные сведения, внутренние идентификаторы клиентов или незакрытые документы, если условия сервиса и ваша политика данных этого не разрешают. Для закрытого корпуса внешняя поисковая API может быть неправильным местом хранения или обработки.
Когда инструмент уместен
Search & Fetch API стоит проверять, если продукту нужно находить открытые веб-страницы и передавать их содержание модели. Для внутренней базы с контролем доступа чаще важнее собственный индекс и фильтрация по правам, чем широкий веб-поиск. Для точных повторяемых справок надёжнее может оказаться заранее утверждённый набор документов. Выбор зависит от того, кто отвечает за источник, насколько важна свежесть и как продукт показывает доказательства.
Вывод. Появление API делает поиск и загрузку страниц отдельным доступным инструментом в экосистеме DeepSeek, но качество итогового ответа будет зависеть от ранжирования, извлечения, промпта и проверки человеком. Сначала измерьте работу каждого этапа на собственных запросах; затем ограниченно включайте функцию и наблюдайте за ошибками.
FAQ
Это новая модель DeepSeek? Нет, 17 октября компания объявила об открытии поискового API и одновременно сообщила об обновлении уже существующей Flash-модели. Гарантирует ли API правдивый ответ? Нет, он помогает находить и извлекать материалы; проверка фактов остаётся отдельным этапом. Что такое Fetch? Получение содержимого найденной страницы для последующей обработки. Как понять, подходит ли сервис? Сравнить результаты с размеченной выборкой и проверить ошибки извлечения, свежесть, задержку и отказ при нехватке данных.
Связанный контекст есть в нашем чек-листе приёмки ответа агента и разборе оценки облачных рабочих представлений.