Transcription
Всем привет. В этом видео мы расскажем про основные компоненты и API платформы Яндекс Studio. Дима, тебе слово.
Привет. Да, начнём с обзора платформы, с обзора слоёв, из которых она состоит. И первый базовый слой, без которого не могут работать никакие приложения - это слой языковых моделей. У нас он называется Model Gallery, и он включает в себя различные генеративные модели для работы с текстом, с аудио, с изображениями или для, например, генерации изображений. А модели у нас разделяются на два класса. Это проприетарные модели, которые предоставляет Яндекс, например, Яндекс GPT, LSI, Яндекс и другие, так и state-of-the-art open-sourceные модели, а, например, GPTOSS, GEMA и другие. Работать с этими моделями можно несколькими способами. Самый базовый простой способ - это использовать completions API, совместимый с форматом API OpenAI. Или же вы можете, например, адаптировать модели под свои задачи с помощью tuning API, да, обучить модель, а, определённый набор моделей, да, под свою задачу, либо же запустить модели в пакетной обработке, если вам нужно обработать большой объём данных. Про все эти API мы поговорим подробнее дальше.
Второй слой платформы - это так называемый Agent Orchestrator. Это набор компонентов или инструментов, которые позволяют реализовывать агентские архитектуры, реализовывать агентские сценарии. А первая часть - это Agent Tools, то есть это набор инструментов или тулов, да, которые расширяют возможности языковой модели. Сюда входят такие инструменты, как, например, обращение к файлам и работа с файлами, да, для ответов на вопросы. то есть для реализации RAG сценариев это поиск в интернете с помощью WebSearch Tool или обращение к внешним API, к внешним системам с помощью формата MCP. Для того, чтобы можно было обращаться к внешним MCP серверам или создавать свои сервера, есть компонент MCPHub, о нём тоже подробно расскажем. А создавать агентов в AI Studio можно двумя такими базовыми способами, двумя направлениями. Первое направление - это с помощью кода, да, например, вы обращаетесь к API, к Responses API, к Realtime, либо же вы пишете код на SDK, который опять же ходит в API. Либо если вы, например, делаете какое-то быстрое прототипирование или если это сценарии, которые не требуют большой гибкости, то их можно реализовать в low-code инструменте Workflows.
Отдельное большое направление, которое у нас есть в Agent Orchestrator - это направление голоса. Здесь можно, например, создавать голосовых агентов, э дообучать модели синтеза речи, а и, например, решать задачи суммаризации, аудио, видеоконференции и так далее. Кроме этого, сегодня подробнее проговорим по про поиск, про то, что на слайде обозначено AI Search, то есть это, а, загрузка и работа с файлами, да, языковой моделью- это построение поисковых индексов.
Третий слой, а, слой UI - это как раз набор компонентов, которые позволяют собирать агентов, прототипировать их без кода. То есть в UI вы можете потестировать различные языковые модели, подключить инструменты, посмотреть, как они отрабатывают, провести эксперимент с промтами, а, и подобрать там, э, формулировки промтов под свои задачи. А здесь же находится, например, возможность собранного вами агента в компонентах Workflows.
Давайте подробнее остановимся на каждом из блоков. Первый блок - это Model Gallery. И здесь представлен список моделей, которые доступны на текущий момент. Сразу скажу, что этот список постоянно меняется, расширяется, добавляются новые модели. А, но если говорить про то, что я сейчас, это модели от Яндекса. А самая большая флагманская модель - это модель LSI. А кроме этого доступны модели поменьше, но модели, которые хорошо решают определённый набор задач и быстро отвечают. А это модели Яндекс GPT Pro и Яндекс GPT Lite. Это специальная модель, которая, а, затюнена, да, обучена под голосовые сценарии, модель Speech Realtime и модель Яндекс Art для генерации изображений по текстовому промту. Э, это что касается именно генеративных языковых моделей, таких общих, да? При этом у нас есть набор специализированных моделей под какие-то узкие конкретные задачи. Например, к таким относятся классификаторы. Это дообученные генеративные модели, но они дообучены специально решать задачу классификации. Либо же это модель эмбедингов, которая переводит текст в векторное представление, например, для реализации сценариев поиска, RAG и так далее.
Что касается open-sourceных моделей, то это модели Llama 2 с 70 млрд параметров. Это модели, которые выложили в Open Source OpenAI, а OSS 120 млрд и 20 млрд. И это модель Gema 27 млрд.
А если говорить про непосредственно построение агентов, то здесь важно выделить два как подхода, два направления. Это текстовые агенты и голосовые агенты. А в целом, когда мы будем подробнее рассказывать про AI Studio, вы увидите, что все инструменты, которые создаются в AI Studio, они могут быть переиспользованы как при создании текстовых агентов, так и голосовых агентов. А, то есть, например, вы можете создать поисковый индекс и затем переиспользовать его и в тексте, и в голосе. А за счёт этого, за счёт этой экосистемности платформы, ээ, создание агентов значительно ускоряется и упрощается. Но давайте поговорим подробнее про каждый из этих типов.
То, что касается текстовых агентов, базовый API, поверх которого они создаются и работают - это Responses API. И Responses, и Realtime, они совместимы с OpenAI, поэтому их удобно использовать, в том числе из других open-sourceных фреймворков, компонентов, таких как там OpenAI Agent SDK, LangChain и других. Так вот, а Responses API или как бы шире текстовые агенты, самый простой способ начать их создавать - это в UI. Как я уже сказал, есть удобный UI в AI Studio, где вы можете выбрать модель, выбрать инструменты, написать промт и начать тестировать такого агента. На вход э Responses API может получать как текст, так и изображение. При этом здесь важно учитывать, что не все модели поддерживают на вход изображения. Все модели будут работать с текстом, с изображениями, э, будет работать под множество моделей, например, Gema. Response API совместим с OpenAI. И, например, если вы уже внутри компании используете э такие open-source решения, как там LangChain, OpenAI Agency Development Kit, CrewAI, либо может какой-то low-code или no-code типа Notion и так далее, вы можете легко интегрировать модели, которые доступны в AI Studio, и агенты, да, которые доступны в AI Studio в эти решения.
Теперь, что касается голосовых агентов. А здесь это отдельный API, так как он требует специализированной работы со звуком, да. То есть, когда мы говорим про голосовых агентов, у нас есть набор определённых требований вокруг скорости ответа, вокруг обработки событий и так далее. А его особенность Realtime API в том, что наша как бы ключевая цель - это оптимизировать работу голосовых агентов под высокую скорость ответа, так как понятно, в большинстве сценариев пользователь не готов ждать, а пока там модель будет генерировать ответ и его озвучивать. Для такого живого диалога нужно делать это быстро, а чтобы получить хорошее качество. Для сценариев голоса мы сделали специализированную модель от Яндекса. А ещё одно важное свойство Realtime API - это поддержка перебиваний, да? То есть, если, а, идёт диалог, там пользователь не хочет дослушивать ответ, он там начинает перебивать, а модель реагирует и как бы перестаёт говорить, а, и начинает генерировать ответ на следующий вопрос пользователя. И что ещё важно, таких голосовых агентов можно делать персонализированными. То есть вы можете, а, использовать как те, а, дефолтные голоса, которые доступны в Яндекс SpeechKit, так и, например, а, подключить свой кастомизированный голос, например, сделанный с помощью Brand Voice или Brand Voice Studio.
О'кей. У нас есть условно базовый оркестратор, который может получать запросы текстовые и принимать решение о вызове внешних инструментов, да? То есть таким оркестратором является Responses, если говорить про текстовых, Realtime, если говорить про голосовых. И дальше встаёт вопрос: а какие же инструменты можно вызвать? И первый набор инструментов, которые доступны внутри платформы AI Studio - это инструменты для поиска, для поиска внутреннего по документам, по документации, а там по PDF-файлам и так далее. Так и, а что важно для многих сценариев, для поиска по интернету?
Давайте начнём с поиска в документах. Самый частый сценарий, который здесь есть - это набор документов. Там это может быть, например, выгрузка Wiki или Confluence. Это могут быть просто какие-то отчёты, там PDF, Word и так далее. Они загружаются в векторное хранилище, да? То есть происходит загрузка документов и дальше происходит парсинг этих документов. И здесь важно, что у нас есть специализированные парсеры под различные форматы документов, под обработку изображений, таблиц и так далее. Далее по этим документам автоматически полностью строится поисковый индекс, и затем человек, который создаёт агента, просто подключает этот поисковый индекс к Responses API, и Response API умеет автоматически делать вызов этого поискового индекса. Кроме того, и Responses, и Realtime могут автоматически вызывать а такой поисковый индекс. Что здесь важно сказать? Это работа. В поисковом индексе по дефолту может быть до 10.000 документов. При необходимости это количество можно расширить через обращение в техническую поддержку. А, как я уже сказал, есть набор специализированных парсеров под разные форматы документов. Понятно, что, например, там таблица Excel должна обрабатываться немного иначе, чем, например, это происходит там у PDF с большим количеством изображений. Вот такие разные форматы есть определённые, э, подходы.
Ещё одна важная вещь - это возможность гибко настраивать и управлять базой знаний. То есть, э, когда вы начинаете работать, вы загружаете документы, да, по ним строится поисковый индекс, дальше вы можете, например, удалить какие-то документы из поискового индекса. И это происходит прямо при работающем индексе. То есть это никак не блокирует сам индекс. Вы можете указывать какие-то метаданные при загрузке файлов и затем при обращении фильтровать по этим метаданным. Это важно, например, если вы хотите разграничить пользователей или там пользовательские группы по сценариям. А, и кроме этого у нас появилась возможность загружать напрямую чанки. То есть, если вы не хотите использовать, а, там, возможности автоматического парсинга и чанкинга, которые доступны в рамках, а, AI поиска, вы можете самостоятельно сделать свой ETL pipeline, а, самостоятельно там готовить чанки, обогащать их и загружать уже в платформу непосредственно готовые чанки. Они будут лежать в базе. И дальше Responses будет обращаться к базе именно с вашими чанками.
Второе направление - это поиск в интернете. Да, для многих сценариев, где, например, нужно работать с самыми последними новостями, проверить терминологию, а ещё что-то, можно использовать, а, инструмент WebSearch, э, который обращается в, а, большой поисковик Яндекса. А, и что здесь важно сказать, что этот поиск также можно настраивать. Вы можете указывать регион поиска, вы можете ограничивать домен, по которому будет происходить поиск. То есть вы можете указать до пяти доменов, и тогда поиск в интернете будет ограничен только вот этим конкретным набором сайтов, доменов, а для поиска информации, например. Это удобно, если вы хотите построить каких-то помощников там по публичной информации на вашем сайте. Вы можете подобрать модель, настроить промт, там всё отладить и подключить инструмент WebSearch, указав только ваш конкретный домен, а только ваш сайт.
Третий тип инструментов, которые доступны на платформе AI Studio - это MCP, то есть это подключение к внешним API через формат, предложенный компанией Anthropic через MCP. Для того, чтобы можно было подключаться к внешним инструментам, а в AI Studio есть компонент MCPHub, который позволяет подключить внешний MCP-сервер. Если он у вас уже где-то создан и развёрнут, и где-то хостится у вас, не знаю, в облаке, локально, вы можете, а, просто настроить к нему подключение, и тогда агенты внутри платформы смогут к нему обращаться. Либо же, если у вас пока MCP нету, но есть API, к которому вы хотите подключиться. А их можно просто внутри UI AI Studio трансформировать в формат MCP. Либо же можно создать свой MCP полностью с нуля. В нём может быть три типа инструментов. Это может быть существующее API, это может быть облачная функция, либо же это может быть полноценный поток, собранный в инструменте Workflows. А что важно, MCPHub он позволяет добавлять, удалять инструменты, и вы можете разграничить роли пользователей, кто, например, занимается добавлением, и роли разработчиков, который будет затем, э, там подключать существующие MCP-сервера и создавать уже агентов. То есть это дополнительная точка контроля, да, и отслеживания того, что происходит с MCP и каким MCP есть доступ внутри компании. Кроме этого, у нас есть э отдельный набор готовых коннекторов к таким системам, как, например, AMA CRM, CounterFusion, Яндекс Трекер. И этот набор шаблонов будет постоянно расти, будут добавляться больше интеграций, и, соответственно, вы сможете ещё быстрее собирать агентов, которые ходят в корпоративные системы.
Ну и что касается low-code создания агентов или вообще построения приложений, здесь у нас есть ещё одно решение, а в рамках AI Studio. Это решение Workflows. Он позволяет, э, собирать цепочки из вызовов языковых моделей или уже агентов, которые, а, могут обращаться к инструментам. А у него есть набор интеграций как с сервисами Облака, так и с AI Studio. А есть набор управляющих шагов, да, для реализации, например, циклов, э там ветвлений и так далее. И при этом вы можете как просто настроить там кубики обращения к моделям, так и гибко, например, там указать, какие поля для чего использовать. То есть инструмент позволяет достаточно сильно кастомизировать цепочки.
И таким образом, подводя итог первой части обзора компонентов, э, мы выделяем два подхода к созданию AI-агентов в рамках AI Studio. А первый подход - это так называемый Code First подход. Он скорее предназначен для разработчиков, которые хотят иметь максимальную гибкость при создании агентских архитектур. А взаимодействие здесь происходит напрямую с API, с Responses API, Realtime API, Completions API, либо через SDK, да, которые опять же ходят в API. А здесь чаще всего используется тот или иной open-source инструмент, который с одной стороны упрощает разработку, так и позволяет, например, собирать какие-то более сложные системы. Например, там в LangChain вы можете использовать OpenAI Agents SDK и использовать механизм хендофов, который позволяет там передавать управление между разными агентами. Этот подход хорош для гибкой настройки, э, и для решения сложных задач. А есть отдельные API для текстовых и голосовых агентов. И оркестрация инструментов, да, происходит с помощью языковой модели. А здесь важная вещь, да, что когда мы говорим условно про агента на базе Responses API или Realtime API, оркестратором выступает сама языковая модель, которая выбирает, какой инструмент необходимо вызвать. Дальше механикой API происходит вызов инструментов, мы получаем результат. И таким образом внутри реализован цикл вызова инструментов до тех пор, пока, в общем-то, не будет дан конечный ответ. А не всем такой подход подходит там в зависимости от бизнес-требований, да, там требований к ошибкам.
Есть другой подход - low-code first подход. А, то есть вы, например, можете в Workflows задать фиксированную цепочку вызовов, да? То есть условно оркестратором выступает э набор там вот этот процесс, который вызывает разные модели. В нём чуть меньше гибкости, да, но при этом больше предсказуемости и больше контроля. Опять же, нельзя сказать, что есть какой-то один там правильный существующий подход. То есть можно экспериментировать из тем с другим подходом и выбирать тот, который подходит под задачу, там лучше себя показывает на метриках, отвечает там нефункциональным требованиям и так далее.
Давайте теперь более подробно поговорим про те API, которые доступны в платформе. И для этого я передаю слово Насте, тебе.
Спасибо. Как подобрать API под свою задачу? Если вам нужно просто обращаться к языковой модели, подойдёт Completions API. Это максимально базовое простое stateless API, который позволяет получить ответ на текстовый запрос. Если нужно что-то более сложное, например, построить текстовый агент, который хранит и использует историю диалога, использует инструменты, такие как файловый или веб-поиск, обращается по протоколу MCP. Используйте Stateful Responses API. Для голосовых сценариев, а аудиоподсказок, создания голосовых агентов, ассистентов лучше всего подойдёт Realtime API. Это специальный, а, спроектированный для работы со звуком и оптимизированный под минимизацию задержек API, а, который поддерживает тот же самый набор инструментов, что и Responses.
Если агенту нужно обращаться к документам, а, использовать данные, которые у них хранятся, используйте Vector Store API и Files API. Эти два API позволяют загружать документы, строить поверх этих документов поисковый индекс и выполнять поиск по их содержимому. Если нужен более низкоуровневый смысловой поиск, кластеризация, поиск аномалий, используйте Embeddings API. Своего рода это альтернатива до какой-то степени Vector Store, но более низкоуровневая и применимая к большему спектру сценариев. Если нужна текстовая классификация, например, для определения тональности обращения, для распределения обращений в поддержку, определения темы, подойдёт Text Classification API. Все эти API, мм, они позволяют, они закрывают полный цикл создания агентов от простого обращения к модели до сложных систем с памятью, поиском и голосом. А, давайте перейдём и рассмотрим более подробно конкретные API, классификаторы. Дима, тебе слово.
Про классификаторы мы уже подробно рассказывали в одном из наших вебинаров. Это был вебинар, посвящённый инструментам дообучения языковых моделей внутри AI Studio с помощью LoRA. И там же у нас был большой блок про а классификаторы. Поэтому мы не будем здесь на них останавливаться подробно. А, рекомендуем перейти по QR-коду, по ссылке и посмотреть, а, вебинар про LoRA и про классификаторы.
А один из основных API, которые сейчас доступны в AI Studio - это Responses. Что же он из себя представляет? Какие функциональные возможности он даёт? Первое - это автоматический вызов встроенных инструментов. То есть, когда вы делаете обращение к Responses API, вы указываете какие-то инструменты, а то в зависимости от решения модели, да, например, модель может определить, что там для решения задачи пользователя, для ответа на пользовательский запрос нужно сходить в поиск. А Responses API автоматически вызывает инструмент поиска. А происходит инструмент там ищет необходимую информацию в векторной базе, возвращает результат. Если этого результата достаточно, если модель считает, что всё информация собрана, можно ответить на вопрос пользователя, а Responses API возвращает этот ответ и дальше там при необходимости дальнейшая обработка уже происходит на стороне приложения, которое этот Responses API вызывает. При этом могут быть ситуации, когда нужно много вызовов инструментов в рамках одного запроса. Эта логика также реализована в Responses. То есть, например, мы можем сходить один раз в поиск, второй раз поиск, там пойти в вектор, пойти в WebSearch, поискать что-то в интернете и затем сгенерировать результат. В Responses API подключаются внутренний поиск, WebSearch Tool, MCP. И, конечно же, вы можете реализовать какую-то свою собственную кастомную логику через function calling.
На вход в Responses API могут передаваться текст либо изображение в формате Base64. И здесь опять же важно сказать, что проверяйте в документации модели какие поддерживают и изображение, и текст, какие только а текст. Ещё одна важная вещь - это автоматическое хранение контекста диалога. То есть параметрами в Responses API вы можете регулировать, а, во-первых, стоит или не стоит сохранять контекст. Для для этого есть параметр store. И кроме этого вы можете передавать ID предыдущего сообщения при обращении в Responses. То есть вы сделали первое обращение, получили ID обращения, и когда вы делаете уже второе обращение в Responses, вы параметрам можете передать ID предыдущего сообщения. И тогда Responses автоматически подтягивает вот это всё, а, вот этот весь как бы тред, да, весь этот контекст, передаёт его в модель. И модель, соответственно, отвечает с учётом всего этого предыдущего контекста. А поддерживаются режимы как стриминговый, так и background-режим, да, для каких-то долгих, э, там, э, операций, например, тулов, которые там обработка, а, которых занимает долгое время.
Realtime API - это основа для создания голосовых агентов, которые умеют общаться в реальном времени. Это API, который был специально оптимизирован на голосовое взаимодействие. Для большинства сценариев, а время между тем, как пользователь закончил говорить и тем, как система ответила, составляет менее одной секунды. Конечно же, это не касается каких-то долгих вызовов, когда происходит какой-то долгий MCP запрос, занимающий секунды. А что важно знать про этот API? Во-первых, то, что он поддерживает не только аудио, но ещё и текст. То есть вы можете строить гибридное приложение, когда агент воспринимает речь, отвечает голосом, но при этом понимает ещё текстовые команды и при этом может отвечать текстом. Ещё одна особенность Realtime API - это двусторонний стриминг речи и текста через постоянное WebSocket соединение. А модель получает звук а буквально в реальном времени. То есть никто не ждёт, никто не ждёт, что фраза закончится. А когда пользователь закончит говорить, фраза поступает вот ровно так, как пользователь её произносит через partial result. Встроенные инструменты Realtime позволяют строить полноценных голосовых агентов. Здесь, как и в Responses, доступны поиск по файлам, а поиск по интернету и работа с внешними API и сервисами через поддержку MCP протокола. То есть это позволяет вам не просто использовать голосовой бэкэнд как некую болталку, которая отвечает исходя из тех знаний, которые были заложены на неё, когда она обучалась, но и актуализировать ответы с помощью обращений в интернет, к своим документам, ну и, конечно же, а, к разным сервисам посредством MCP протокола. А Realtime API, как и Responses, хранит и использует контекст диалога. В отличие от Responses, который, кстати, хранит реплики на протяжении 30 дней, а контекст диалога в Realtime API хранится вот в рамках того времени, пока идёт взаимодействие пользователя, пока активирована так называемая сессия. А что ещё важно подчеркнуть в Realtime API - это то, что он полностью совместим с сервисом SpeechKit. Вы можете использовать общие доступные голоса SpeechKit. С ними вы можете ознакомиться на сайте или в консоли, поэкспериментировать в Playground, так и сделать собственный голос, который вы можете озвучивать взаимодействие с агентом. Это Яндекс SpeechKit Brand Voice.
Ещё один, а, даже два, про которые важно знать - это API для работы с документами. То есть для сценариев, когда необходимо построить RAG, да, и чтобы модель опиралась не на свои знания, а опиралась на подгруженные документы, можно использовать Files API и затем файлы, загруженные через Files API, использовать для построения векторного индекса в через Vector Store API. А как это выглядит? Что происходит? Vector Store API позволяет создавать э много поисковых индексов из загруженных файлов. А он позволяет загружать файлы, удалять файлы или же загружать напрямую готовые чанки. Да, всё это происходит без блокирования работы индекса. А то есть ваши агенты продолжают работать, несмотря на то, что вы удаляете и добавляете файлы. Э агенты работают именно с тем состоянием, да, которое доступно на в моменте в Vector Store в векторном индексе. А важный функционал - это, во-первых, фильтрация, то есть, когда вы загружаете файлы в поисковый индекс, вы можете задать этому файлу набор атрибутов, а, формата ключ-значение. И затем, когда вы, например, в Responses сделаете обращение с подключённым индексом, с подключённым Vector Store, а, вы можете указать набор фильтров. То есть я хочу там только те файлы, в которых там ключ соответствует такому набору значений или меньше такого-то или больше такого-то значения. Соответственно, когда происходит обращение, сначала происходит фильтрация по файлам, чтобы они соответствовали этому фильтру. И затем уже непосредственно поиск происходит только по вот этому подвыборке, да, вот этому подмножеству файлов, которые соответствуют поисковым параметрам. И второе, частый запрос - это ссылочная подтверждённость. То есть нам важно смотреть, на базе чего были сгенерированы ответы. Также в Responses API можно посмотреть источник, да, и получить ссылку на файл либо фрагмент, на базе которого а формировался ответ. А, и что важно, да, поиск по данным, которые хранятся в Vector Store, он происходит как вызов инструментов. То есть, в отличие от предыдущих, например, подходов, если вы работали с ассистент API, где поиск происходил при каждом вызове, то здесь Vector Store поиск происходит в тот момент, когда языковая модель принимает решение этот инструмент вызвать. То есть здесь важно, что информация о наличии этого инструмента, о о том, когда его нужно вызывать, прописана в системной инструкции, в системном промте. А и, соответственно, выбрана та модель, которая хорошо умеет, во-первых, понимать инструкцию, хорошо умеет вызывать инструменты. А потому что вполне возможен сценарий, что модель, например, не понимает, когда нужно вызывать или неправильно вызывает. Поэтому здесь для реализации RAG сценариев важно не только подключить векторный поиск, но и ещё корректно настроить языковую модель для работы с ним.
Мы поговорили про Responses, про Realtime, про Vector Store, и хотелось бы сказать пару слов о том, как их объединить или переиспользовать. Большим плюсом платформы AI Studio является то, что многие из инструментов, а, могут они образуют экосистему и, соответственно, могут переиспользоваться в э в различных API, в различных компонентах. То есть, если я хочу построить, например, RAG сценарий, да, там историю, что у меня, а, ну, частый сценарий, который у нас есть - это, например, поиск по сайту плюс поиск по каким-то моим дополнительным документам, которые не были опубликованы на сайте. И хочу сделать такого чатбота неважно, текстового, голосового, как будет выглядеть этот процесс построения такого бота, если говорить в терминах API. Сначала мы загружаем файлы через Files API в общее хранилище файлов. Далее с помощью Vector Store API мы добавляем файлы из этого хранилища непосредственно в векторное хранилище. То есть мы, когда подгружаем файл, он, а, парсится, разбивается на чанки, чанки векторизуются, да, обогащаются там, и так далее. И всё это складывается в векторный индекс. И дальше этот векторный индекс подключается к API, к Responses, если мы хотим работать текстом, к Realtime, если мы хотим работать с голосом. И дополнительно, например, мы можем указать и там, и там WebSearch, да, веб-поиск как ещё один инструмент для работы по непосредственно с конкретным сайтом. Таким образом, получается, что мы можем переиспользовать наш поисковый индекс в голосовых и текстовых агентов, а, и точно также переиспользовать там WebSearch Tool для для работы с сайтом.
Ещё одним способом реализовать поиск уже на более низкоуровневой является API Embeddings. Embedding - это векторное представление текста в виде числового массива. Расстояние между двумя массивами позволяет найти смысловую близость. Если расстояние малое, то тексты по смыслу похожи. Если большое, тексты различаются. А Embeddings можно использовать как более низкоуровневую альтернативу Vector Store. И одним только поиском его, конечно же, применение не ограничивается. Так, с его помощью можно делать кластеризацию, когда объединяются, а, схожие по характеристикам элементы, находить аномалии как те элементы, которые разительно отличаются, а, по сравнению с остальными. И также давать персонализированные рекомендации, когда пользователю предлагаются элементы с похожим содержанием. Как использовать Embeddings? Встроенного инструмента, который бы взаимодействовал с Responses API, нет. Но вы можете подключать Embeddings, например, через функцию function calling и реализовать как перечисленные сценарии самостоятельно. А можно использовать как готовые модели, так и дообученные. Да, обучение можно проводить на ваших документах, то есть оптимизировать, а, Embeddings, а, на тройках или парах, которые описывают взаимодействие с вашим документом, например, как вопрос-ответ. Пример вызова Embeddings. Здесь приведён максимально простой базовый код, как можно взаимодействовать с Embeddings. Здесь мы задали две модели, условно это doc_query. Одна предназначена, чтобы работать, а, с большими документами, которые, скажем так, больше, чем размер по размеру, чем запрос, и вторая оптимизированная на короткие запросы. То есть у нас, допустим, приведён некий документ и некий запрос. А в моём случае это "когда день рождения Пушкина", на самом деле, это отсылка к примеру, который есть в нашем репозитории. Вы можете, кстати, по ссылке, которую мы покажем, а, в конце этого видео, пройти и самостоятельно позапускать пример, посмотреть, как всё работает. И дальше вы получаете embedding через специальный API. Задаёте модель. У этой модели должен быть специальный префикс. Указываете в её URI Яндекс Cloud Folder как специальный идентификатор, который даёт вам доступ, и указываете, собственно, модель, которую хотите использовать. Text search, doc search query. Это что касается общедоступных. Если вы дообучили свою, то будете использовать идентификатор дообученной модели. Ну и, собственно, дальше выполняете запрос через client.create. И в качестве артефакта этого выполнения получаете а векторное представление текста. Что с ним дальше можно делать? Вектора, как я уже говорила ранее, можно сравнивать между собой, а, таким образом определяя близость текстов и реализуя те самые сценарии классификации, поиска аномалий и, конечно же, поиска по смыслу.
Очень часто бывает не до конца удобно или, ну, не требуется работать напрямую с API. Больше концепций, да, больше подходов можно реализовать с помощью SDK поверх этих API. И в очень часто с клиентами мы идём именно по этому пути. Например, можно реализовать какие-то более сложные приложения с несколькими агентами поверх OpenAI SDK или Open Agents Development Kit. Можно использовать LangChain, LangGraph. А для ряда сценариев у нас есть свой собственный Яндекс Cloud SDK, который также, например, позволяет реализовать сценарии поиска в интернете или там работы с векторной базой. А, поэтому если вы хотите, если вы, например, только начинаете строить приложение, рекомендуем начинать не не с работы напрямую с API, а, например, посмотреть на существующие SDK и на возможности, которые они предоставляют.
В заключении этого видео хотели бы дать несколько полезных ссылок. Первое - это репозитории с большим количеством примеров, а, работы с API, про которые мы сегодня рассказывали. Это, конечно же, документация, где можно более подробно почитать про все те концепции, которые сегодня обсуждались. Если у вас появились вопросы, вы хотите что-то спросить или чем-то поделиться, переходите, вступайте в сообщество и задавайте вопросы там и следите там за всеми нашими новостями. Спасибо.
Спасибо.