DeepSeek открыла Search и Fetch API для поиска и чтения источников

Search находит страницы, Fetch получает их текст. Объясняем, как собрать проверяемый ответ и почему резюме выдачи не заменяет первоисточник.

DeepSeek открыла Search и Fetch API 17 октября 2026 года. Это два инструмента для приложений, которым нужны сведения из интернета: первый находит страницы, второй получает текст выбранного источника. Для ИИ-агентов и RAG-систем важен весь путь: сформулировать запрос, выбрать ссылку, прочитать материал и проверить, действительно ли он подтверждает ответ.

О запуске компания сообщила в журнале изменений. Ниже — разбор документации и учебного примера. Редакция не запускала платные API и не измеряла качество поиска; публичные страницы первоисточника проверены отдельно.

Путь от поискового запроса через Search и Fetch к проверке текста первоисточника
Поиск, извлечение текста и проверка — разные этапы работы с источником. Концептуальная иллюстрация, созданная ИИ.

Что дают Search и Fetch агенту

Search возвращает структурированную выдачу: названия страниц, адреса и дополнительные сведения. Fetch работает с конкретным URL и отдаёт заголовок и содержимое страницы в Markdown. Оба интерфейса принимают JSON; адреса методов — POST https://api.deepseek.com/v1/tools/search и POST https://api.deepseek.com/v1/tools/fetch. Описание форматов есть в справочнике Search и справочнике Fetch.

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

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

Как читать результат Search API

В ответе Search есть snippet — короткое описание для интерфейса, summary — более развёрнутое резюме для модели, и content — содержимое страницы. Если need_content выключен, content пуст; даже при включённом параметре текст может оказаться недоступен. Поэтому отсутствие содержимого нельзя заменять пересказом так, будто приложение уже прочитало оригинал.

У результата также есть оценки rerank_score и authority, а дата может отсутствовать. Это полезные признаки для сортировки, но не независимое подтверждение достоверности. Высокая оценка не отвечает на вопрос, относится ли найденная фраза к нужной версии продукта и не изменилась ли страница после публикации. Поля и допустимые значения описаны в схеме ответа Search.

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

Учебный разбор официального примера

В руководстве Search & Fetch запрос «DeepSeek V4 release» сопровождается параметрами count: 5 и need_content: true. Первый задаёт желаемое число результатов, второй просит вернуть содержимое. Это образец запроса из документации, а не выполненный редакцией поиск.

Показанный рядом JSON использует адрес https://example.com/deepseek-v4 и условные сведения о релизе. Его задача — показать структуру ответа. Дату 2026-06-01 и название страницы из этого образца нельзя переносить в новость как установленный факт. Точно так же пример Fetch с example.com/article не доказывает, что сервис успешно прочитал реальную статью.

Если строить на этой схеме проверку новости, последовательность будет такой:

  1. Сузить вопрос. Искать дату открытия Search и Fetch, а не любое упоминание DeepSeek. Оператор site: позволяет направить поиск на официальный домен.
  2. Выбрать источник. Сопоставить заголовок, URL и описание; для даты выпуска предпочесть запись в журнале изменений.
  3. Получить текст. Использовать доступный content или обратиться к Fetch для выбранного URL. Проверить, что получен нужный раздел страницы.
  4. Сверить утверждение. Найти в тексте дату и событие, затем сохранить ссылку вместе с выводом. Если подтверждения нет, оставить вопрос открытым.

Это рекомендуемый порядок работы приложения. Он не описывает результат нашего запуска DeepSeek API.

Что подтвердила ручная проверка первоисточника

При подготовке материала мы отдельно прочитали публичный журнал изменений DeepSeek. В разделе за 17 октября 2026 года есть запись об открытии собственного поискового API и ссылка на руководство Search & Fetch. В официальном анонсе того же дня оба интерфейса названы доступными всем. Это подтверждает событие и дату, но не позволяет оценить полноту выдачи или скорость извлечения страниц.

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

Так выглядит полезный результат поиска с проверкой: не просто несколько ссылок, а объяснение, какая страница подтверждает конкретную часть ответа.

Какие ограничения заложить в приложение

Fetch зависит от доступности сайта и его правил доступа. Согласно руководству, сервис может не получить пригодный текст, а превышение лимита вызывает ошибку 429. Для Search и Fetch установлены отдельные лимиты по пять запросов в секунду на аккаунт; у Fetch есть дополнительное ограничение по домену.

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

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

Сколько стоит этот путь к источнику

На 18 октября каждый прямой API стоит $0,75 за 1000 успешных запросов. Search оплачивается при непустой выдаче, Fetch — при получении содержимого; неудачные запросы и пустой поиск не тарифицируются. Количество результатов в одном Search-запросе не меняет его цену.

Временная бесплатность относится к серверным вызовам инструментов через DeepSeek Harness, Claude Code и Codex при использовании DeepSeek API. Начало оплаты — 1 ноября 2026 года в 00:00 по Пекину, или 31 октября в 16:00 UTC. Это не бесплатность прямых API или токенов модели. Условия приведены на странице тарифов DeepSeek.

Обновление самой модели мы разобрали в новости о DeepSeek V4.1 Flash 1017. У Search и Fetch другой практический смысл: разработчик получает отдельные шаги работы с источником и может явно показать пользователю, где поиск закончился, а проверка только началась.

Понравилась статья? Поделиться с друзьями:
GPT Insider