Transcription
Привет всем. А вот вы когда-нибудь думали, что, ну, если бы языковые модели могли не просто текст писать, а, скажем, быть такими активными помощниками, например, там, не знаю, моментально найти самую свежую новость в сети или что ещё круче, проанализировать вот ваши личные файлы, данные и всё это без сложного программирования. Ага, такая перспектива, да, заманчивая.
Вот сегодня мы как раз и хотим погрузиться в эту тему. Встроенные инструменты от Open AI. Их представили на сессии Билдеур. Это, ну, как бы как будто моделям выдали суперспособности. Суперспособности - хорошее сравнение, да, и разбирать мы это будем на основе материалов как раз с той самой сессии. Build hour, Build in Tools. Там было видео, демки, примеры от самих разработчиков OpenI и ещё кейс от их клиента компании HI. То есть источник у нас надёжный из первых рук. Мно.
Так что задача у нас сегодня такая: понять, что это вообще за инструменты, ээ, как они работают, ну, под капотом, сильно ли они отличаются от, скажем, вызовов функций function calling, с которым многие уже, наверное, работали. Угу. И, конечно, самое главное, как их можно применить, чтобы делать приложения, ну, по-настоящему мощными. В общем, давайте разбираться.
Давайте начнём с самого простого. Что такое встроенные инструменты? Вот как бы вы это объяснили? Ну, смотрите, проще всего представить это как набор готовых модулей. Вот есть модуль для поиска в интернете, есть для работы с файлами, которые вы загрузили, есть для выполнения кода. Угу. И эти модули можно, так сказать, подключить к моделям Open AI. Но самое главное, вам, как разработчику, не нужно писать код, чтобы этот поиск или анализ файла реально произошёл на вашей стороне. То есть, а, то есть модель сама, когда ей нужно, понимает, ага, тут мне нужен веб-поиск или тут надо заглянуть в этот PDF. Она сама инициирует вызов этого инструмента. Он выполняется на серверах Open AI и результат используется для ответа.
Хм, звучит действительно проще. Вот в этой простоте и есть, наверное, ключевое отличие от function calling. Помните, как там? Ну да, там модель говорит: "Сделай вот это". Потом ты у себя в коделаешь и результат обратно модели скармливаешь. Три шага получается именно запрос модели, выполнение у вас, ответ модели. А здесь, ну, почти для всех этих встроенных инструментов, кроме одного компьюте, о нём позже, всего два шага. Модель решила использовать инструмент, и он тут же автоматически выполняется Open AI. Результат сразу готов. Понятно. То есть это прямо снимает кучу головной боли с разработчика. Не надо свою логику поиска писать. Парсеры для файлов. Совершенно верно. И не только писать, но и поддерживать, масштабировать. Open AI берёт это на себя. Вы просто говорите модели. можешь использовать вот эти инструменты. А дальше, ну, не магия, конечно, но всё происходит на их стороне. Это, конечно, сильно снижает порог входа. Можно делать более сложные вещи быстрее. Да, именно так.
Хорошо, давайте тогда пройдемся по конкретным инструментам. Какие там суперспособности уже есть? Начнём с веб-поиска. Websearch. Его упомянули, да? Вебпоиск. Его главная задача понятна. Модели ведь обучаются на данных до какой-то точки во времени. Ну да, в видео говорили про май 2024 для тех моделей. То есть спроси их, что было вчера, они, ну, не в курсе. Вот. Апоиск даёт модели возможность, так сказать, выйти в интернет через поисковые системы Open AI и получить самую свежую информацию.
В Playground показывали на простых примерах, типа какая погода в Сан-Франциско сейчас или там когда выйдет GPT5. Ну, на такой вопрос она, конечно, не ответит точно, но сам факт запроса, да, и там ещё была фишка с настройкой локации, чтобы поиск был релевантнее, если это важно. А вот реальный кейс от Хейбил интересный. Им нужно было оперативно следить за влиянием недавних торговых тарифов Трампа. Понятно, что в обучающих данных модели этого и близко не было, ипоиск стал для них решением. Да, но тут, я думаю, важно понимать, это не просто, ну, скажем, подключение к Google или Яндексу. Скорее всего, Open AI используют свои, возможно, оптимизированные под LLM поисковые технологии, чтобы модель лучше понимала результат. И именно, чтобы информация приходила в таком виде, который модель может легко переварить и использовать в ответе. Ну и плюс вопрос актуальности, какие-то базовые проверки источников, это тоже, видимо, на их стороне. Хотя, конечно, стопроцентно доверять веб-поиску никогда не стоит. Критическое мышление никто не отменял. Это точно.
Хорошо, с поиском понятно. Следующий, и вот он, мне кажется, очень многих интересует, поиск по файлам. File search. Как заставить модель отвечать на вопросы, используя вот мои документы, мою базу знаний и чтобы не надо было модель дообучать, что долго и дорого. Да, это прямо горячая тема. И fileа - это, по сути, реализация. того самого Retrieval Augmented Generation. Ага. Генерация с дополнением извлечённой информации. Точно. Вы просто загружаете свои файлы, там PDF, диосы, X, что угодно поддерживается, а Open AI дальше делает всё сама. Она эти файлы бьёт на кусочки начанки, разбивает на фрагменты. Да. Да. И для каждого фрагмента создаёт специальное числовое представление edн, которое отражает смысл этого фрагмента. И всё это складывается в так называемое векторное хранилище. Векторное хранилище. Звучит сложно, но если упрощать, это как специальная база данных. Она умеет очень быстро находить фрагменты текста, похожие по смыслу на ваш запрос. Не по ключевым словам, а именно по смыслу, благодаря этим эмбедингам.
И что происходит потом? А потом, когда вы задаёте вопрос модели, она сначала идёт в это векторное хранилище с вашими файлами, ищет там самые подходящие, самые релевантные фрагменты, а уже потом на основе найденного генерирует ответ. То есть она отвечает не из своей общей эрудиции, а конкретно по моим документам. Именно так. И это ключевое. В плейграунд показывали демку, загрузили PDF с описанием этих же инструментов из блога Open AI, а потом спросили, какие инструменты тут описаны. И модель не просто перечислила их, она ещё и ссылки дала. Да, дала аннотации со ссылками прямо на конкретные места в PDF-файлах, откуда она взяла информацию. Это же супедобно для проверки. Вот. И тут мы подходим к тому, почему это так ценно. Сделать хорошую раксистему самому, это, ну, не просто. Надо правильно выбрать размер чанков, модель для эмбедингов, алгоритм поиска настроить, ранжирование результатов, там куча нюансов. Да, я слышал, это целая наука. А Openaa говорит: "Мы всё это оптимизировали за вас. Они взяли на себя и предобку, и сам поиск, и предлагает это как готовое решение. Для многих это может быть огромной экономией времени и сил. Получается такой рак из коробки в каком-то смысле. Да, с упором на простоту. Конечно, если у вас какие-то суперспецифические требования или нужен полный контроль над каждым шагом, возможно, вы всё равно будете строить своё, но для большинства задач это, ну, очень привлекательно. Ясно?
Так, с файлами разобрались. Идём дальше. Интерпретатор кода. Код интерпретер. Этот инструмент вроде бы уже был в чат GPT+. Да, он был доступен в веб-интерфейсе GPT, а теперь его выкатили и в API. И в чём его суть? Он код выполняет. Именно он не просто пишет код на Python, он может его реально выполнить в безопасной, изолированной среде. И это открывает двери для задачи, где нужна точность вычисления или, скажем, анализ данных.
Пример из Playground был как раз про анализ данных, да, про погоду в Сан-Франциско за 10 лет. Да, очень показательный пример. Модель попросили сравнить погоду. Что она сделала? Сначала раз сходила в интернет с помощью веб-поиска, нашла данные. Ага. Свежие и исторические. Потом два использовала интерпретатор кода, написала скрипт на Python, чтобы эти данные обработать, проанализировать. И в итоге выдала не просто текст, а сгенерировала график, диаграмму, которая наглядно всё показывает. Вот это круто. То есть она может не только считать, но и визуализировать. Да. И ещё она может работать с файлами, которые вы ей даёте. Например, загрузить CSV с продажами и попросить посчитать выручку или найти топ-торы именно или построить тот же график продаж по месяцам. В чём здесь главное преимущество перед тем, чтобы модель просто сама попыталась посчитать? В точности. Модели, особенно на сложных вычислениях или при анализе больших данных, могут, ну, галлюцинировать, ошибаться. А когда выполняется реальный код, результат предсказуем и точен. Плюс вот эта возможность генерировать файлы, графики, отчёты, даже изображения в теории, это уже не просто ответ текстом, это полноценный результат работы. То есть модели становятся таким мини-аналитиком данных, который может и данные найти, и обработать, и результат показать. Ну, в какой-то степени, да, для многих задач этого может быть вполне достаточно. Интересно.
Так, и остался у нас ещё один инструмент из основных MCP Tool для работы с протоколом MCP. модул контекст протокол звучит как-то технически, да, название такое, но идея за ним довольно простая и мощная. MCP - это, по сути, попытка создать стандарт, единый язык, на котором внешние сервисы, ну, там сайты, приложения, базы данных могли бы описывать свои апии. Апии - это интерфейсы для взаимодействия программ, верно? Да. чтобы модели могли легко понимать, что умеет делать тот или иной сервис и как с ним общаться. Как будто у каждого сервиса есть универсальная инструкция по применению для Здраствуйте. И MCP Tool - это инструмент, который позволяет модели эту инструкцию прочитать и воспользоваться сервисом. Именно модель может подключиться к любому внешнему серверу, который поддерживает этот протокол MCP.
В демке показывали примеры с известными сервисами Shopify. Ага. чтобы поискать товары в магазине. Да, например, электровелосипеда в конкретном магазине или страй, чтобы проверить баланс счёта. Понятно, что для этого нужен ключ API, ваш секретный пароль к сервису. Логично. И там ещё упоминали опцию пропускать подтверждение действия пользователем, ну, для каких-то безопасных рутинных операций, чтобы автоматизировать процесс. И какие перспективы у этого MCP? О, вот тут, мне кажется, самое интересное начинается. Если этот протокол MCP станет популярным, то модели смогут не просто искать что-то или считать. Они смогут делать реальные вещи: заказывать товары, отправлять письма, управлять проектами, взаимодействовать практически с любым сервисом, который подключится к этой экосистеме через MCP. То есть это шаг к таким универсальным цифровым помощникам. Именно стандартизация здесь ключ. Если все будут говорить на одном языке MCP, то интегрировать модель с новым сервисом станет намного проще. Не нужно будет для каждого писать свой отдельный коннектор, как раньше. Вот разработчикам моделей нужен будет один инструмент MCP Tool, а разработчикам сервисов один раз описать свой API по стандарту MCP. И всё, их сервис доступен для всех совместивых моделей. Потенциал огромный. Да, звучит многоощающее.
Но вот как все эти разные инструменты, поиск, файлы, код, MCP работают вместе. Показывали какое-то демоприложение? Да. Да. Панель для анализа данных. Очень наглядная демонстрация. Сценарий там был такой. Есть владелец магазина здорового питания. У него продажи идут и онлайн через Skype, и оффлайн. Он их ведёт в Excel-файле. И ему нужен инструмент, чтобы задавать вопросы на обычном языке и получать аналитику по всем этим данным сразу. И в демке показывали, как легко эти инструменты добавить в код. Там был примерно Python SDK, но сказали, что и для веба JSTS есть. Буквально нужно было перечислить название инструментов web, File search, Code interpreter, MCP Tool в вызове нового responses API. Респонс из API - это что-то новое, видимо, да. API, который как раз и управляет использованием этих инструментов. Говорили, что настройки можно прямо из плейграунда скопировать. Удобно.
И вот пример синергии. Задали такой вопрос: "Покажи платежи Strikee за последнюю неделю и выведи карточки. Сколько всего клиентов, сколько было неудачных платежей и на какую сумму? Ого! Такой составной запрос. Да. И чтобы на него ответить, модели что нужно было сделать? Во-первых, сходить в Strikee через MCP Tool за данными. Угу. Во-вторых, возможно, использовать код интерпретер, чтобы эти данные посчитать, агрегировать, ну, там, количество клиентов, сумму неудачных платежей. Логично. И потом уже сформировать ответ. И фишка в том, что модель сама решала, какой инструмент когда использовать, в какой последовательности. Вот здесь как раз и важен этот с API, о котором вы упомянули. Он, по сути, оркеструет весь этот процесс. Он помнит контекст диалога и позволяет модели делать несколько шагов, вызывая разные инструменты, чтобы прийти к финальному результату. Это уже не просто запрос-ответ, это целый рабочий процесс. Такой мини-агент получается, можно и так сказать. И ещё, конечно, важен системный промпт, то есть начальные инструкции для модели. В примере говорили, что там можно указать важные детали, например, что цены в страйp приходят в центах али в долларах. Или дать подсказку, когда какой инструмент лучше использовать. Хороший промпт, он как бы направляет модель. Да.
И ещё был забавный технический момент, чтобы вот эти результаты карточки с цифрами показать красиво именно в интерфейсе дашборда, а не просто текстом. А, да, что там было? Им всё равно пришлось использовать старый добрый вызов функций. Function calling. Они сделали свою кастомную функцию generate component. А почему? А потому что встроенные инструменты выполняются где-то там на серверах Open. А чтобы обновить картинку в браузере у пользователя на его компьютере, нужен был механизм, который вернёт данные именно в клиентское приложение, и для этого подошёл function calling. А, ну да, логично. Это хорошо показывает, что эти подходы, встроенные инструменты и functionш calling, они не взаимоисключающие, они могут отлично работать вместе. Встроенные инструменты берут на себя, скажем так, тяжёлую работу с данными, с внешними системами. А колинг можно использовать для тонкой настройки интерфейса или для вызова каких-то совсем специфических функций, которых нету Open AI. Хорошее замечание. То есть выбираешь инструмент под задачу. Именно так.
Ну и давайте посмотрим на практику. Кейс компании Heb. Они ведь как раз занимаются финансами, юриспруденцией, там, где поиск информации критичен. Да, они поделились своим опытом. Как они используют веб-поиск? Ну, во-первых, как мы уже говорили, чтобы получать актуальную информацию, которой нету модели. Пример с тарифами. Угу. А, во-вторых, у них интересная стратегия исследование, использование. Explore, exploit. Они сначала делают широкий веб-поиск по теме, чтобы, ну, как бы оглядеться, понять контекст, а потом уже запускают глубокий поиск по своим специализированным базам данных, уже зная, что конкретно искать. Такой двухэтапный подход. Да, и ещё они встроили веб-поиск в свой продукт Matrix. Это какая-то платформа для масштабного анализа. Она может параллельно тысячи запросов делать по разным компаниям, собирать данные, финансы, новости и всё это структурировать. Вебпоиск помогает им получать самые свежие данные из сети для этой матрицы. Внушительно.
А вот про MCP их мнение было прагматичным. Они говорят: "Да, идея стандартизации - это супер". Но для их корпоративных клиентов нужны очень высокие гарантии качества поиска по внутренним документам. Поэтому они сделали свой собственный MCP-сервер. То есть не стали использовать готовое решение. Они используют саму идею протокол MCP, но сервер реализовали свой, который работает поверх сложной системы индексации и поиска, чтобы гарантировать ту точность и релевантность, которая нужна их клиентам. Это, кстати, очень важный момент. Он показывает, что Open AI даёт мощные кубики LEGO. Но для сложных специфических задач компании всё равно могут строить свои конструкции поверх этих кубиков. Хибазе взяли концепцию MCP, но адаптировали её под себя, под свою основную технологию. То есть это гибкая система: "Хочешь, бери готовое, хочешь строй своё". На тех же принципах. Именно так.
Ну что ж, давайте попробуем как-то ээ подвести черту. Что мы имеем в итоге? Встроенные инструменты Open AI - это, ну, прямо серьёзный шаг вперёд. Модели теперь могут не просто болтать или писать тексты. Ага. Они могут взаимодействовать с реальным миром, получать свежую информацию, копаться в наших файлах, делать точные расчёты, дёргать внешние сервисы и всё это, что важно, с гораздо меньшими усилиями для разработчиков. Я бы сказала, ключевой вывод - это движение от просто чатботов к более сложным мм агентным системам, то есть системам, которые могут понять задачу из нескольких шагов, спланировать действия и использовать разные инструменты: поиск, код, API, чтобы эту задачу решить. И Responsis API как раз помогает этим управлять. Да, похоже, что responsнс API и сами инструменты - это как раз инфраструктура для создания таких агентов. Мы увидим, как модели становятся более автономными, что ли, способными решать реальные проблемы. Если модели так легко учатся пользоваться инструментами, получают доступ к данным реального времени, анализируют наши файлы, могут даже что-то сделать через API, там, не знаю, в магазине или в сервисе. Угу. То где теперь граница проходит? Вот когда языковая модель - это уже не просто модель, а полноценный цифровой ассистент или даже агент, который сам действует в цифровом мире. Хороший вопрос. Насколько мы вообще близки к Ии, который сможет взять на себя сложную задачу, не просто текстовую, а комплексную, и решить её от начала до конца. Вот об этом, наверное, стоит подумать, да? Пища для размышлений определённо есть. На этой ноте, наверное, и закончим наш сегодняшний разбор. Напомню, все детали и примеры мы брали из сессии Open AI Build Hour. Спасибо, что были с нами и погрузались в эту тему. Спасибо.