Всем привет, дорогие друзья! Мы рады всех вас видеть на нашем сегодняшнем вебинаре. Он
называется «Как научить Агентов искать информацию в интернете и проводить исследования».
С вами сегодня буду я, как Авина Анна, ML Tech Product, да, и Сережа Нарбут.
Да, который является руководителем группы разработки EA Studio.
Все так. А я ML Tech Product Manager в Яндексе EA Studio. Мы с вами двигаемся дальше. Давайте с вами поговорим о том, что мы сегодня расскажем.
Первая часть вебинара будет такая. Для нашего всеобщего понимания контекста я немного расскажу о сценариях, которые реализуют пользователи EA Studio совместно с поисковыми сценариями в своих EA агентах.
Еще я расскажу про продукты, которые есть в Яндекс.Б2Б для поиска и поисковых сценариев. В основном, конечно, для EA агентов, но не только.
И вторая часть вебинара будет по-настоящему про уровня. На ней Сережа расскажет про подходы к Deep Research, архитектуру и то, как мы реализовывали Deep Research в наших инструментах.
Все верно.
Давайте стартовать, начинать. Мне кажется, самое время поговорим, как я уже сказала, о сценариях, которые реализуют пользователи в Яндекс.Ей Студио.
Конечно, самый частый кейс – это клиентская поддержка. Клиентская поддержка нужна большим клиентам, B2B клиентам, собственно, интерпрайз-компаниям.
Но также клиентская поддержка нужна и небольшим компаниям. Все ее хотят автоматизировать, потому что, как правило, это самый финансово выгодный кейс внедрения AI и автоматизации.
Но если мы с вами подумаем внимательно и посидим, поразмышляем, что такое автоматизация клиентской поддержки, то поймем, что это либо работа с пользователями в чате,
соответственно, нужно очень хорошо управлять контекстом.
Если мы автоматизируем эту часть работы, наш агент должен отвечать на вопросы пользователей, о нашем сервисе, о нашем продукте,
а еще, может быть, мы хотим сделать какой-то помощник для уже существующего сотрудника клиентской поддержки.
Ну и в таком случае, соответственно, он поможет этому сотруднику отвечать быстрее, тоже сможет искать по внутренней базе знаний и разбирать обращения.
Еще часто наши клиенты реализуют корпоративных ассистентов. Это такие ассистенты внутри компании, которые помогают не только сотрудникам клиентской поддержки, но и в целом сотрудникам компании быстрее реализовать свои задачи и комфортнее работать.
Искать по внутренним регламентам, например, искать, как корректно взять отпуск, как поступить в той или иной ситуации по регламентам компании. И также координируют по внутренним процессам, помогают им и выступают некоторыми такими персональными помощниками, например, по календарю сотрудника.
Еще, наверное, частый кейс — это работа с документами. На самом деле, вообще, это топ-2 кейс после кариенской поддержки. Автоматизация документа оборота — это, кажется, такая очень понятная для автоматизации, для применения AI-сферы. И здесь тоже нам помогают поисковые сценарии. Без них вообще никак.
Например, у вас есть большая стопка документов, PDF, каких-то сложных, может быть, какой-то невероятной строительной документации. И вот по ней вам нужно найти, как конкретно должен быть реализован тот или иной проект.
Ну и, соответственно, здесь, конечно, вам нужен поиск, либо вы хотите автоматизировать подготовку писем, каких-то отчетов. Ну и, соответственно, здесь тоже есть место поисковым сценариям.
Ну и еще один интересный кейс, который на самом деле более массово стал применяться у клиентов EA Studio только недавно, это B2C-консультанты. Это так называемые EA-агенты, которые общаются с клиентами нашего B2B-клиента.
В качестве примера можно привести, пожалуй, ритейл. Вот представляете, когда вы приходите в магазин техники и выбираете себе пылесос, хотите вы пылесос себе выбрать, да? Вы смотрите на разные модели, может быть, общаетесь с сотрудником, сравниваете две модели и, собственно, принимаете решение.
В нашу цифровую эпоху ИИ эту задачу может выполнить ИИ-ассистент, конечно, если у него есть хороший поиск под капотом, он должен понять, а что за модель пылесоса вы хотите купить, сравнить с какой-то еще другой, например, найти отзывы на нее в интернете и вас проконсультировать.
Собственно, это такие core сценарии, в которых нужен поиск. Ну и тут я, конечно, не называю различных и ассистентов, которые заточены под поисковый сценарий, кажется, это совершенно понятно, которые реализуют разные маркетинговые исследования или мониторинг конкурентов.
Мы с вами двигаемся дальше. Вот мы с вами на самом деле какое-то время назад все хотели быть промт-инженерами, а потом поняли, что промт-инженеринг — это не так круто и важнее вообще конфигурировать контекст.
И вообще в работе над AI-аппликейшнами какими-то важна не только сама модель, которая, собственно, пережует наш промт и выдаст какой-то результат, но и важно то, что мы даем этой модели на вход помимо просто текстовой инструкции, какую еще информацию мы ей подаем.
Сейчас в эпоху коммодизации AI, когда там точка конкуренции смещается от того, насколько большая у вас модель к некоторому харнесу и созданию контекста для этой модели, как будто бы как раз поисковый сценарий, способы создания этого контекста наиболее актуальными становятся.
Контексты можем избирать откуда? Из внутренних знаний, можем из интернета, еще можем собирать какую-то информацию о пользователе, если хотим, персонализированное общение, либо какие-то внутренние процессы и инструкции.
Ну, то есть, о чем я говорю? Вот да, если модели комодизируются, то раньше, что мы делали? Мы выбирали большую модель, были такими некоторыми промт-инженерами и думали, а где находится нужная информация, чтобы вот классно ее в промт добавить и чтобы у нас хороший результат получился.
Сейчас мы уже больше доверяем AI и, соответственно, больше задачи и более сложные задачи делегируем AI. Ну и, соответственно, сейчас стоит задуматься уже, а вообще какая информация нашей AI-системе в теории может понадобиться, чтобы классно решать наш запрос.
То есть не мы вручную ее подбираем и добавляем в промт и просто условно просим модель на основании этого промта что-то сгенерировать, а мы уже строим систему, которая автоматически умеет собирать хорошо контекст.
Это такой важный смысловой переход, про который мне хотелось вам подсветить и рассказать.
Ну и, соответственно, современный AI-серч, то есть поисковый контекст, он помогает получать актуальный контекст под запрос клиента, какую-то, может быть, реал-тайм-информацию, которая не была на этапе обучения модели.
И, ну, по-настоящему, наверное, один из столпов создания хорошего контекста. Это хороший поиск.
Мы с вами немножко поболтали про сценарии, в которых, собственно, наши пользователи применяют поисковые сценарии, поговорили про некоторое изменение паттерна взаимодействия с ее системами.
Сейчас настало время нам с вами поговорить о продуктах e-search.
Собственно, о B2B поисковых продуктах, которые у нас есть. Я сейчас по ним пройдусь, расскажу вам немного контекста, и, собственно, сможем продолжить.
На самом деле, если мы, собственно, смотрим на e-search, то у нас есть такие воображаемые две ветки.
Поиск в локальной базе знаний и поиск в интернете. Я поговорю про обе, но сначала про поиск в локальной базе знаний.
У нас вебинары в правом уровне, поэтому я думаю, что вы все уже догадались, что на самом деле это рак.
Но давайте я потрачу буквально минуту времени для того, чтобы мы с вами все были в одном контексте.
Я думаю, что у нас сегодня разного уровня зрители на этом вебинаре.
Собственно, что такое рак?
По сути, это такой архитектурный подход, который реализует сначала поиск информации
в какой-то базе данных, которую вы заранее загрузили по вашей локальной базе знаний,
и дополнение этой информации к промпту, ну и, соответственно, генерацию на основе всей этой истории.
Ну и технически можно разделить его на две части.
Это, по сути, подготовка данных.
Это такая область довольно сложная и трудоемкая, и довольно неочевидная для людей,
которые впервые сложатся в таком архитектурном подходе.
Ну и, собственно, сам поиск релевантной информации,
которая, на самом деле, оказывается даже, я бы сказала,
чуть более простой задачей, чем подготовка сложных данных.
Все так, да.
Да, давайте я покажу вам схему.
Важно не пугаться, она простая и буквально иллюстрирует то,
что я вам сейчас рассказала.
Представим, берем нашу базу знаний какую-то,
суперсекретная документация, берем наши данные,
извлекаем, может быть, из сложных форматов,
из видео, из аудио, а может быть, у нас какая-то документация
лежит в PDF-ках, оттуда нужно забрать контекст
и перевести его, собственно, в текст.
Потом мы берем этот текст, режем его на кусочки.
Как показывает практика, поиск по кусочкам информации
работает лучше, чем поиск по целому файлу и более точно.
Потом переводим текст в вектора, эти вектора загружаем
в специальную векторную базу данных.
Все, мы готовы к тому, чтобы отвечать на вопросы пользователей.
Принимаем, собственно, вопрос пользователя,
модель его, может быть, как-то переформулирует
и идет в базу данных искать ответ на этот вопрос.
Ищет, ну, как правило, гибридным поиском,
это векторный поиск плюс, ну, обычный, полнотекстовый, да,
и добавляет к себе в prompt нужную информацию
и корректно отвечает на ваш вопрос.
Как вообще работает подготовка данных?
И тут я хотела бы на пару минут остановиться
и поговорить конкретно про наш инструмент, собственно, рага.
На самом деле, архитектурно мы реализуем внутри себя
такой довольно классический прямой пайплайн рага.
Основное УТП, про которое хочется рассказать,
это именно подготовка данных.
Как правило, все, кто пытался завести какие-то раг-системы,
понимают, что в целом это не какая-то rocket science задача,
в целом сделать какой-нибудь раг у себя на коленке.
Основная сложность в том, чтобы мощь хорошо,
чтобы хорошо предобрабатывать информацию.
Если с текстом плюс-минус все понятно,
может быть, ты его берешь и режешь на кусочки,
может быть, у тебя какая-то markdown-разметка,
и ты режешь как бы по спецсимволам,
то с другими типами информации все не так очевидно.
Конкретно наш инструмент поиска по локальной базе знаний
умеет работать с таблицами, это CSV и Excel.
Мы специальным образом их обрабатываем,
собственно, проводим сериализацию таблиц.
Интересно, что такое сериализация.
Пожалуйста, ребята, загуглите.
Там вот такая статья.
Просто вам чтиво на целый вечер.
Еще мы работаем с PDF и PPTX.
Это ваши любимые PDF-презентации, соответственно.
Мы не просто забираем оттуда текст,
но забираем еще и картинки.
Их тоже обрабатываем.
Работаем, соответственно, с изображениями,
как мы можем игнорировать изображения.
Особенно, если мы говорим про какую-то инструкцию со скриншотами.
Это очень важная часть контекста, которую не нужно терять,
которые, как правило, в каких-то простых опенсорсных решениях рага
часто просто скипают, из-за этого падает качество.
А еще мы работаем с видео и аудио.
Ну, вдруг вам нужно загрузить какую-то видеоинструкцию.
Например, такой кейс был на моей памяти у сотрудников Пятерочки.
Они делали ассистента для своих сотрудников,
которые пекут булочки и хлеб.
Я думаю, все пробовали булочки из Пятерочки.
Но вот там есть видеоинструкция, и они долго мучились тем,
чтобы научиться добавлять этот контекст в рак.
А у нас уже есть готовый инструмент для этого.
Поэтому вы не будете мучиться.
Предлагаю вам протестировать этот функционал.
У аудио мы берем текстовую дорожку.
Собственно, достаем текст и его викторизуем.
У видео мы берем и текст, собственно, звук, и видеоряд.
Его тоже мы обрабатываем.
Это тоже важная часть контекста.
Что ж, я тут надолго с вами остановилась.
Просто хотела вас привести к мысли о том,
что вообще большая часть качества результата
определяется тем, насколько хорошо подготовлены данные.
И это вообще важная мысль для людей,
которые делают такие системы.
И, конечно, важно, как они используются в LLM
и как они добавляются в контекст,
но подготовка данных — это вообще кора успеха.
Когда использовать трек?
Я думаю, что вы все уже догадались,
я не буду подробно устанавливаться.
Главный тут принцип — это история,
когда у вас есть какая-то локальная база знаний,
которой нет нигде в интернете,
и, может быть, вы не хотели бы ее шарить в интернет,
вот тогда хорошо помогает рак.
Либо вам нужно, ну, очень сильно как-то кастомизировать
ваш поиск, у вас совсем разнородная информация.
Дальше, переходим к второй большой части —
это поиск во внешних ресурсах.
Я вам немножко заспойлерил,
мы сегодня будем с вами говорить
про такие четыре интересных продукта.
Собственно, давайте по ним двигаться чуть подробнее.
Первое — это GenSearch.
Это такой продукт, собственно,
для наших клиентов,
которые не хотят заморачиваться
и просто хотят получить классный
генеративный ответ по поиску в интернете.
Фактически, что он делает?
Он принимает ваш запрос,
анализирует его
и, собственно, делает поиск на технологиях Яндекса,
берет поисковую выдачу
и генерирует ответ с цитатами.
Давайте, наверное, где-нибудь здесь посмотрим,
вообще, как это работает.
Кстати, на экране перед вами плейграунд,
в котором вы можете посмотреть,
как отрабатывают ваши запросы.
А еще взять себе код,
которым можно Ctrl+C, Ctrl+V вставить,
добавить API-ключ и буквально
все, у вас работающий функционал.
Это я вот задавалась интересным вопросом,
как зимуют рыбы.
Кстати, правда интересно.
Советую погуглить такие простые вопросы.
Собственно, у нас есть генеративный ответ, цитаты,
ссылки на эти цитаты, просто берем и используем.
И супер, и работает.
Когда такую историю стоит использовать?
Собственно, чат-боты, где поисковый сценарий - это вообще не core-функциональность,
где нужен просто какой-то поиск, и где хочется минимально
заморачиваться, типа супер-мвп какую-то историю делать,
и хочется вот куда-то делегировать все эти сложные штуки с тем,
чтобы настраивать поиск.
Но важно понимать, что мы здесь не можем влиять
на промпт итоговой генерации.
Мы вот получаем, собственно, какой-то генеративный ответ.
Если у вас очень специализированные ассистенты,
то такая история будет работать чуть хуже.
Ну и, соответственно, какой-то deep research
сложновато на такой истории построить.
Подробнее про сами API можно почитать в документации.
Еще одна интересная штука – image search.
Что я под этим подразумеваю?
Давайте смотреть.
Это такой же playground в нашей консоли Яндекса и студио.
Вот я тут какой-то другой вопрос задаю, да?
Да, ты задаешь, как котики.
Да, да, да. Люблю котиков.
Ну, давайте признаем честно, а кто не любит котиков, да?
Из нас с вами.
Здесь вот видно, что можно настроить разные параметры.
Например, понять, какие картинки конкретно мы ищем.
Скопировать уже сразу код с этими параметрами.
Вот у меня нашлись котики на подоконнике.
Собственно, это отображение картинок и ру-респонс.
Супер.
А еще можно искать по картинке.
Вот этот цветок, который стоит у меня на столе, на работе.
И я не знаю, как он называется.
Я решила посмотреть.
В общем, да.
Теперь знаешь.
Теперь знаю.
Да, да.
Вот, собственно, тут уже есть спойлеры в ответах.
Можно перейти на сайт.
Он найдет сразу сайт, где есть этот цветок.
Вот продают с потифилом такой же.
Более, ну ты даже теперь его цену знаешь.
Да, да.
Не, ну у меня, конечно, цветочек поскромнее, я бы сказала, по размеру.
Но примерно да.
Можно найти картинку и сайт, откуда эта картинка была взята.
Так, мы уже переходим к другому продукту, а я вдогонку замечу,
что такой функционал можно применять в различных, собственно, AI-агентах,
например, в том же, может быть, шоппинг-ассистенте,
когда мы ищем что-то похожее, либо там для других кейсов.
Я, кстати, использую часто такую историю,
когда, например, вижу какую-то классную блузку в интернете
и понятия не имею, где мне что-то похожее купить.
Честно, со мной всегда работает, меня это очень радует.
Следующий продукт, о котором мы сегодня поговорим – это Wordstat.
Наверное, из названия понятно, что это такое,
но давайте поговорим подробнее.
Это такой автоматический инструмент,
который помогает не просто искать информацию в интернете.
Предположим, что мы с вами хотим провести какое-то исследование,
а как часто ищут все или иные фразы в интернете.
И, может быть, как-то оптимизировать наш сайт,
наш бизнес под эту задачу.
Для этого есть, конечно, SEO-оптимизаторы специальные.
Ну и как бы нам с вами, как людям,
которые могут провести маркетинговое такое исследование,
это тоже интересно.
Собственно, он позволяет анализировать интерес к различным темам,
смотреть, а что еще ищут по похожей теме,
показывает статистику поведения
и как бы позволяет оценивать частотность запросов.
Меньше слов, больше, наверное, скринкастов для вас, да?
Давайте так.
Что самое интересное, в AI-студио мы прямо недавно добавили шаблон MCP-сервера
и теперь не обязательно что-то кодить невероятное, по API вызывать.
Можно просто зайти в интерфейс, добавить себе шаблон MCP-сервера к Wordstat
и на естественном языке общаться с своим AI-ассистентом,
который будет для вас проводить исследование.
Но, важно сказать, добавляйте, пожалуйста, инструмент веб-поиска
вместе с шаблоном MCP к Wordstatу так работать будет лучше.
Я думаю, что надо попробовать и потестировать, и оценить.
Мне, например, понравилось.
Действительно, классно работает, я согласен.
Итак, мы с вами подбираемся к, наверное,
такому самому интересному большому продукту,
на базе которого строится еще ряд других продуктов.
Это Яндекс.Серк.Чапи.
Это классический текстовый поиск на технологиях Яндекса,
что важно обговорить.
Мы сейчас говорим больше про поиск российский,
но есть и международная часть.
Если будет интересно, после вебинара в вопросах
либо в документации можно будет про это подробнее узнать.
Собственно, это классический поиск.
Вы задаете свой вопрос, конфигурируете API,
там довольно большое количество различных фильтров,
и на выход получаете, собственно, уру.
Топ 10, например, вы задали глубину.
И сниппет. Что такое сниппет?
Сниппет - это 2-3 предложения о том, что вообще есть на этом сайте, на этом урле.
Буквально вот в классическом веб-поиске,
когда вы ищете вот эти вот небольшие строчки под каждым урлом,
это и есть сниппет.
Важно сказать, большое количество действительно параметров.
Так, скорее всего, я даже записала скринкаст.
Да.
Важно сказать, можно настроить себе какой-то family mode, фильтр,
или управлять форматом выдачи.
Можно еще, например, сужать область поиска.
Например, вы хотите на конкретном домене искать.
Вот делаете вы, может быть, шопинг-ассистентой себе,
и хотите, чтобы он искал на конкретном маркетплейсе.
Это тоже можно сделать абсолютно просто через Playground.
Это я тут показываю разные форматы выдачи.
Да, все фильтры уже у вас готовые будут в коде.
Просто копирую, вставляю и использую.
А еще можно делать специализированный поиск в каком-либо регионе России
для того, чтобы максимально точные результаты получать.
Я немножко вздохну, и мы с вами будем шагать дальше.
Да, тут я уже вам все рассказала, когда нужен такой поиск в России,
очень качественный, собственно, с возможностью сузить область поиска,
когда нужно искать довольно быстро и находить углы ресурсов.
Далее мы приходим, наверное, к самому интересному, буквально подбираемся,
поговорим про Web Search Tool в Яндекс.Ей Студио.
И на этом прекрасном моменте мы с вами завершаем болтологическую часть,
мы все с вами в одном контексте, и я передаю слово Сереже Нарбуту,
для того чтобы он рассказал вам действительно про версию, вы же все этого ждали.
Да, более того, наша болтологическая часть здесь будет, потому что я же вам буду рассказывать.
Что ж, давайте начнем.
Всем сейчас пользуются активно агентами.
А мы сейчас говорили про конкретные инструменты, про конкретные API,
немножко потрогали генеративный поиск, но, наверное, вы хотите спросить,
а как мне в агента добавить, собственно, возможность искать, отвечать по контенту страниц.
Это можно делать при помощи нашего инструмента WebSearch Tool в Яндекс.AI.Studio.
Мы предоставляем нашим пользователям режим совместимости с OpenAI API.
И есть такой API, который называется Responses API.
Вот в нем существует встроенный Tool WebSearch, который можно по-разному настраивать.
Во-первых, у него точно так же, как у обычных API-поисков в интернете,
которые мы рассматривали чуть раньше.
Можно настраивать регион, конкретные сайты, язык можно настраивать, поиск.
Но есть ключевое отличие.
Во-первых, у него можно настраивать режим потребления контекста,
который кардинально меняет режим работы нашего агента.
Что происходит?
То есть, какие существуют всего три режима их?
Есть режим Low.
Это специальный режим с коротким ответом.
Он очень сильно экономит токены.
Он позволяет отвечать на короткие ответы.
Это, по сути, формат запроса-ответа.
Он прекрасно подойдет на примерах:
какая сейчас погода, сколько что-то стоит.
Что-то такое простое, не требующее глубокого исследования.
Затем есть режим Medium.
Он уже может потреблять существенно больше контекста модели.
Он выполняет агентский поиск.
То есть, это теперь мультихоп-поиск,
где не обязательно один запрос равен одному поиску,
где может быть целая серия запросов в поиск,
получение контента по этим страницам, изучение их и дополнение.
Здесь мы пытаемся соблюдать баланс между сложностью вызова толову моделей
и количеством контента, который он получает.
Мы стараемся здесь экономить токены, чтобы пользователям было дешевле
и модели с маленькими контекстными окнами лучше справлялись.
И, наконец, есть самый продвинутый хай-режим.
Это, по сути, уже полноценный ресерч,
глубокий агентский ресерч,
многократные вызовы инструментов поиска, сравнения их,
возможность моделей искать не только в интернете,
но и прямо по конкретным частям страниц,
изучать их подробно и дополнять себя.
Когда он применяется?
Когда мы действительно хотим делать всяческие мультихоп-запросы,
давать сложные сценарии?
Чуть позже покажу, как это все работает.
По сути, HIGH - это готовый harness для Deep Research.
Вы можете добавить туда дополнительных инструментов,
например, добавить туда MCP-квордстату,
можете добавить туда еще наш tool-код-интерпретатор,
чтобы получить какие-нибудь графики и сформировать отчет,
например, в PDF.
А можете и RAC туда подключить и вообще будет офигенно искать по всему.
Будет мега-такой ассистент, который ищет и по интернету,
и по вашим внутренним знаниям,
и готовит по-настоящему развернутые исследования
в нужном вам формате и в готовом PDF.
Да, и более того, сможет всякое сравнить.
Давайте теперь посмотрим на примеры.
Сейчас мы посмотрим на режим Low и его демонстрация.
Я спрашиваю агента, специально взял быструю модель
и спрашиваю, какая погода в Москве.
Мы видим, что модель ответила очень быстро,
мы получили информацию, какая сейчас погода,
и мы потратили всего около 1000 токенов.
Все работает быстро, и этот сценарий действительно подходит,
когда вам нужно что-то такое понятное и простое спросить.
Но давайте теперь перейдем к более интересному режиму,
это Medium поиск.
Здесь я уже выбрал более сложную модель,
это QN36 с глубоким оризонингом,
и задаю ей вопрос найти самую дешевую синюю зимнюю шапку.
Это уже не просто поиск в интернете,
здесь нужно провести ей некоторые исследования.
Вот мы видим, какой запрос она послала в поиск.
И модель пошла рассуждать.
Да, Quentry 6 очень любит рассуждать,
он достаточно многословный,
поэтому мы можем уже предположить,
что токенов мы потратим порядком.
Вот мы видим, что модель еще пошла что-то изучить.
А, вот теперь она решила открыть конкретный сайт.
Видимо, ей там шапки понравились, да?
Да, но она же действительно по нашему запросу,
я не уточнял, где искать, что за шапки,
какие шапки, просто спросила, какая у нас шапка самая дешевая.
Она пошла думать, выбирать такие запросы и такие страницы,
которые ей позволяют ответить на мой вопрос.
Да, это действительно непростой вопрос для модели,
тем более для маленькой модели QN36 на 35 миллиардов параметров.
Вот мы видим, что она пошла еще одну страничку открывать
и очень много думать.
QN36 действительно любит думать.
Важно сказать, что если вы хотите, чтобы все работало
побыстрее, вы можете взять модель с другим ризонингом
или вообще без ризонинга.
Важно отметить, что основная ценность в том,
что вы можете кастомизировать поиск под ваш конкретный
бизнес-кейс и бизнес-задачу.
Нужны быстрые ответы, берем быструю маленькую модель
и, собственно, простой маленький поиск в параметре low.
Или берем medium или high-контекст, и мы понимаем, что ответить
какие-то вопросы, например, выбрать шапку, сколько
мы залипаем на маркетплейсов, с другой стороны.
Мы понимаем, что вот такой поиск сильно сократит нам
время, и у нас на самом деле нет такого пользовательского
большого ожидания, что этот работает совсем быстро.
Часто именно в ресерч-сценариях скорость не основное требование
и не является блокером для пользователей.
Да, тем временем модель все еще размышляет.
Более того, опять же, поговоря про настраиваемость, вы можете
взять конкретное поведение модели через системный
промпт, как мы, например, видим в следующем режиме.
И да, действительно, Quantry 6, как я уже сказал, очень
любит хорошенько поразмыслить над вашей задачей.
Так что, если вы хотите взять модель, которая хорошенько
размышляет, вот Quantry 6 как раз…
Используем ее, да.
Да, используем ее.
Хорошо, что вы можете повлиять на системный промпт,
который влияет напрямую на результат.
Мы со своей стороны экспертно подобрали хорошие промпты
для того, чтобы агентский поиск работал хорошо.
И вам не нужно об этом заботиться.
Да, и как мы видим, здесь агент нам выдал итоговый результат.
Он показал разброс цен, сказал, на каких маркетплейсах можно их поискать.
В принципе, можно дальше попросить его предоставить конкретные ссылки
и пойти купить уже эту самую дешевую синюю-зимнюю шапку.
Это было достаточно небыстро, но, опять же,
потому что мы выбрали такую модель специально для демонстрации.
И как мы видим, то, что токенов мы потратили здесь достаточно много.
Но важное отличие, то, что это токены тулов,
а для некоторых моделей мы придаем их с достаточно большой скидкой.
Подробнее вы можете ознакомиться в документации.
Наша большая цель в том, чтобы вы собирали качественные агенты,
которые хорошо отрабатывают на ваших сценариях,
и для вас это было комфортно.
Поэтому мы приняли такое решение.
Я думаю, что после этого вебинара вы зайдете в документацию
и посчитаете, посмотрите.
Да, более того, кроме документации, еще было обучающее видео про токены тулов.
Все так.
И теперь мы посмотрим, наверное, самый интересный режим.
Это хай-режим размышлений поиска.
Я здесь уже прописал некоторую инструкцию для модели
и спрашиваю ее провести исследование стоимости квартиры в Саратове в 2026 году
и предоставить мне мало того, что просто чекстовый отчет,
но еще отчет в виде HTML-странички, которую я смогу посмотреть.
Для этого я, кроме веб-серча в режиме хай, подключил еще и наш инструмент «код-интерпретатор»
и выбрал модель «Dipsick 4 Flash».
Как мы видим, то, что думает, он существенно быстрее,
он не такой прожорливый в размышлениях.
Здесь мы видим, какие он странички открывает,
как он подобрал план исследований,
он уже целый список, большой такой список ссылок нашел,
и теперь он идет их изучать.
Он открывает, опять же, странички,
в каких-то местах он начинает читать конкретные кусочки страниц,
не пытаясь, например, прочитать всю информацию со страницы.
И, наконец-то, мы видим, что поиск он уже выполнил намного быстрее.
Вот как влияет, например, выбор конкретной модели на поиск.
Модель просто резонит гораздо эффективнее,
потому что модель больше, она более умная,
она лучше вызывает тулы.
И в итоге мы видим, что поиск закончился существенно быстрее,
хотя это поиск в хай-режиме.
И теперь, что дальше?
Модель начинает генерировать мне HTML-страничку
при помощи нашего инструмента код-интерпретатора.
То есть она сейчас буквально сидит и пишет мне код
с красивой страницей и отчетом.
Я специально никак не конкретизировал,
что именно модель должна построить,
поэтому у нее полная свобода в реализации этого итогового отчета.
Да, и интересно, что у нее получится.
Но, на самом деле, хай-контекст очень удобный,
я бы сказала, даже в таких бытовых вопросах
не только выбор недвижимости,
но и, может быть, выбор чего-то еще.
Например, я тестировала этот инструмент,
а за этим стоят, на самом деле, месяцы экспериментов
со всем, что вы видите, на горнолыжном оборудовании.
Я выбирала себе через хай-контекст горнолыжное оборудование.
Успешно?
Вполне успешно, мне понравилось.
Я не эксперт в области, поэтому для меня это было очень ценно.
Тем временем модель продолжает генерировать мне код для написания самой странички.
Мы немножко за этим понаблюдаем.
Очень надеемся, что она скоро закончит.
И можно опять же рассказать про ключевую особенность встраивания поиска в агентской системе.
Это то, что вы действительно можете его кастомизировать всячески.
Вы можете писать промт, вы можете советовать модели чаще или наоборот реже вызывать конкретные тулы поиска.
Наконец-то она это сделала.
Во-первых, она предоставила мне итоговый отчет по исследованию и, как мы видим, приложила файлик с HTML-страничкой.
Отчет можно почитать и можно открыть саму страничку.
Вот эта страничка.
Что ж, мы видим, красивый отчет в оригинальном варианте цветового исполнения, но я ничего у нее не просил.
Она привела все ссылки, привела мне таблицы, показала мне цены по районам, тренды посчитала.
Я же не спрашивал, что именно, какой отчет мне нужен.
Вот она выдала все, что захочет.
Естественно, вы в промте могли попросить ее сделать что-то более простое, более понятное.
Соответственно, модель выполнила, по сути, здесь уже Deep Research.
Мы вам какие-то сложные вещи тут про Deep Research рассказываем.
Давайте буквально на минуту отвлечемся и поймем вообще, как мы пришли от поиска к Deep Research.
А точно ли это штука, которая всем нужна?
Предположим, как вообще строился поиск раньше?
Как правило, это поиск где-то в браузере, какие-то буквально небольшие вопросы по кейвардам,
такие одношаговые вопросы, найти факт.
Как показывал и рассказывал Сережа, это, собственно, такие запросы для режима работы tool.
Собственно, один проход поиска и ответ.
Нам ответ не нравится, мы снова задаем вопрос, как-то вручную переформулируем.
Ну и, собственно, такой паттерн поведения пользователей с поисковыми системами был таким же.
Фактически, пишем короткие вопросы, кейварды, как привыкли в браузере,
ну и, собственно, не расстраиваемся, если что-то не сработало и просто спрашиваем еще раз.
Но по мере того, как в целом AI интегрируется в нашу жизнь,
у нас становится гораздо больше доверия к системам на базе искусственного интеллекта,
и мы теперь не просто задаем какие-то вопросы, не знаю, недвижимость Саратов,
если мы вспоминаем предыдущий кейс,
мы сейчас уже спрашиваем в поиске и спрашиваем у агентов целые задачи,
такие многоходовые, многошаговые задания для наших агентов и вопросы.
Они называются мультихоп.
Собственно, сегодня ожидание пользователей от системы,
что они зададут такой мультихоп-вопрос сложный,
проведется некоторый анализ, запрос разложится на несколько шагов,
и выполнится.
Именно поэтому мы сейчас с вами беседуем про DeepResearch,
потому что, по мере развития технологий,
ожидания пользователей от системы меняются,
и для того, чтобы их не разочаровывать,
нам нужно строить чуть более сложные системы
и, собственно, управлять ценой ошибки.
Например, вот, пример мультихоп-запроса.
Сейчас на экране:
«Ну, мне нравится что-то вроде, там, я не знаю,
какая команда победила на чемпионате мира,
когда в Москве была гроза».
Вполне себе такой мультихоп-сложный запрос,
который пользователь может задать в вашу систему.
Я передаю слово снова Сереже.
У нас продвинутая часть.
Да, я сейчас расскажу чуть больше
про основные архитектуры построения Deep Research.
Их не так много.
Поверх этих архитектур существует
большое, бесчисленное, наверное, количество реализаций,
но мы рассмотрим основные.
Во-первых, подход номер один — это, по сути,
подход с отдельным планером и экзекьютором.
Что же это, собственно, такое?
Значит, у нас существует некоторый агент с планировщиком,
который пишет план исследования, уточняет детали у пользователя,
задает ему вопросы и составляет, так называемый,
контекст того, что нужно поискать.
Потому что, зачастую, пользователь не всегда даже
конкретно спрашивает, что он хочет найти.
Потом агент-планер разбивает задачу на части и передает
это экзекьютору, который подхватывает и выполняет
задачи.
Экзекьютор, когда уже нашел некоторые результаты,
возвращает их снова в агент, и тот их оценивает и говорит,
хороший ли это ответ, подходит или нужно еще что-то доуточнить
и продолжить поиск.
Здесь мы видим схему.
Важно понимать то, что планеры-экзекьютор могут
быть даже разными агентами, работающими поверх разных
пользователей.
Например, что-то более дешевое и более простое
для самого поиска исполнения и более сложное, более дорогое,
пытающиеся активнее мыслить в виде планировщика, который
задает вопросы и собирает итоговый контекст.
Важно понимать то, что это все происходит в цикле.
Планер и экзекьютор могут выполняться достаточно
большое количество раз, пока пользователь не будет
удовлетворен.
Планировщик строит план запроса, он декомпозирует
на шаги, а экзекьютор их исполняет.
Он ищет информацию в интернете, читает источники,
извлекает ключевые данные, возвращает промежуточные
результаты, чтобы планировщик принял решение, идти ему
дальше или нет.
То есть, соответственно, именно экзекьютор делает
запросы в поисковые системы, веб-поис, тот же самый
RAC, и вычитывает оттуда информацию.
Но если вы думаете, что это позволит вам сэкономить
токены в контексте, на самом деле нет.
Он разобьет просто один большой контекст на много
контекстов поменьше.
Оптимизировать можно за счет как раз выбора модели.
Обычно так и поступают, такую чуть более тяжеловесную
модель с обработкой большого контекста делают
планером и чуть более маленькую, но с хорошим
тулколингом, экзекьютором.
Или наоборот, зависит от вашей задачи конкретной.
Все правда.
Это досвольно распространенный подход, и что же в нем хорошего,
какие у него будут ограничения и как его использовать.
Хорошо, во-первых, в нем то, что поверх него можно строить абсолютно любой поиск.
Он умеет искать информацию на любой запрос пользователя.
Он очень гибкий, потому что он мультихоп запросы умеет легко исполнять,
и более того, даже в процессе спрашивать пользователя что-нибудь доуточнить.
Потому что это не только мультихоп запросы, но еще и мультитерн запросы,
когда у вас несколько итераций взаимодействия с пользователем.
Важно понимать, что из плюсов это то, что это очень многопрофильный, широкий инструмент.
А какие же у него основные ограничения?
Во-первых, он может быть достаточно дорогой.
Особенно если вы хотите делать высококачественный план,
вы захотите использовать дорогую модель, которая будет хорошо резонить и генерировать хороший план.
У этого нестабильное качество может быть.
А что здесь значит?
То, что если планировщик начинает ошибаться, то весь этот план начинает постепенно накапливать ошибку.
Модель может уходить не туда, задавать не те вопросы.
И в итоге вы можете получить не совсем качественный результат.
Или в принципе не качественный, если модель буквально не поняла вас.
И еще сложно тестировать и воспроизводить.
Почему так?
Потому что модель может построить другой план.
Вы взяли другую модель, она вообще сделала другой план.
Вы взяли другого экзекьютора, он пошел по-другому поискал.
Это достаточно сложно тестировать.
Но тем не менее, если вам нужен универсальный research-агент,
который решает любые вопросы, это прекрасный архитектурный подход.
Он будет работать, он будет выдавать довольно качественные результаты,
и он достаточно несложно реализуется.
Естественно, поверх этого архитектурного подхода
есть огромное количество разных вариаций с набором агентов,
с делением на подзадачи, с иерархией.
То есть, его расширять можно достаточно много.
И есть в том числе и готовые фреймворки.
Вы тоже можете посмотреть в интернете,
как такой агент можно собрать, в том числе, например, и поверх нашего API.
Теперь мы подойдем к следующему подходу.
Это жестко-многошаговый пайплайн.
Почему он, в принципе, появился?
Потому что из прошлого пайплайна я сказал то,
что есть проблемы с воспроизводимостью и точностью результата.
Это не всегда применимо.
Что же такое жесткий пайплайн?
Он нам нужен, если у нас очень высока цена ошибки.
Например, медицина, что-то связанное с фармакологией,
с ириспруденцией.
И здесь специалист, человек, часто лучше знает,
как именно искать, какие лучше делать запросы, что улучшать.
Что же здесь делают?
На самом деле, изначально при помощи разработки,
может быть, ML-инженеров и специалистов из области
собирают специальный жесткий пайплайн,
который в определенном порядке умеет искать,
умеет задавать правильные вопросы.
По сути, это поиск, который жестко заточен
под конкретную специализацию.
Как правило, это одношаговый поход,
реже проход поиском, реже мультишаговый.
Здесь обычно не задают вопросов в поиске,
если это не предусмотрено изначально пайплайном.
И он обычно состоит из нескольких шагов.
Сейчас я их покажу подробнее.
У нас есть пользовательский запрос.
Пользователь его посылает, но его перехватывает рефрайзер,
специальная модель, которая переформулирует запрос пользователя
и из него делает что-то более информативное.
После этого происходит обогащение контекста модели,
всяческой информации, в том числе и запроса пользователя.
После этого уже происходит поиск в различных системах.
Это тоже может быть либо отдельная модель, либо эта модель.
Дальше происходит фильтрация результатов.
И после фильтрации результатов итоговая модель пайплайна оценивает качество.
Кстати, это даже может быть не только модели,
а какие-нибудь более математически строгие тесты.
После этого уже возвращается результат.
Или пользователь получает ошибку, что ничего не нашел.
Такое тоже бывает.
Это типовой пайплайн, но с точки зрения архитектуры,
вот как вы пайплайн свой запрограммироваете, таким он и будет.
Какие же здесь плюсы и минусы?
Во-первых, что же в нем хорошего?
У него есть высокая предсказуемость,
потому что сам пайплайн собран руками человека,
руками разработки, и вы можете все это протестировать,
валидировать каждый этап.
Вы можете проверять результаты входа и выхода каждого этапа.
Так как это пайплайн, который спроектирован под конкретную задачу,
решает ее достаточно хорошо.
Отсюда же следуют ограничения.
Если вы поиску, который был спроектирован для поиска по медицине,
зададите вопрос про астрономию,
результаты будут, скорее всего, не очень качественные.
Более того, вам здесь нужны специалисты в доменной области для того,
чтобы такой pipeline собрать.
Ну и опять же, где применимо?
Это всякая фармакология, врачебные отделы, медицина,
юридическая аналитика, финансовые исследования.
Но важно понимать, что изменение этого pipeline будет требовать разработки.
И теперь мы перейдем к третьему режиму.
Это, по сути, такой агентский и цикл.
Есть умное слово, по-моему, React, как это называется.
По сути, мы даем модели некоторый набор инструментов,
при помощи которого она может искать.
Причем искать иерархически.
Мы даем ей инструмент поиска в интернете,
по которому она сможет найти ссылки с тем же самым описанием,
о чем может быть страница.
Мы не даем никакого жесткого плана.
Модель на основании запроса пользователя
сама сделает его refresh, потому что ей сказали так сделать.
Она найдет нужную информацию в интернете, а потом,
смотря на инструменты, которые у нее есть,
будет пытаться понять, как лучше их использовать
для того, чтобы решить задачи пользователя.
Например, у моделей могут быть инструменты
"поискать что-то на конкретной странице".
А может быть, и есть инструмент "отдай мне, пожалуйста,
весь текст на странице".
Или "найди что-нибудь по ключевым словам".
По сути, здесь ваша фантазия безгранична.
Недавно у Perplexity было целое исследование
про то, какие инструменты они используют в моделях.
Они дают им целый большой набор инструментов поиска в интернете,
и модели сами из них собирают пайплайн под каждый запрос.
Вот это важно.
Модель может собрать пайплайн под каждый запрос.
Но какие же здесь минусы такого подхода?
А минусы достаточно понятные.
Во-первых, нужен очень хороший системный промпт.
Чем лучше вы модели объясните, как пользоваться инструментами,
именно инструментами,
тем лучше она сможет их использовать.
Но из плюсов, на самом деле,
то, что можно легко управлять этой стоимостью,
давая модели разные тулы и разные описания.
Можно менять модель саму, можно менять описание тулов.
И, более того, еще можно и системный промпт модели менять.
Соответственно, ее основные плюсы - это гибкость и естественность.
Модель сама будет собирать себе из специальных,
условно говоря, скиллов поиска по интернету,
пайплайн для вашего запроса.
Это очень легко расширять, потому что вы добавляете новый инструмент,
и модель сама учится его использовать.
Опять же, у этого высокая наблюдаемость,
так как вы можете проверять результаты входа и выхода каждого тула
и наблюдать, как все это работает.
Этот подход прекрасно ложится на модели с сильным использованием тулов.
И более того, то, что при помощи этого подхода
вы можете легко оптимизировать стоимость на простых запросах.
Как мы видели, когда я спросил у модели, какая сейчас погода,
она просто мгновенно ответила:
«Да, в качестве спойлера мы используем именно этот подход у нас в веб-поиске».
Но какие же ограничения?
Нужна модель с сильным пошаговым рассуждением.
При этом вам важно выбирать баланс между рассуждением модели и временем работы,
если вам это важно.
Как мы видели, Quantry 6 работал достаточно медленно,
потому что он очень много размышлял.
Сложнее гарантировать полноту исследования,
потому что, когда модель решит остановиться,
тогда она и остановится.
Но, конечно, вы можете попросить ее исследовать дальше.
Более того, на самом деле, вы можете модели попросить
в ходе исследования задавать вам вопросы,
для того, чтобы уточнять.
То есть, вы вольны настраивать все, как хотите.
И расход токенов и времени очень сильно зависит от числа шагов.
И, соответственно, от тех ограничений, которые вы наложите сверху.
Модель может завершить поиск за, условно говоря,
10 поисков по интернету, а может и за 50.
Тут зависит от того, насколько четко она поняла задачу.
Соответственно, мы рассмотрели сейчас три основных подхода.
И какие же из этого есть выводы.
Во-первых, то, что все агенты решают, по сути, одну и ту же задачу.
Они хотят получить доступ к нужным знаниям.
Опять же, почему так?
Потому что агенты были обучены на каком-то наборе знаний,
и современные знания они могут не знать.
Например, тот же QN36 очень часто думает, что сейчас не
2026 год, и ему пришлось специально объяснять это
в промтах.
Это краткое происследование, которое мы делали.
Опять же, важно понимать то, что у Deep Research существует
три основных архитектурных подхода, и вы можете выбирать
под конкретные задачи.
На самом деле, любой из них можно построить поверх
нас.
И теперь я еще тоже передам основные итоги.
Да, из первой части нашего прекрасного вебинара
мы, наверное, все поняли, пришли к мысли о том, что
мы двигаемся от простых запросов, которые можно
просто поискать в интернете, чуть более сложным таким
мультихоп запросам, буквально задачам пользователя, с
которыми им может помочь их агент, который специально
профессионально занимается поиском, ресерчер.
Или у него просто есть, собственно, такая возможность
и такая функция.
Весь поиск переходит из стадии, собственно, когда
человек просто дает промпт и происходит генерация
в процесс интеллектуального создания контекста для
AI-агента.
В этом помогает как раз Deep Research.
А мы с вами будем двигаться дальше.
Что ж, я вас порадую.
На этом все.
У нас осталось время на ваши вопросы.
Я воспользуюсь минуткой PR.
Вот тут есть QR-код на мой Telegram-канал.
Там выйдет весь этот контент в виде статьи.
Ну и просто я пишу про всякие интересные LLM-штуки.
Если вам интересно, можно подписаться.
А мы будем потихонечку переходить к вопросам.
И, наверное, я зачитаю первый вопрос.
И, пожалуй, делегирую его Сереже.
Вообще, при использовании веб-серч в хай-режиме,
вот в максимальном,
задаются ли для исследования уточняющие вопросы?
В общем, может ли модель задавать их пользователю?
Да, смотри, здесь довольно интересная ситуация.
То, что модель действительно может задавать их пользователю,
но, как мы видели на демонстрации,
цикл всего поиска – это, по сути, один запрос к модели.
По ходу дела вам некогда вставить вопрос,
но модель может решить то, что ей необходима для вас информация,
вывести вам вопрос, прерывать цикл,
вы можете ответить, и модель может продолжить его сама дальше.
То есть, соответственно, если вы попросите модель в стенном промте
собирать такую информацию, по сути, реализовывая планер как раз,
она будет так делать.
Но именно в рамках одного поиска,
когда вот она начала искать в интернете,
здесь она в процессе работы, это уже называется мультитерн,
вот она делает один терн,
в рамках одного терна она не задаст вам вопрос.
На самом деле и другие системы задают вам вопросы в рамках мультитерна,
и мультитерн, по-первых, нас реализовать можно.
Супер, спасибо. Теперь, наверное, вопрос для меня.
Вообще, а можно ли ограничивать поиск по интернету?
Смотрите, вот большая особенность нашего инструмента в том,
что, как и в стандартном API текстового поиска,
вы можете выбрать именно те домены, на которых вы хотите,
чтобы, собственно, поиск производился.
Например, домен конкретного маркетплейса
или, может быть, какой-то площадки с экспертными статьями
или нескольких таких площадок и нескольких доменов, соответственно.
Так и в туле, собственно, поиска в интернете,
который можно добавить с IMEA-агентом,
вы тоже можете ограничить область поиска по конкретным доменам.
А еще можно искать в конкретных регионах России
для того, чтобы максимально точный поиск у себя делать.
Да, вы можете это делать как в API отдельного поиска,
так и в Web Search Tool в настройках прямо в интерфейсе
или в коде, если вы хотите писать код.
Можно взять Open SDK, указать, соответственно, там ограничения,
и запрос будет находиться по такому-то сайту
или по такой-то стране, даже по такому-то региону.
Сереж, всех очень интересует наш Тула веб-серча.
У меня к тебе вопросы, собственно, которые нам написали наши зрители.
Вообще вот несколько походов в веб-серч.
Такая стратегия, такая история работает только в ВХ-режиме
или может работать на всех режимах.
Да, здесь смотрите, три режима достаточно сильно разделены.
По сути, в каждом из них мы используем третий подход,
но даем разный набор инструментов для модели,
потому что мы хотим ограничить то, как глубоко модель может использовать.
Если короткий ответ, то он работает на всех трех.
Если более точный ответ, то high использует весь набор инструментов,
которые доступны модели, medium использует более ограниченный набор
и low режим — еще более ограниченный набор.
Супер, спасибо.
Теперь вот такой интересный вопрос.
Сравнивали ли мы качество ответов в веб-серч-тул с нейроответами других поисковиков?
Давайте тут с вами разбираться вместе.
Смотрите, нейроответ, который дают поисковики вообще в браузере, он предоставляет готовый генеративный ответ.
Это, по сути, генсерч.
Да, это на самом деле генсерч, который просто дает вам генеративный ответ, вы не можете вообще никак влиять на промпт.
И какую задачу он выполняет?
Он светится, собственно, в браузере для B2C-пользователей.
То есть он помогает им собирать контекст для их конкретного запроса, который они пишут в браузере.
И наш близкий продукт — это генсерч, это такой же генеративный ответ, который появляется в браузере.
Честного СБСа между ответом Гугла и Яндексом мы не проведили.
Ну, в первую очередь, потому что честный СБС на самом деле сделать не получится.
Потому что мы понимаем, что Гугл — это очень такая мультинациональная поисковая сеть.
И, конечно, база Гугла и Яндекса разные.
Яндекс лучше всего, конечно, делает поиск в России.
И тут, наверное, сравнивать будет не совсем честно, потому что состав поисковой базы сильно влияет на такое сравнение.
Что еще хочется сказать?
Собственно, то, что WebSearch Tool — это скорее агентский поиск, который вы можете адаптировать под свой запрос и добавлять агенту.
Это не совсем такой же продукт, как условный BTC генеративный ответ.
На самом деле, если вы хотите построить собственный нейроответ, как бы вы называли, как в браузере,
вы можете использовать.
И на самом деле, если вы хотите поэкспериментировать, то скорее можно взять лоу-режим,
покрутить параметры модели, выдать ей какое-нибудь ограничение количества тулов,
добавить информацию про пользователя.
Я уверен, что Google, например, добавляет информацию про пользователя.
Ну, предположу так.
Да, все так, ты прав.
Все эти нейроответы, они персонализированы вообще у всех провайдеров интернета и поиск.
Да, соответственно, вы можете попробовать поверх нашего API собрать такой же режим,
и на самом деле сравнивать качество поиска – это достаточно сложная задача,
мы занимались этим достаточно много, особенно когда подбирали всяческие системные промты и наборы инструментов.
Более того, приходится сравнивать на разных наборах моделей,
потому что поведение у них может быть отличаться.
Как мы видели, то, что QN36 ведет себя совсем не так, как дипсик.
Более того, тому же самому QN36 пришлось объяснять, какой сейчас год, и то он не всегда верит.
Ну, чтобы поделать разные модели, да, очень много факторов в таком сравнении.
Я вот вижу вопрос от Романа, будет ли QR-код на тест, а он уже на экране.
Я думаю, что вы можете взять свои телефончики, отсканировать этот QR-код, там будет квиз,
по итогу которого мы закрепим то, что обсудили сегодня на вебинаре.
Пока что больше нет вопросов, и мы будем с вами потихоньку завершаться.
Спасибо вам большое, что вы были сегодня с нами на этом вебинаре,
а мы были рады вам рассказать про наши поисковые инструменты и архитектурные подходы в Deep Research.
Советую всем их попробовать, благо у нас есть достаточно удобный плейграунд для текстовых агентов и для поиска.
Вы можете попробовать, посмотреть, как это работает, поэкспериментировать с различными параметрами,
с различными моделями и посмотреть, как это работает.