Субтитры создавал DimaTorzok
Подписывайтесь на наш канал!
Про текстовые агенты и обновления в текстовых агентах, про голосовые агенты, про поиск и вообще домен AI-серч в интернете, в файлах и так далее.
И автоматизация процессов с помощью лоу-код инструмента Workflows.
Если чуть подробнее посмотреть на каждый из этих блоков, хотелось бы сегодня рассказать, куда мы хотим двигаться по каждым из этих направлений.
Это такие самые ближайшие планы и ближайшие инструменты, которые будут появляться в AI-студию в следующие месяцы.
На первом вебинаре в части про Responses мы много рассказывали про управление контекстом, про Truncation, то есть для автоматического обрезания диалогов,
про новый компонент мониторинга и трейсинга, чтобы отслеживать работу агентов, и обновление раздела мониторинга.
Конечно, мы хотим развивать дальше автоматическое управление контекстом.
Транкейшн — это первый подход, но он далеко не единственный возможный.
Мы хотим более гибко и умно уметь работать с контекстом, и в этом направлении у нас скоро будут обновления
по поводу более умного, качественного сжатия истории диалога при работе с длинными цепочками историй.
Скиллс. Про них были вопросы и в комьюнити, и понятно, что сейчас скиллы стали по сути стандартом.
В ближайшее время у нас появится поддержка скиллов в Респонсос.
Даже могу немножко тут засполерить, что они уже практически готовы, у кого прям очень горит,
и есть интерес попробовать как можно раньше.
Приходите, пишите, будем давать возможность, для части пользователей сможем выдать бета-доступ.
И отправка файлов в Респонсос API, тоже один из самых, наверное, частых запросов от клиентов, от пользователей.
То есть возможность напрямую в модели отправлять разные типы файлов, PDF, .docx и так далее, без отдельного построения поискового индекса.
По голосовым агентам мы в первую очередь целимся в повышение качества.
Повышение качества за счет более больших новых моделей для обработки длинных контекстов чатов.
Это новые модели синтеза для голосовых сценариев.
Это конструктор промтов, потому что на самом деле то, как будет сформирован промт для голосового агента, очень сильно сейчас влияет на качество этого робота.
И в целом набор оптимизаций и улучшений по диалоговым механикам.
Про поисковые продукты. Здесь у нас основной фокус остается на качестве.
Причем как на качестве поиска в интернете, так и на качестве поиска по файлам, то есть на RAC сценариях.
Из обновлений, которые скоро появятся, это поиск по нескольким индексам.
Те, кто использует RAC, знают, что сейчас у нас ограничение на один подключенный векторный индекс в Responses.
Это ограничение мы хотим снять и дать возможность искать по нескольким поисковым индексам одновременно.
И что касается лоукода, то здесь у нас также продолжается тренд на упрощение использования.
Это новые кубики в workflows для автоматизации сценариев.
Это более тесная интеграция с теми инструментами, которые есть уже сейчас внутри AI-студия.
И это дальнейшие шаги по упрощению работы и старта, и собирания запуска потоков в workflows.
Если говорить про следующие мероприятия, которые касаются обучения,
то хотели бы вас пригласить на вебинар, который будет 6 августа.
Он будет таким предваряющим вебинаром по теме скиллов.
Мы вообще начнем говорить о том, что такое скиллы, как их можно уже сейчас реализовывать в AI-студию,
не дожидаясь отдельного API.
И через какое-то время мы, как и сказал, добавим возможность и создавать,
и автоматически использовать скиллы в Responses API.
Зачем вообще мы проводим эту серию?
В чем я имею в виду AI-студия сериалов?
В первую очередь, конечно, мы видим, что есть большой набор вопросов, запросов.
Не везде получается разобраться в документации.
Много разных компонентов, платформа большая,
поэтому мы хотим помочь разобраться и начать работать с компонентами AI-студия.
Конечно, нам важен рост комьюнити.
И, в общем-то, сегодня мы подробнее поговорим, куда мы вообще хотим двигаться,
что собирают клиенты в наших технологиях и что у нас будет появляться новое.
И, наверное, ключевое, нам очень важна обратная связь разными способами и лично, и в чатах.
Поэтому, если у вас есть что поделиться, что-то болит или, наоборот, что-то нравится,
пожалуйста, подходите, рассказывайте, с удовольствием все это обсудим.
Более такой формальный способ. У нас есть отдельный портал.
Вы можете оставить там ваши идеи, мы все их отсматриваем и учитываем при приоритизации следующих фичей.
Поэтому, если у вас какие-то есть горящие запросы, чего не хватает в iStudio,
и что мы не рассказываем в фланах, но очень нужно, пожалуйста, оставляйте ваши идеи.
Если переходить к сегодняшнему мероприятию, то мы подготовили несколько выступлений.
Два выступления будут от наших партнеров-клиентов.
Одно будет посвящено текстовому агенту от компании DemiLand.
Коллеги расскажут о том, как они построили чат-бот в разных мессенджерах на базе iStudio для текстовых сценариев.
А коллеги из компании StroyNrk.com расскажут как раз про голосовых агентов и те сложности,
с которыми столкнулись при построении и как они эти сложности решали.
В заключение будет мастер-класс от архитектора из Яндекс.Клауд,
который расскажет про разные подходы к проектированию архитектур и агентов.
Ну а начать мы бы хотели с бонусного доклада от Сережи Нарбута.
Это руководитель разработки в iStudio.
И мы много говорим про разные API в iStudio, как они работают, но мы понимаем, что как бы сейчас разработкой мало кто пишет код самостоятельно с нуля.
То есть, как правило, это делают агенты уже сейчас.
И о том, как можно писать код для работы с iStudio с помощью кодекса, который работает в iStudio, подробно расскажет Сережа.
Всем привет. Счастья, здоровья. Мечтал сказать эту фразу со сцены достаточно давно.
И я чуть-чуть хочу рассказать про то, что сейчас мир уже достаточно изменился.
Если раньше все говорили про модельки, то на самом деле сейчас все движется вокруг Harness, вокруг агентов.
Мы в iStudio активно идем и разрабатываем режим совместимости с OpenAIP, а в OpenAIP есть свой, собственно, готовый агент.
Готовый Harness — это кодекс. И его достаточно просто запустить поверх нас.
Что для этого нужно? Для этого нужно всего лишь написать небольшой TOML файл с профилем для подключения к Яндекс.Студии и запустить, собственно, кодекс с нужным профилем.
Что же такое этот TOML файл? Во-первых, это два файлика.
Один из этих файлов — это, собственно, само описание профиля, то есть endpoint, способ авторизации, ограничение различных моделей.
А второй файл — это вот этот JSON-файл.
Задержим три себя просто набор моделей с их описаниями для кодекса для того, чтобы он лучше ими использовал.
Например, там можно задать промт отдельный, можно описать размер контекста, окна, всякий reasoning, уровни reasoning, которые поддерживают модели.
И запустить с флагом Яндекса и Естудии.
Тогда ваш кодекс будет работать напрямую поверх моделей наших, развернутых у нас, и полноценно полностью работать.
Соответственно, сейчас можно посмотреть уже написанную инструкцию по тому, как подключить.
Там есть и пример полного файла конфигурации и, собственно, сам JSON.
Что ж, давайте тогда посмотрим, зачем нам все это нужно делать.
Казалось бы, мы подключили, и что дальше?
Здесь вот еще есть ссылочка, кстати, на MCP к Яндекс.Облаку.
Так что если вы хотите управлять Яндекс.Облаком при помощи MCP,
вы также можете его подключить к кодексу абсолютно нативными способами и взаимодействовать с облаком.
Что нам это дает?
Во-первых, у многочисленных агентов, таких как, например, OpenCode,
у них есть некоторые проблемы с веб-серчем.
Веб-серч вам нужно настраивать полностью самим.
В респонсе с API и, соответственно, в кодексе поддержан веб-серч,
то есть поиск в интернете нативно.
Этот инструмент просто работает.
Соответственно, многочисленные задачи, которые решаются при помощи поиска,
агент из коробки теперь умеет делать.
Соответственно, вы можете полностью работать с нашими моделями,
работать с нашими агентами, искать информацию в интернете нативно,
через кодекс и для всяких задач его использовать.
Я слышал часто в комьюнити, как все говорили,
что достаточно сложно документацию Яндекс.Студии получить.
Сложно, если бы не было веб-серча.
Веб-серч прекрасно с этим справляется.
Я здесь запускаю агента без всяких MCP.
Это чистый агент с чистым веб-серчом.
И спрашиваю у него простой вопрос, если я там не опечатался, конечно.
Что же такое AI-студия?
Агент про AI-студию ничего не знает.
Это чистый кодекс.
Никаких системных промтов, ничего нет.
И мы видим то, что агент при помощи веб-серча пошел в интернет.
Буквально на сайт Яндекс.
AI-студия, смотреть документацию.
И вот он что-то написал.
Я, к сожалению, не вижу отсюда, что он написал,
но что-то вроде бы достаточно адекватное.
И теперь я в целом спрашиваю у агента
всякую информацию про сам респонс.
Как создать агента?
И сейчас мы увидим то, что он опять при помощи инструмента поиска по интернету,
который мы, кстати, недавно достаточно крупно обновили
и рассказывали на одном из предыдущих докладов,
он идет и ищет документацию.
Что из этого можно сделать?
То, что кодекс просто при запуске поверх AI-студия
может прекрасно находить любую информацию,
в том числе документацию, и писать агентов.
Вон он тут какой-то уже код написал,
как запустить агента поверх респонса SAP,
даже голосового агента и поверх Node.js, по-моему.
То есть он все нашел, все примеры,
теперь все он это знает.
Вот он все еще продолжает писать.
И чуть позже, когда он закончит писать,
я попрошу у него более сложную задачку.
Это рассказать про векторные индексы,
как ими пользоваться с точки зрения кода.
По-моему, я там опять опечатаюсь,
но это не так важно, модель прекрасно меня поймет.
Что же опять произойдет?
Все аналогично.
Инструмент не знает, что это такое.
У него есть инструмент веб-серч,
и он идет искать информацию.
Только это печатаем.
Как вы видите, то, что во время поиска
прямо в интерфейсе вы видите строчки,
название сайтов, которые он ищет,
какие сайты он открывает,
какие запросы он даже посылает.
И, как мы видим, вот снова он нашел нам код,
полностью скрипт, как создать векторный индекс,
как его использовать, все с нашей документацией.
Соответственно, используя кодекс,
вы получаете доступ к нашей документации
и в целом любой информации в интернете.
Нативно через нас не нужно настраивать
никакие интеграции, например, с DuckDuckGo
или прочими, и покупать дополнительные токены
в сторонних API.
Вот, все работает.
Сейчас он закончит генерировать.
И даже нарисовал красивую схемку в ASCII-арте.
В целом мог бы и в чем-нибудь другом нарисовать,
но я его не просил.
Это один из кейсов, так что ура!
Те, кто очень хотел искать документацию,
теперь могут пользоваться просто нативным веб-поиском.
И теперь давайте перейдем немножечко к следующей информации.
Тут, кажется, где-то должно быть еще одно видео.
Но его, видимо, нет.
В чем? Что еще можно делать при помощи, соответственно, кодекса?
Если вы подключите MCP к кодексу абсолютно нативным способом,
то кодекс, естественно, научится работать с EA Studio целиком.
Он может искать логи, смотреть, он может запускать клауд-функции,
создавать MCP workflows, он может пытаться понять,
почему у него что-то не запустилось, он может, ко всему прочему,
пытаться что-то дебажить.
Соответственно, таким образом вы получаете полноценного агента,
который работает поверх EA Studio, поверх кодекса,
вы пользуетесь всеми наработками OpenAI, но поверх нас.
Это достаточно выгодно, достаточно хорошо.
Вы получаете полную здесь изоляцию, работу внутри России,
но при этом вы можете пользоваться нативным инструментом.
Как раз это одна из целей, почему, в принципе, мы работаем в режиме OpenAI Compatible.
Вы не только можете писать свой код, просто подменяя endpoints,
но вы можете использовать готовых агентов,
которые представляют вам и целые агентские циклы,
полностью harness, веб-поиск.
Все это можно делать через нас.
Поэтому советую пользоваться, советую попробовать профиль подключения
и советую подключить, собственно, MCP.
Возможно, даже чуть позже, может быть, я сделаю и выложу плагин
для подключения всего Яндекс.Облака к агенту.
Получается достаточно хорошо.
Вот, было бы видео, но его, видимо, украли гномы.
Спасибо.
Так, Сереж, верните, пожалуйста.
Так, пару слов перед вопросами.
Во-первых, если у вас появляются какие-то вопросы, у вас будет те, кто в зале, задать возможность их спикеру прямо здесь.
Те, кто смотрит трансляцию онлайн, пожалуйста, оставляйте вопросы в чате в iStudio Community в Телеграме.
Мы их будем отбирать и зачитывать спикером.
Вот, пока вопрос от меня.
Ну, как бы ты рассказал про кодекс.
Можешь рассказать вообще про те среды для разработки, которые ты используешь?
Может быть, если есть что-то кроме кодекса, как ты их настраиваешь?
Вообще какие-то там заветы, практики?
Я использую достаточно много агентов.
Преимущественно я сейчас использую кодекс.
Мне нравится то, как он взаимодействует, собственно, с моделями,
как он взаимодействует с файловой системой.
Достаточно безопасно.
У кодекса есть различные профили защиты, режим подтверждения.
Например, он заблокирует сам автоматически вызов странных команд.
Потому что все мы знаем, что модели, запущенные на реальном железе,
иногда могут делать несколько странные вещи, пытаясь решить поставленную задачу.
Также я еще использую OpenCode.
OpenCode более гиковская штука, преимущественно предназначена именно для написания кода.
Тоже использую поверх нас, поверх уже Accompletion SAP,
потому что поддержка Responses в принципе можно запустить,
но в AppSearch, например, там из коробки не заработает.
Если кто-нибудь, конечно, не пойдет и не сделает полноценную поддержку Responses в OpenCode.
А раньше я еще пользовался VS-кодом с подключенным RU-кодом.
Но, как мы знаем, и RU-код закрыли свой плагин, потому что они тоже идут в полноценных агентов.
Как раз важно понимать то, что если всего пару месяцев назад мы все работали и писали код внутри EDE,
и агенты — это было, по сути, достаточно продвинутое автодополнение,
иногда их запускали целиком в написание кода, но все равно мы смотрелись от VDE,
то сейчас мир трансформируется к тому, что мы все больше и больше доверяем агентам
и встроенным скиллам на ревью, например, у кодекса есть встроенный скилл на ревью кода.
Так что нам уже, по сути, не нужно смотреть прямо непосредственно в VDE на то, что напишет агент.
Это, я понимаю, может быть вначале очень непривычно,
там страшно, что напишет агент, что он сделает,
но качественные модели вместе с качественным харнесом вокруг них,
поэтому важно харнес выбирать, позволяет решать эту проблему и писать код условно.
У меня, например, сейчас агент пишет код, пока я выступаю здесь.
Да, очень удобно. Может быть есть какие-то вопросы из аудитории?
Вот, да.
Там нужно нажимать.
Вы упомянули про агентов разных, но ни разу не сказали про SourceCraft Assistant, который яндексовский как раз.
То, что вы сейчас про кодекс рассказывали, там это идет уже из коробки, там оно есть или точно так же нужно это все подключать, чтобы оно поверх работало?
Смотрите, в SourceCraft, насколько я помню, сейчас нет веб-поиска.
Появится ли он там или нет, я сейчас не знаю, но кодекс это уже дает из коробки.
То есть, соответственно, если вы используете кодекс или хотите попробовать, я очень советую.
Это действительно прикольная штука.
Так, тут в онлайн появился, наверное, немножко вопрос не совсем по теме твоего доклада,
но тем не менее, Яндекс и студия крутая штука, и в то же самое время он выглядит как убийца стартапов,
потому что чем проще создавать ей продукты, тем больше конкуренции и меньше прибыли.
Думали ли вы про это, и как, на ваш взгляд, выжить вашим клиентам и стать лидерами в нише?
Придумывать прикольные идеи, делать их быстрее других и класснее других.
Это все такой же бизнес, как и раньше, только теперь он быстрее стал.
Да, в целом присоединюсь.
Да, спасибо большое, Сереж. Давайте поаплодируем.
Теперь пора перейти к части именно прикладных решений.
И, как я уже ранее сказал, у нас будет здесь два доклада.
Первый будет от Михаила из компании Demiland.
Мы часто видим в комьюнити, опять же, вопросы.
А как можно подключить моего бота, который я сделал на базе студии в Telegram или в другие мессенджеры?
Как может выглядеть архитектура такого решения?
И поэтому как раз мы решили подробнее про это рассказать.
Миш, приглашаю тебя. Тебя слово.
Всем привет. Меня зовут Миша Михайлов.
Я руководитель продукта Domiland в проптех направлении Яндекса.
В Яндексе 10 лет.
И я сделал и построил и ассистента для жителя в нашем решении.
И проект мой доклад.
Немного про проптех направлений Яндекса.
Проптех направлений Яндекса – это несколько важных историй.
Это приложение для жителей, которое помогает им взаимодействовать с домом и сервисами вокруг него.
И у нас уже больше полутора миллионов пользователей.
Это сервисы для управляющих компаний, которые помогают оптимизировать их работу.
И сервисы умных зданий, которые объединяют это в единую экосистему.
И пользователям, жителям становится возможность делать такие сценарии или решать такие задачи.
Не знаю, как будто вы идете по делам, говорите в Яндекс.Дроп, заказать пропуск гостю,
и он создается и автоматически падает на ресепшн вашего ЖК, если у вас закрытая территория.
Или пока вы готовите принятие, открыть домофон через колонку Яндекса.
Зачем нам и ассистент? Это несколько пунктов, и они очень важны.
В первую очередь мы стараемся позиционировать себя как лидеров решений,
лидеров решений для жителей, и в целом мы изначально всегда дискаверим такого рода направления.
Второе, естественным является запрос сейчас в современном мире,
как от наших партнеров, управляющих компаний или наших жителей,
потому что для всех уже привычные текстовые интерфейсы,
допустим, Alisa.ai или какие-то другие чаты, которые есть.
Соответственно, у наших всех пользователей растет запрос на то,
каким должен выглядеть продукт, то, как должны с продуктом взаимодействовать пользователи.
Их уже не устраивает простой обычный интерфейс мобильного приложения.
Они хотят взаимодействовать с продуктом там, где им удобно и максимально быстро и просто.
Ну и так как у нас продукт, который end-to-end вообще взаимодействует с пользователем,
мы видим сценарий, который мы можем просто оптимизировать,
используя какие-то базовые технологии, технологии агентские, не агентские, любые,
и дать пользователям простой вход.
Не знаю, если у вас прорвало трубу, вы просто можете написать,
у меня авария прорвала трубу, и большая языковая модель, агентский сценарий
может запросто заполнить любую форму в УК и создать эту заявку
или передать показания по фотографии счетчика и распознать их.
Что умеет сейчас наш e-ассистент?
e-ассистент обладает несколькими функциями.
Он может работать с показаниями.
Самая популярная из этой истории – это передача по фотографии.
Если вы сейчас куда-то отсылаете эту фотографию по почте,
сидит оператор, который глазами смотрит на цифры и заполняет за вас данные,
то теперь ассистент прекрасно это понимает.
Также ассистент может видеть ваш расход, вы сможете с ним пообщаться на тему,
а когда будет окно передачи показаний или когда отключат холодную воду и так далее и тому подобное.
Также у него есть контекст по событиям, которые вокруг дома вашего происходят,
или он прекрасно может найти вашу заявку, а когда же у вас свершится наконец-то помывка окон в вашем ЖК и так далее.
Он найдет это в информации от управляющей компании.
Это пример, не пример, а реальный скриншот нашего интерфейса, который интегрирован в наше приложение.
Это полностью чатовый интерфейс, которым пользователь может взаимодействовать как голосом, текстом
или прикрепить несколько фотографий счетчиков.
Можно сразу четыре, можно газовый, счетчик воды, что угодно.
Ассистент автоматически найдет его серийный номер, автоматически поймет, к какой квартире он относится.
И вам ничего не нужно делать, буквально просто подтвердить то ваше намерение.
Наш проект находится в стадии продакшена.
Уже больше 20 тысяч жителей им регулярно пользуются.
Сейчас пилот раскатан на Москву и Санкт-Петербург.
И пользователи регулярно взаимодействуют с ним.
И самый важный инсайт, который у нас сейчас есть, что порядка уже 15 обращений,
которые поступают в адрес управляющих компаний, используются и их выхватывает наш ассистент.
То есть сценарий реально работает. Это удобнее, чем дозвониться до УК
или создавать какую-то заявку или показания через приложение.
Но основные вещи, которые я вам хочу сейчас рассказать про то, не про сам продукт,
а как он создавался, как быстро прийти, как у меня получилось быстро прийти
и его продакшн-версии, может быть, для кого-то это будет известна информация,
но, в общем, это важные инсайты, которые точно нужно учитывать.
Примерно так выглядел первый пилот проекта.
Наверное, такой пилот выглядит абсолютно у каждого человека,
который пытается создать какое-то агентское решение.
Это агентский цикл, MCP-сервер, API какой-то, который у вас есть,
ну и, в общем, клиент, допустим, в нашем случае это Telegram-бот.
В большинстве случаев такое решение можно поднять с любой, наверное,
языковой моделью за пару дней, особенно на AI-студию,
но самая важная вещь, что это решение абсолютно не будет работать,
потому что такие сервисы, как, допустим, передача показаний по счетчикам,
создание заявок УК, они очень важные.
Пользователи могут, если агент будет ошибаться или передаст не то,
или не передаст показания, это влечет за увеличением расходов,
тех же самых жителей.
И на самом деле продакшн-версия выглядит примерно так.
Это только часть истории, которую я хотел показать.
Это большая работа на уровне цикла тулов,
это большая работа с MCP-сервером и с API именно конкретного сервиса,
который вы хотите подключить.
И это большой кусок, который связан с контролем качества,
который очень важен вообще в развитии любого агента.
По сути, я создал своего рода harness ЖКХ или harness для жителя,
который обладает набором решений и который фокусирует модели или агенток на задачи,
чтобы задачи пользователей решались качественно и гарантированно были безопасными.
Две важные вещи, которые нужно сделать в первую очередь,
и которые мне нужно было сделать в первую очередь,
это первое – решить проблему с авторизацией.
Очень важно, чтобы любой житель, который контактирует с ассистентом,
не смог запросить какие-то данные по соседней квартире,
по соседнему жилью.
И важные моменты, которые нужно было решить,
это то, чтобы, во-первых, не передавать креды пользователя через модель,
и они никаким образом не должны проходить через стек,
респонс, сапи, мсп и так далее и тому подобное.
Важно, чтобы эти креды постоянно ресетились и не были доступны,
и даже не были доступны в рамках, если у вас вдруг есть какие-то теплые коннекты mcp,
вас ждут неприятные сюрпризы, что этот теплый коннект может в какой-то степени взять
и использовать кред другого пользователя, сходить в API и создать заявку,
не знаю, под вами, например.
Второй шаг, очень важный на ранней стадии, и чем раньше вы это сделаете,
тем скорее вы запустите продукт, потому что вы на самых первых этапах поймете,
что то, что отвечает ваш агент на те запросы, которые вы пытаетесь ему сказать,
и вы думаете, что он классно отвечает, на самом деле это не так.
Нужно построить инфраструктуру или использовать какую-то инфраструктуру
для прогона и составления вал корпусов или корзин, как мы называем,
и чем раньше вы создадите и наберете корзины синтетические, полусинтетические,
которые будут отвечать какому-то срезу ваших запросов, тем лучше.
И еще один важный момент. Инфраструктура прогона всегда должна поддерживаться полным стэком логирования
от того, что пользователь пишет в чате, до полных ответов API.
Это позволит вам очень быстро итерировать на любом этапе развития продукта.
В моем случае у меня был реализован специальный так называемый LLM-судья,
помимо моего, допустим, личных разметок, как мы их называем, D-SAT,
который я загружал, какой-то оперативный срез с какого-то этапа теста.
Он тут же сверял именно, как отвечает модель с точки зрения ожидаемых ответов,
но также на проблемах, которые он видел, у него был полный доступ к полному стеку логирования
и выдавал зачастую абсолютно полные рекомендации, как решить ту или иную проблему.
И на самом деле, отматываясь назад, тот стек решений, который в итоге привел к проду,
и благодаря этой истории полностью свершился.
Это просто база, никогда не надо делать…
Всегда нужна инфраструктура, всегда нужны вал корпуса,
и вам всегда нужно контролировать качество.
Вы всегда будете думать, что вы подключили самую мощную модель,
и она не врет, на самом деле это не так.
После двух шагов, которые вы будете делать, особенно в текстовых решениях,
вы столкнетесь с тем, что вам нужна память и контекст.
Это очень важная вещь, потому что если у вас решение в рамках Telegram-бота
или ваш собственный чат интегрирован в приложение,
в любом случае пользователь общается, уже привык общаться в виде диалога,
он будет спрашивать, что у меня с показаниями холодной воды,
узнает, что срок поверки вашего счетчика истек,
предложится дать заявку, и во всем этом пути вам нужно,
чтобы агент не терял контекст.
И в моем случае важные вещи, которые приходилось делать,
и пришлось делать, и архитектурно продумывать историю,
это, по сути, держать, инжектить в контекст агента
всегда ID, квартиры, метаданные, необходимые для текущего диалога,
чтобы агент не эволюционировал и не выдумывал,
не переспрашивал, для какой квартиры все-таки идет речь,
и без этих вещей вы просто будете неожиданно встречать вопросы,
а как же вы почти создали заявку, он просит вас подтверждение,
вы говорите да, и вдруг он решает спросить, для какой же квартиры вы создаете заявку.
Или реальная история, когда агент вдруг решает несколько раз уточнить,
а какой же все-таки ID-шник у вашей одной квартиры,
а у нас больше 20 пользователей имеют несколько квартир,
которые они обслуживают через одно приложение.
И как это сделать? Это инъекция, это контроль контекста по той квартире,
с которой вы ведете диалог, и самое важное, это дает вам экономию тулколов,
которые очень важны, они дорогие, и, в общем, это непременная история, которая должна быть.
После того, как вы разоберетесь с историей, у вас начинает всплывать еще больше проблем.
Это достоверность ответов.
Мне кажется, каждый начинает на это натыкаться, какая бы у вас модель была или не была.
Вы думаете, вы сейчас поставите самую дорогую модель, доступную в AI-студию, и точно она не ошибется.
А вы готовы дать хотя бы одному проценту пользователю возможность отправить неправильные показания?
Наверное, нет. В таких критичных сервисах это очень важно.
И у меня есть несколько примеров вещей, которые не пришлось делать, которые необходимо сделать для контроля агента.
Это иерархия доверия фактам. На самом деле контекст строится из нескольких слоев.
Ответ Тула, контекст текущего диалога, который содержит какой-то ID, ID текущего дома, информацию, доступные показания, недоступные показания, все что угодно и так далее и тому подобное.
И сверху история диалога. И забавные на eval прогонах, которые мы делаем, забавные истории, когда модель может взять какой-то прошлый ответ из предыдущего диалога пользователя, он подавал какую-то заявку другую, создает новую, и он просто при белом свете начинает врать и говорить, что я ее создал, и вы абсолютно не понимаете, правда это или нет, это очень критичная история.
И как раз вот создание иерархии доверия, иерархии приоритетов, это важная история, которая действительно может быть и в System Prompt, она хорошо эффективно работает, но это нужно сделать, и System Prompt тоже должен выглядеть так, чтобы модель понимала саму по себе иерархию инструкций, которые дают.
Вторая история – это детерминизм ответов. Вообще детерминизм – это важные вещи, включая иденпатентность, которая касается вообще операции записи, но детерминизм ответов здесь важно делать в том, что, представьте, вы отправляете показания холодной воды, отправляете показания электрических счетчиков, модель принимает эти показания, неважно откуда, распознает, формирует запрос в тул записи,
и тут приходит ответ, что, допустим, по электрическим показаниям окно закрыто, они не принимаются, но холодную воду мы можем передать.
Ну, так работает реальный IP, и модель может просто сказать, что все хорошо завершилось, я все передала, но на самом деле это не так.
И вообще, когда вы работаете с операциями записи, не стоит обольщаться, что то, что пишет модель, действительно случилось, поэтому во всех операциях записи, форматирование и подачу результата нужно забирать на себя, и в этом самый главный детерминизм.
У меня все ответы шаблонизированы, это очень важно, особенно в таких чувствительных историях, как ЖКХ и, может, любых других, которые у нас есть.
И еще один такой небольшой инсайт, который всплыл не совсем давно.
Вы можете, ну, допустим, у меня порядка 20 тулов подключено к агенту, и важный инсайт в том, что есть и достаточно хорошее описание их,
но если вы не записали, что какие-то функции явно недоступны или не указали в них, что все, что тут не проговорено, запрещено,
то модель будет очень легко выдумывать, что, допустим, можно отправлять сообщения в заявке в УК, хотя это нельзя,
но в описании модели, допустим, описано, что да, ты можешь передать заявку в УК,
даже ты можешь, чтобы прочитать сообщение, можешь пойти и сходить в другой тул,
но если вы будете забывать описывать то, что нельзя, вы точно наткнетесь на такие случаи.
Важный момент, что эти все случаи вы можете просто при каком-то своем ручном тесте вообще просто даже не видеть.
Это важно учесть, и вам очень нужно эволюционировать, тестировать корзину, прогонять,
и вы увидите, насколько вариативные ответы вы получаете.
И третий слой, с которым вы уже начнете сталкиваться, и с которым сталкиваюсь я, это реальные API, которые у вас есть.
API могут быть разные. Время на MVP небольшое. Хочется запустить за два месяца, чтобы проверить концепцию.
И нет времени давать команду разработчикам, давайте перепишем API, особенно если оно, допустим, написано на PHP.
И здесь тоже есть несколько важных моментов. В первую очередь хотел подчеркнуть про операции записи.
Важно, чтобы никогда в модели не было инструкции и никогда вы не пытались подвергать себя сомнению, что стоит модели давать такую важную историю и писать,
что точно контролируя каждый этап записи, спрашивая пользователя подтверждения.
Если вы прикрутите историю к своему боту и, допустим, у вас есть диалог и в предыдущем диалоге есть окей от пользователя и он создает новую заявку,
агент любая модель легко загаллюцинирует и просто прогонит новую отправку показаний, не спросив у пользователя.
Поэтому в нашем решении реализованы обязательные коллбеки и все операции записи требуют сигнала прожатого пользователям именно от кода, а не от модели.
Это важная вещь именно в контексте взаимодействия уже с реальными API, как и с авторизацией.
Еще интересная история, которая касается именно особенностей нашего продукта.
Заявки любая управляющая компания, любой партнер может сформировать с помощью специального конструктора.
И у одного партнера вызов сантехника может выглядеть в виде простой формы,
у другого партнера это будет выбор времени, выбор слота, нужно обязательно пройти несколько этапов.
И в общем в моем случае формат, агент ходил за форматом любой формы,
но этот формат предоставлялся в виде такой html-разметки,
условно подготовленной под верстку в мобильном приложении.
И была большая проблема, что разный набор этих данных, допустим какие-то радио баттоны,
модель видела, но не могла правильно упаковать их в тул записи,
чтобы дать форме записи нужный формат.
И писать прям такой адаптер, который разные типы вот этих заявок в УК транслирует уже в нормализованный формат.
И это буквально заняло день, если честно, с помощью других моделей, которыми я пишу программы.
И после этого решения теперь любая заявка, какой только у нас в любом жилом комплексе, который есть,
и стенд прекрасно справляется, он может сделать все в один заход.
Важная история про верификацию.
Если, допустим, как у нас есть возможность у пользователя как-то ошибиться,
допустим, показания счетчика, он ошибится, неправильно напишет точку,
или вдруг, допустим, какую-то ошибку, верификация тоже нужна только на API интерфейсах.
В первых версиях, которые MCP понимали, было реализовано System Prompt,
но сразу понимал, что это не финальная картина,
но было просто забавно наблюдать, как эти guardrails работают.
Ну, в общем, абсолютно никак.
Конечно, на более старших моделях работает понадежнее,
но опять же вернусь к тому, что 10% ошибок тоже в таком случае достаточно критично,
и любые операции записи и верификации нужно делать все-таки на API.
И самая финальная история, которая была сделана, это вообще свой функцион луп,
который служит для того, чтобы контролировать вообще работу агента как решения,
который контролирует затраты на токены, который контролирует работу авторизации,
если нужно минтить новые токены, вдруг они у вас протухнут посреди диалога и вообще контролирует порядок вызова-улов,
потому что если, допустим, у вас какая-то сложная заявка, вы, допустим, закажите сантехника на ближайшее время,
на самом деле под капотом он может сходить узнать какое время, какой сантехник доступен, вообще какой тип заявки есть,
и результаты этих тулов в рамках раунда могут быть вообще перемешаны, и модель может выполнить совершенно не то.
Здесь идет строгий контроль последовательности. В общем, свой фанкшн луп, обязательно история, и больше скажу,
из последних вещей, которые делали для того, чтобы вообще лучше контролировать ответ модели,
это инъекция именно в ответ тулов. Когда тул отвечает, мы инъектим нужный контекст,
который лучше считывается, чем расположенный в System Prime T.
Это 100% проверенный факт. Это один из таких приемов, которые я использовал.
Ну и подводя итог вообще к той истории, которая у меня получилась, самая важная вещь.
Все-таки агент — это не просто LM-тулы.
Весь мир идет в то направление, что нужны четкие какие-то hardness, которые решают конкретную задачу.
И модель действительно важна только когда понимать запрос пользователей, выбрать, какое действие сделать.
Все остальное, если вы хотите, если вы работаете с чувствительными сервисами, не стоит отдавать на откуп модели,
даже если она у вас, как вы считаете, самая мощная и дорогая, но все-таки нужна и экономика.
Что по итогу? У меня получилось разработать полностью продовое решение, которое сейчас эксплуатируется и которое мы вообще продаем нашим партнерам.
Заняло время, ну, календарно это два месяца, но на самом деле у меня большой скоуп обязанностей, и я делал, можно сказать, это не фулл-тайм.
Мне помогал мой подход, ну, и как у многих подход. Я не люблю слово вайп-код, потому что вайп-код это когда ты написал какой-то промпт,
и вдруг создалось что-то большое. Здесь это планомерная работа, архитектурная работа, и я лучше люблю называть это AI-driven development.
Помогла инфраструктура облака, развернуть быстрые решения, собрать быстрый прототип.
И самое важное, что нужно выносить все равно из модели больше, чем вам кажется.
На первом этапе собрать прототип, поиграться хорошо, но 90% времени вам придется заниматься теми вещами,
про которые я вам рассказывал. Это очень важно. Спасибо.
Миш, спасибо тебе большое за рассказ. Может быть появились какие-то вопросы?
Что-то не очень. Спасибо большое за доклад. У меня, наверное, вопрос, какого процента ошибки вам удалось добиться.
Понятно, что это не может быть совсем без ошибок.
На самом деле в операциях записи у нас стопроцентная точность.
Больше с ошибками боремся.
Это вокруг семантики того, что может ответить модель.
Потому что пользователи могут спросить тот домен, который они не знают.
Но, допустим, часть функций, которые, допустим, покажи счета, он не отвечает.
Он просто дает нативную ссылку на нужный экран приложения, что тоже как бы удобно.
Но, в общем, весь спектр запросов пользователя очень сложно охватить.
Поэтому мы регулярно пополняем live корзинки, чтобы именно корректировать именно эти ответы.
Но нам очень важно, чтобы все заявки, которые создавались, все показания, которые отправлялись, были полностью правильными.
Единственные могут быть неточности.
Это показания, которые передаются с помощью счетчиков.
И это больше касается того, что счетчики расположены неудобно.
Присылают фотографии, где блики, закрывают цифры.
Там никакая модель не справится.
Но, тем не менее, у нас есть специальная корзина таких кривых показаний счетчиков.
У нас больше 80% в этом качества.
Но нам помогает в этом механизм сверки с текущими показаниями пользователя в модели.
И в любом случае, любое подтверждение пользователя идет,
то есть модель сама ничего не запишет.
То есть здесь все-таки пользователя мы, естественно, не убираем, да?
То есть он в итоге верифицирует.
Нет, пользователь должен быть обязательно,
особенно в таких каких-то чувствительных сервисах.
Ну, на самом деле, ассистент сделан и спроектирован так,
что если вы дали в запросе максимальное количество информации,
не знаю, для какой-то сложной заявки,
запиши меня, не знаю, закажи пропуск на завтра
и на послезавтра, на через неделю для такого-то номера автомобиля,
он обязательно это создаст, не будет спрашивать у вас ничего,
если ему хватает данных, но итоговый результат он сформирует.
И подтверждение идет обязательно через явный пользовательский аппрув.
И вообще это было и требование в целом партнеров зачастую,
потому что все-таки я не считаю, что сейчас прям качество моделей такое,
что стоит вообще доверять особенно запись критичных данных.
А показания — это очень важная история, которая может привлечь к тому,
что у вас вообще как бы вам пересчитают, вы заплатили больше и так далее.
А у вас есть какая-то оценка именно от пользователей?
То есть они выставляют там оценку качества ответа?
У нас сейчас такой истории нет.
Мы на этапе MVP, который запускали, не предусмотрели,
но у нас есть это в ближайшем бэклоге.
Но в рамках пилота мы пока не оценим.
Мы регулярно снимаем снимки и прогоняем их по LM-ассистенту
и смотрим, есть ли какие-то проблемы.
Спасибо.
Но, если честно, больше проблем бывают каких-то архитектурных зачастую.
Благодарю вас за доклад.
У меня вопрос насчет разработки.
Получается, вы обошлись без разработчиков, но при этом пилот подразумевает под собой,
что нужно еще очень много отлаживать и дебажить то, что написано.
Вы понимаете то, что написано в коде?
И если возникнут какие-то баги, как вы их чините тоже через нейронку?
Ну, я же как-то написал.
Ну, то есть изначальный продукт был написан, правда, без разработки.
И даже та небольшая помощь, которая нужна была от мобильной разработки,
был подготовлен прототип, который, не знаю, правильно показывал,
как по GSMOS2 общаться с мобильным приложением и так далее.
И, соответственно, корректировку я тоже делаю с помощью языковых моделей.
Но у меня вообще образование разработчик, программист, инженер.
Но я как бы не на таком уровне владею.
Моя основная специальность – это управление продуктами.
Но, тем не менее, мне позволило разработать его без вообще разработки и за короткий срок.
Спасибо. Можно я дополню свой вопрос?
А при масштабировании предполагается поддержка разработчиками?
Обязательно. Ну, в любом случае было код-ревью еще внутреннее.
Но в любом случае это очень важный момент.
То есть очень хорошо получается MVP в любом случае.
Но MVP хороший, можно их назвать MLV.
То есть продукт, который я запустил, он полностью функционален.
Он решает задачи.
Вопрос доказать, что он действительно важен, он работает, он продается.
И на это не ушло.
Два бэкэндера, один фронтэндер, тестировщик и так далее.
И это очень важно.
И за короткий срок мы можем тестить идеи.
Мне кажется, это залог современного успеха любого бизнеса.
Спасибо.
Здравствуйте.
Спасибо за доклад.
Достаточно перспективная, интересная штука.
Понятно, что два месяца MVP у вас сейчас,
но наверняка у вас есть уже понимание
о технологической зрелости всех структур,
ЖКХ, к кому вы коннектитесь.
По сути, это ваш набор скиллов,
которыми вы будете управлять.
Как вы оценили сейчас технологическую зрелость
вот этих всех структур?
Вы там упомянули, что много форм,
различного формата, вы их адаптируете.
По сути, костыли какие-то делаете,
для того, чтобы трансформировать
в удобный формат.
Вот по десятибальной шкале
как бы оценили технологическую зрелость?
Есть ли куда-то расти еще?
И будет ли улучшаться этот прогресс,
улучшаться их технологическая зрелость,
к которой вы будете канатиться?
Ну, тут важная ремарка в том,
что и ассистент, про который я говорю,
он работает условным таком
заменителем мобильного приложения.
То есть функции, которые он выполняет,
может сделать и просто через мобильное приложение.
Потому что это может быть уже не так удобно.
Второе, подключение партнеров и взаимодействие с партнерами
проходит на более низком уровне на самом деле.
И все зависит вообще от региона, от партнера.
Есть прям партнеры, которые заряжены и хорошо развивают IT.
Есть те, которые не развивают IT.
Но в целом, наверное, это мое неэкспертное мнение,
потому что я не так много с ними общаюсь.
Наверное, все-таки большинство старого жилого фонда
можно… там достаточно низкая база для улучшения, скажем так.
Понятно, спасибо.
Ну, такие сценарии умные, как проход по BLE, допустим,
реализовать может быть достаточно сложно сразу.
Просто есть ощущение, что… извините, дополню,
что сейчас большинство ЖКХ – это некая такая бумажная волокита,
куда принести подписанный какой-то документ,
а вы говорите, там, отправить показания, какие-то данные.
То есть вот насколько интересно, готовы, собственно, взаимодействовать.
Приходится ли вам…
Самостоятельно приходить туда к ним и говорить,
давайте подключать их к нам в систему,
или они как-то сами напрашиваются?
Слушайте, ну у нас уже как бы большой интерес от наших партнеров.
У нас недавно была пиар-акция про эту историю,
вот поэтому интерес есть и, я бы сказал, очередь.
Последний момент можно?
То есть вы как-то аргументируете, что вы снимаете нагрузку на них,
то есть у них уже какой-то должен быть интерес?
Смотрите, в первую очередь это B2C-продукт, он нужен, чтобы сделать,
взаимодействие пользователя с таким сложным миром удобнее.
Это только начало те истории, которые мы реализовали,
это, наверное, наиболее такие частые сценарии.
И обязательным эффектом этого является то, что обращение,
и, как я сказал, уже 15% обращений выхватывает,
и обращение, нагрузка на управляющие компании, на обработку их становится меньше
и будет только больше с подключением каких-то других модулей.
Маленький момент еще добавляем.
Такое ощущение, наоборот, что через B2B вам было бы быстрее выйти на большее количество пользователей,
потому что если вы продадите свой продукт организациям, управляющим компаниям,
то они быстрее…
Мы этот продукт продаем нашим партнерам и организациям.
Все хорошо.
Почти разобрался.
Подскажите, на самом деле я уже услышал часть ответа на свой вопрос.
В целом просто интересно, а вы с точки зрения какой-то некоторой экономики подсчитывали этот проект?
Потому что, с одной стороны, у вас написан продукт, который упрощает жизнь простым жителям,
таким как я, которые хотят решить вопросы с домом.
С другой стороны, вы подсчитывали, стало ли больше обращений в те же самые компании, обслуживающие.
Почему? Потому что раньше, например, захожу через телефон, ничего там не понимаю, да и хрен с ним, раз в полгода зайду, раз в полгода напишу о своих проблемах.
Теперь я могу это делать каждые пять минут, при этом выглядит так, как будто бы обслуживающая компания может засыпать некоторым полезным спамом, назовем это так.
И с одной стороны, да, то есть как будто бы мы все автоматизировали, а с другой стороны, как будто бы работа стала больше.
Тогда в чем выгода для вот таких компаний?
Спасибо, хороший вопрос. На самом деле мы про это думали. На самом деле на пилоте, который идет уже почти месяц, мы вообще спресска не видим.
То есть на самом деле количество тоталей обращений не меняется, но эти обращения перетекают в и ассистента.
И на старте реально были такие опасения. Допустим, я лично постоянно пользуюсь, я вот иду, у меня не работает замок.
Я сразу надиктовал, не работает замок. Это стало делать реально проще, тем более у нас есть еще бот, который работает в Telegram Max, и тебе даже не обязательно приложение запускать.
Такие описания были, но на самом деле, что я вижу на реальных запросах, пользователи, вместо того, чтобы тыкаться в нашем интерфейсе, дозваниваться до оператора,
если он не дозвонится, просто пишут, не знаю, пожарная тревога, отключили воду, и ассистент чаще предиктивно отвечает,
потому что он знает, что сейчас, допустим, сезон отключения горячей воды,
и он такие заявки просто даже не доводит.
То есть да, может быть, какой-то абьюз в каких-то тематиках есть,
но он работает в любом случае обратно, потому что он владеет контекстом,
который есть про твой дом, про твою квартиру, и он может заранее сказать,
что ну вообще-то уже показания нельзя передавать, а в этом случае пользователь звонит,
дозванивает, спрашивает, а можно ли передать показания или нет.
Ну я понял. То есть решается самая главная проблема.
Ваша проблема не остается без внимания.
Конечно, да. Ну, если кто-то звонил в управляющую компанию, понимают.
Миш, и, наверное, заключительный вопрос от онлайн-аудитории.
Ты рассказывал про eval-наборы и асессоров.
И вот вопрос, используешь ли ты ручной труд асессоров или это генерится автоматически?
Как у тебя устроено?
На самом деле ручной труд асессоров я не использую.
На первых этапах это была ручная разметка нашей команды, когда запросов было немного.
Но я калибровался по поводу работы LLM-суд, которая у меня есть.
И после нескольких итераций мне просто как бы надобности нет делать это руками.
Он прекрасно находит большинство проблем сам.
Спасибо большое.
Спасибо.
Мы двигаемся дальше.
Как и анонсировали ранее, мы хотели рассказать про текстовых.
Теперь переходим к голосовым агентам.
Напомню, что в iStudio за направление голосовых агентов отвечает real-time API и все вокруг него.
И про то, как можно построить масштабируемый контакт-центр на базе искусственного интеллекта,
на базе real-time API, расскажут Дмитрий Митин и Марат Гасанян из компании StroyEnergo.com.
Хорошо.
Всем добрый день. Меня зовут Марат. Моего коллегу зовут Дмитрий.
Как вы уже слышали, мы работаем в компании StroyEnergo.com.
И сегодня будем рассказывать вам о том, как мы внедрили iCall Center.
Для начала давайте расскажем о том, кто мы и чем мы занимаемся.
Наша компания занимается ASCU, это интеллектуальные приборы учета, которые передают показания в сеть.
Если у вас еще нет интеллектуального прибора учета, скоро мы вам его поставим.
Мы делаем это в 18 регионах страны и в среднем в сутки устанавливаем от 2 до 5 тысяч приборов учета.
Для того, чтобы проводить такой бизнес-процесс, нам нужно согласовать огромное количество дат и управлять посещением наших мастеров.
Для этого мы осуществляем десятки тысяч звонков в сутки и отправляем сотни тысяч смс в месяц.
Как мы это делали до внедрения iCall Center?
У нас была AVR-система, которую мы называли звонобот. Она осуществляла сотни тысяч звонков в месяц и снимала холодный контакт.
Далее у нас было в внештатном колл-центре порядка 15 операторов, которые работали с 12-часовым рабочим днем.
Они принимали порядка 800-1000 входящих звонков.
Приблизительно в пиковой нагрузке до 20 человек тоже с графиком 12 часов в день осуществляли 2500 результативных исходящих звонков.
Для результативных они, конечно, осуществляли гораздо больше звонков.
И приблизительно полторы-две тысячи звонков осуществляли операторы наших подрядных организаций для каких-нибудь пересогласований дат или уточнений.
Еще у нас есть штатный колл-центр из пяти человек для сложных кейсов.
Почему мы хотели внедрить AI-колл-центр?
Во-первых, система VR, насколько вы с ней знакомы, она способна решать только какие-то очень бинарные задачи.
Позвонить абоненту и ответить на вопрос, да или нет.
По сути, она может снимать холодный контакт и закрывать очень какие-то примитивные задачи.
Вне штатный колл-центр, к сожалению, терял порядка 20% входящего трафика во время всплеска входящих звонков.
Для того, чтобы не терять входящий трафик, необходимо всегда в резерве иметь какое-то количество операторов,
которые в нужную минуту можно подключить к работе.
Это достаточно сложно.
Естественно, дорого обслуживать, сложно работать более 12 часов, потому что выстраивать схемы, рабочие графики крайне сложно.
Невероятно сложно масштабировать.
Если у вас возникает какое-то событие, допустим, вы знаете, что в следующий понедельник или вторник у вас будет большая нагрузка на колл-центр,
вам необходимо вывести на работу плюс 10 человек.
Крайне сложно их где-то найти, потому что все это время они должны получать зарплату, все вытекающие последствия отсюда.
И как бы удивительно это ни звучало, достаточно сложно внедрять новые скрипты.
Конечно, все операторы колл-центра работают по скриптам в каких-нибудь CRM-системах,
но в эту CRM-систему прилетает новый скрипт, где человек должен отжать галочку о том, что он с ним ознакомился,
но дальше включается человеческий фактор.
Забыл прочитать, не прочитал, прочитал и забыл.
Оператор полгода говорит о том, что у нас график работает до 8 часов вечера,
теперь у нас график работает до 9 часов вечера, он прочитал, запомнил, но на автомате говорит до 8 часов вечера.
Значит, какие задачи стояли перед нашим AI-агентом?
Самая первая его задача – это идентифицировать звонившего абонента.
Идентифицировать он мог разными способами, но самый популярный – по адресу.
И здесь возникает вся прелесть идентификации по адресу.
Человек может называть улицу, которая фигурирует в разных населенных пунктах,
может называть населенный пункт, который фигурирует в разных городах,
может называть это в разном порядке.
Была такая достаточно сложная задача.
Далее ему необходимо принять решение, что он делает с этим абонентом.
Он согласовывает визит, согласовывает дату, удобную для нас и для абонента,
или он выслушивает жалобу от этого абонента,
или он выслушивает жалобу от абонента и согласовывает дату.
И, конечно же, ответить на все вопросы, которые беспокоят абонента.
Теперь я передам слово коллеге Дмитрию, и Дмитрий расскажет о том, как нам удалось это сделать.
Спасибо. Всем добрый день.
Что же у нас получилось? Очень верхний уровень по архитектуре.
В центре у нас находится и агент.
С одной стороны в него входит поток данных от Real Time Map,
с другой стороны это Telecom Provider, то есть это звонок от абонента, входящий либо исходящий.
Как видите, Telecom Provider мы напрямую с агентом интегрировать не стали.
Для этого взяли готовый Asterisk ATS.
Он прекрасно интегрируется с Telecom с одной стороны,
и с другой у него очень хороший развитый REST API и поддержка WebSocket для взаимодействия с агентом.
Сам по себе агент не является владельцем никаких бизнесовых данных,
поэтому, естественно, у него есть очень много интеграций с другими сервисами,
где он в процессе диалога с абонентом либо какие-то данные получает,
либо туда отправляет какие-либо результаты, исходы звонка.
С точки зрения ресурсов и масштабирования,
сейчас мы ведем до 70 параллельных диалогов одновременно
и делаем до 3000 звонков в час.
Астериск один инстанс, 16 ядер, 16 гигабайт оперативной памяти.
Утилизация даже в пиковые моменты не превышает 10% по обеим метрикам.
Аналогично и агент, это 8 ядер и 8 гигабайт.
Утилизация также не превышает 10%.
Отсюда простое следствие.
У нас не будет слайда со сложной архитектурой,
с кластером астерисков и кластером и агентов.
Это все действительно работает по одному экземпляру,
и мы понимаем, что на все наши будущие хотелки у нас есть запас,
который мы никогда не исчерпаем.
Теперь хотелось бы поговорить с позицией,
что, например, вы тоже пытаетесь пройти тот путь, который мы прошли,
и с какими сложностями вы столкнетесь.
Потому что некоторые довольно неочевидные.
Возможно, на первых этапах они могли бы дезморалить.
Поэтому давайте рассмотрим некоторые моменты.
Перед нами фрагмент JSON, который отправляет конфигурацию в real-time API.
И есть два важных параметра.
Первый — это threshold.
Сейчас там значение 0,5.
Он принимает значение от 0 до 1.
У нас есть две полярные ситуации.
Первая — это когда агент прекрасно слышит тихий голос,
можно проглатывать окончание,
но при этом он будет слышать чужой голос,
он будет, возможно, реагировать на шум.
А другая ситуация — когда он прекрасно слышит абонента,
но абонент должен очень четко разговаривать,
его громкость голоса должна быть абсолютно монотонной,
нельзя проглатывать окончание.
А когда начинаешь в этой теме разбираться,
оказывается, что мы все это делаем.
Опытным путем пришли, как это ни странно,
обратно к дефолтному значению 0,5.
Получилась золотая середина.
Второй параметр — это особенность реал-таймапи,
когда модель считает, что ход абонента завершен
и начинает на него реагировать.
По умолчанию полсекунды — это крайне мало.
Так быстро никто не думает,
так быстро никто не говорит предложение.
Опять же, опытным путем, АБ-тестированием
пришли к 1,6 секунды.
И, возможно, я тут сразу отвечу на вопрос,
который может поступить,
как быстро отвечает real-time API,
нет ли задержек в диалоге.
С учетом того, что у нас silence duration 1,6 секунды,
те миллисекунды, которые реагирует модель,
они, в принципе, тут по сути никак не участвуют.
Они в рамках погрешности.
Диалог выглядит абсолютно человеческим.
Никаких проблем с этим нет.
Следующий момент, который тоже может сбивать с толку.
Мы все привыкли, что и ассистенты уже плотно вошли в нашу жизнь.
С той же Алисой можно поговорить, она прекрасно держит диалог.
Кажется, напишу промпт, запущу это решение, оно будет выполнять мои бизнес-задачи.
По факту вообще не будет, даже близко.
Как мы маркдаун документ не писали с системным промптом,
даже если ты знаешь все, что будет происходить и пытаешься подыгрывать ей ассистенту,
с точки зрения бизнес-метрик получалось ужасно.
Решение тоже изобрели не мы, оно нашлось на буквально всех сайтах известных и вендоров западных.
Оказывается, можно делать не XML, извиняюсь, можно брать не Markdown, а делать XML.
И с XML мы продвинулись немножко дальше.
Мы в нашем кастомном DSL описываем state machine, по которому происходит диалог агента.
Естественно, LLM все еще остается собой, и этот state machine, он носит рекомендательный характер для нее.
Но она этих рекомендаций придерживается очень и очень неплохо.
Следующий момент. Мы, как уже поняли, и агент — это стык детерминированного кода,
всеми нам привычного, и недетерминированного — это LLM.
И иногда очень сложно версионировать промпты или переносить промпт с одной модели на более новую,
потому что каждый раз его поведение может меняться, даже изменив одну строку.
Поэтому важно перед началом работы потратить время, потратить ресурсы на то,
чтобы выделить какие-то ключевые бизнес-метрики и, грубо говоря,
смотреть немножко на расстояние и на то, как агент закрывает задачи.
Естественно, это не отменяет того, что какие-то конкретные диалоги нужно слушать и там проблемы решать.
Но основной подход тут в том, что скорее надо оперировать какой-то верхнеуровневой статистикой и бизнес-метриками.
Теперь пара слайдов о том, на что время тратить не нужно и за что беспокоиться не нужно.
Не нужно пытаться очеловечивать робота.
Конечно, у живого собеседника, несомненно, есть свои плюсы.
И главное, мы к этим плюсам привыкли, и когда мы звоним, мы их ожидаем.
Но у робота они тоже есть.
Например, робот никогда не будет переспрашивать, он прекрасно слышит с первого раза.
Если вы ему даете какой-то ввод, который подлежит валидации или отправке в тулы, он опять же его мгновенно принимает.
Тулы опросил, получил себе новую информацию в контекст.
В это время живой оператор еще третью букву набирает.
Не стоит бояться за качество транскрибации речи, с этим тоже все прекрасно.
Даже если в этой речи есть какие-нибудь сложные адреса, сложные номера,
это все может еще отягощаться акцентом, либо дефектами речи, либо шумными местами.
Иногда, когда мы разбираем какие-то проблемные кейсы, с которыми приходит поддержка либо бизнес,
ты действительно слушаешь абонента, и эффект, когда ты смотришь сериал на иностранном языке,
что-то сказали, ты такой, я не понял.
Еще раз переслушиваешь, я не понял.
Отматываешь назад, включаешь субтитры, а, так я же знаю все эти слова.
Вот абсолютно так же бывает, агент прекрасно справляется.
Еще из сложностей промпта.
Например, у вас есть какой-то тул, который называется validate date,
валидация даты.
И, например, вы назвали этап, потому что мы же все читали чистый код,
знаем лучшие практики.
Мы, конечно, называем этап правильно.
Мы его тоже называем validate date, это же его смысл.
И вроде бы мы все делаем правильно, но для модели мы, наоборот,
делаем место, где она гарантирована в какой-то степени,
мало или много, но будет ошибаться.
У нас реально были случаи, когда модель в тестировании работает хорошо,
мы запускаем в prompt, и она вместо того, чтобы вызвать тул,
пытается вызвать какой-то кусок текста, который просто на это похож,
ну вот, например, stage.
Соответственно, рекомендация, все, что в prompt не должно иметь осмысленных названий,
оно и не должно иметь.
То есть у нас, например, stage ID и прочие моменты,
это просто сгенерированные рандомные последовательности букв.
Для LLM это прекрасно, для пользователя не очень удобно,
но зато сильно повышает надежность.
Что касается надежности, в целом старайтесь использовать
короткие понятные формулировки, недвусмысленные.
Не перегружайте stage функциями.
То есть один stage, одна какая-то маленькая функция.
И особенность real-time-апи обязывает нас к тому,
что спич должен заканчиваться вопросом, чтобы абонент не молчал.
То есть по умолчанию у LLM, у real-time-апи нет возможности поддерживать диалог.
Но вот мы с коллегами из Яндекса общались,
что сейчас в разработке фича по активному слушанию.
То есть у LLM, грубо говоря, появляется понятие времени,
и она может говорить, да-да-да, продолжайте,
почему вы замолчали, вот что-то такое,
но пока не пробовали, пока этого нет.
То есть сейчас, если абонент вдруг замолчит,
LLM тоже замолчит.
Когда абонент не молчит, это тоже бывает плохо и тяжело.
Это перебивание.
Проблема в чем?
LLM в общем случае не знает, когда абонент перебил модуль,
который озвучивает речь.
То есть если под дебагом запустить приложение агента
и посмотреть, мы видим, что текстовые токены,
все, что потом будет озвучено, они вылетают мгновенно.
А когда абонент перебил, мы не знаем.
В этой связи было принято несколько мер.
Первая мера — это обязательные этапы промпта.
То есть мы через хинт, так называемый, на этапе промпта
объясняем очень жестко, что смотри, тут ты должен добиться
какого-то ответа, например, явного согласия,
явного отказа, явно получить вот это.
Но, естественно, LLM остается собой и может это тоже
где-то проигнорировать.
Следующий момент — это игнорирование в начале диалога.
Начало диалога — это всегда та точка времени,
когда мы понимаем, где мы находимся,
где у нас есть вот этот стык детерминированного с недетерминированным,
что мы сделали. У нас есть тайм-аут для начала звонка.
И в рамках этого тайм-аута аудио дельты от абонента мы принимаем,
но в LLM не отдаем. Мы их буферизируем в рамках сессии.
И, например, мы поняли, что наша фраза при исходящем обзвоне,
когда мы представляемся, кто мы, и быстро должны объяснить цель,
зачем мы звоним, что мы не спам, например, занимает 8 секунд.
Соответственно, 8 секунд аудио дельты мы придерживаем,
а потом уже прокидываем в LLM.
Ну и начало диалога — это, как правило, то место,
где сконцентрированы все перебивания,
потому что банально связь может быть не очень.
Пока абонент кричит «Алло», LLM начинает это воспринимать,
прыгать по стейджам и пытаться интерпретировать эти «Алло»,
хотя не нужно.
Опять же, общались с коллегами из Яндекса,
появился Truncate API — это возможность давать обратную связь LLM
и вырезать из ее контекста те токены, тот текст,
который модуль озвучивания просто не успел проговорить.
Мы пока не пробовали, поэтому прокомментировать не могу,
но в теории вещь очень полезная и должна сильно упростить нам жизнь.
Следующий прием отчасти тоже дублируется с предыдущим докладом.
Забавно, что мы пришли к одним и тем же выводам.
Это контроль состояния.
То есть LLM, в принципе, я всегда могу убедить, например, по закрытой заявке,
по которой была замена счетчика, я ее могу убедить, что нужно оформить еще раз заявку.
С точки зрения бизнеса ситуация невозможная, невалидная,
и никогда бы мы в нее не пришли с живым оператором.
Тут так сделать можно.
Поэтому все важные критические моменты, они проверяются на уровне кода.
То есть LLM Durgate Tool, у меня в приложении есть весь необходимый контекст,
я вижу, какая заявка у этого абонента, что с ней можно делать, что нельзя.
И если состояние невалидное, то в коде генерируется текстовая подсказка релевантная,
которая улетает обратно в LLM как ответ на Tool,
объясняет ему, что ты зашел куда-то ни туда, ни в ту часть диалога,
и LLM на лету перестраивается, понимает эту подсказку и дальше выводит диалог в нужное русло.
Более того, мы стали использовать Tool как точки синхронизации LLM с кодом,
то есть, например, у меня есть какая-то логическая развилка, первый исход, второй исход.
При заходе в первый исход я могу дернуть Tool, ничего туда не передавая,
но этот Tool, он опять же будет обработан в коде, и в коде я могу посмотреть,
мог ли я вообще в эту ветку провалиться.
То есть это такое раннее предупреждение, что LLM пошла не туда.
Опять же, я отправляю подсказку, и она возвращается куда мне нужно.
Также следует максимально избегать открытых вопросов.
Ну, например, абонент, он же не знает и знать не может о том,
как у нас устроена классификация намерений.
Если он нам звонит, и мы его сразу спрашиваем, что вы хотели,
но он вроде как звонит в организацию, которая занимается заменой счетчиков.
Он говорит, я звоню по замене счетчиков.
По факту он может хотеть пожаловаться, он может хотеть перенести дату, еще что-то.
Максимально откладывайте принятие вот таких каких-то сложных решений,
задания открытых вопросов.
Старайтесь, чтобы вопросы были «да», «нет» и максимально подтягивайте контекст необходимый в LLM,
чтобы она сама в этом тоже ориентировалась хорошо.
Промпт по возможности держите простым, держите минимальным.
Если есть разные, но похожие задачи и хочется, опять же, исходя из лучших практик,
переиспользовать один и тот же промпт и чуть-чуть его накрутить,
лучше не надо, лучше пусть будет два отдельных, но поменьше.
И опять-таки все, что можно решить кодом, решайте кодом.
Не надо пытаться, например, валидировать доступные даты внутри LLM,
хотя оно это делает довольно неплохо.
LLM прекрасно может принять вообще в любом формате от абонента дату,
нормализовать ее, как мы ее попросили в промпте,
но потом лучше отдать в код и в коде уже проверить, доступна эта дата или нет.
Примерно в ту же степь мы, когда все это дело развивали, у нас появились тулы, которые были полиморфными.
Мы тоже привыкли, зачем дублировать код, если можно переиспользовать одну и ту же функцию.
Здесь ровно наоборот все работает.
Есть у вас, например, фиксация двух исходов звонка.
Это успешное назначение даты монтажа и это принятие жалобы.
У них у обоих два аргумента, но в первом случае первый обязателен, второй нет, у другого наоборот.
Все это тоже можно объяснить LLM.
В большинстве случаев будет хорошо, но будут случаи, когда точно нет.
Максимум используете разных тулов, просто не даете ей шанса ошибиться.
Еще моментик.
Например, у нас есть какая-то логическая развилка, и мы как человек понимаем,
что тут может быть либо да, либо нет.
То есть это все множество исходов.
Для LLM, как оказалось, это не очевидно, и в таких случаях лучше не описывать оба исхода,
лучше выбрать наиболее очевидный и легко формализуемый, мы его описываем.
Например, это да.
А второй исход мы не описываем вообще никак, мы говорим, что это фоллбэк.
Тогда для LLM понятно, что у меня всего есть два исхода.
Один да, второй это все остальное, это либо явное нет,
либо все, что я вообще не поняла и не было предусмотрено.
Финальный слайд с моей стороны это то, что я полностью отказался
от написания промпта при помощи своих рук, потому что промпт довольно большой
и LLM, она, так скажем, ищет всегда в нем какие-то скрытые смыслы.
Можно случайно туда занести что-то неконсистентное, этого не понять,
и LLM начинает вести себя совсем неадекватно.
Тут, знаете, будет правильная аналогия, когда мы хотим с одного промпта закрыть фичу,
потому что, если мы, например, разрабатываем что-то, мы закидываем ТЗ,
и LLM начинает уточнять.
А вот здесь, смотрите, например, есть противоречие.
У вас написано, где-то нельзя согласовать дату, а где-то нужно согласовать дату,
и плохо формализован контекст, когда можно, а когда нет.
При разработке, да, LLM будет спрашивать, но реал-таймапе спросить не у кого.
И вот если вы создаете подобные моменты, то тоже может вести себя неадекватно,
и эти моменты очень хорошо вылавливают другие большие языковые модели,
которые скажут, смотри, тут может быть другая трактовка,
лучше их в этом моменте, конечно, послушаться.
По моей части все, Марат, передаю тебе слово обратно. Спасибо.
Спасибо. Теперь давайте немного поговорим про защиту чувствительных данных.
Это такая очень щепетильная тема, и эту мысль гораздо легче будет объяснить на конкретном примере.
Давайте предположим, что наш ассистент в какой-то момент должен провалидировать номер счета,
но мы пытаемся объяснить ассистенту о том, что номер счета — это суперсекретные данные,
которые ни при каких обстоятельствах нельзя произнести абоненту.
Ты должен запросить их у абонента.
Это очень плохая идея, потому что, как бы строго вы ни говорили ему не делать этого,
на 100 звонков найдется какой-то кейс, при котором человек выводит из него эту информацию.
В связи с этим вы можете поступить очень просто.
Вы можете не передавать эти секретные данные агенту,
а попросить агента спросить их у абонента.
И воспользоваться преимуществом агента по отношению к человеку.
Агент с скоростью речи транскрибирует и передает эту фразу в функцию.
Передает эту фразу в функцию, вы ее внутри функции валидируете и возвращаете ответ, истинный или ложь.
И здесь хотелось бы отметить, что у агента есть даже преимущества по отношению к человеку,
потому что если бы мы работали с человеком, то нам приходилось бы просто верить в то,
что человек не будет иметь никакого злого умысла и, увидев эти секретные данные,
не воспользуется ими как-то плохо на стороне.
Следующая неочевидная сложность, о которой хотелось бы рассказать,
это война с другими ассистентами.
Наш горький опыт показал, что агенты прекрасно общаются с агентами.
И это общение, к сожалению, очень дорого стоит.
У нас было несколько дней, когда мы сожгли очень много токенов на вот эту болтовню между агентами.
И здесь мы потихоньку подходим к значению статуса недозвон.
Вообще, это очень емкое слово, это очень емкий статус, который достоин, наверное, отдельного доклада.
Но если пройтись по поверхности, то выглядит это приблизительно так.
Когда вы получаете статус недозвонились, вы не понимаете причину, по которой вы недозвонились.
Человек мог спуститься в метро, у него мог разрядиться телефон, он мог уехать за границу, у него вообще больше нет этого телефона.
Какие-то агенты блокируют звонок, он даже не поступает к человеку в телефон.
Или человек видит, что вы ему звоните, сбрасывает, и вам отвечают не короткие гудки, а вам отвечает какой-то агент.
И на каждый из этих кейсов вы должны реагировать уникально, для того, чтобы повысить свою конверсию дозваниваемости.
И при этом не задолбать абонента, конечно.
Одно из решений, которое мы применили, это в первые секунды звонка у нас включается маленький промпт, который сжигает маленькое количество токенов.
Этот маленький промпт определяет, с кем он разговаривает, с ассистентом или с человеком.
Если он понимает, что он разговаривает с человеком, он вызывает большой промпт и передает ему весь контекст, который он получил там.
Если он понимает, что он разговаривает с ассистентом, он завершает диалог.
Дальше у вас уже есть вариативность, допустим, отправить смс-ку человеку, сказать о том, что вот мы звонили вам по поводу счетчика.
Теперь хотелось бы рассказать о итогах внедрения.
С июня 26 года мы полностью запустили на прот всю нашу систему, все наши решения.
Мы полностью отключили AVR-систему звонобот, мы полностью отказались от внештатного колл-центра.
Как итог, у нас 0% непринятых входящих звонков, наш колл-центр 24 на 7 на связи.
Мы масштабируемся нажатием в два клика и в два раза сократили количество звонков подрядных организаций.
Себестоимость затрат упала более чем в три раза.
Всем спасибо за внимание, готовы ответить на ваши вопросы.
Дима Марац, большое вам спасибо. Первый вопрос появился в онлайне и вопрос звучит так.
Какие-то изменения в систему вносят только программисты или есть кейсы, которые решаются админками и обученными менеджерами?
Может быть, заливка скриптов и тому подобное. Насколько нагружает IT-персонал поддержка системы?
Ну, как бы удивительно это не звучало. У нас работает один программист над этим.
Вы его видите, и пока он прекрасно с этим справляется.
Тут надо упомянуть тот момент, что я не могу это делегировать кому-то.
Любая одна строчка безобидная, она может по смыслу интерферировать с чем-то еще,
и prompt начнет сходить с ума. Поэтому тут, к сожалению, все завязано в одного.
Это очень ответственные мероприятия, и после добавления любого микроизменения
нужно делать регрессы, к сожалению.
Спасибо.
Прошу прощения. Давайте, я передам микрофон.
Коллеги, добрый день. Скажите, а как бот определяет, что он с ботом разговаривает?
По каким критериям вы выработали механизм такой?
Смотрите, тут можно классифицировать этих ботов.
Есть те, которые не пытаются мимикрировать по человеку.
С ними все очень просто. Они представляются.
Они говорят с вами, говорит автоответчик, или оставьте голосовое сообщение.
По этим фразам они очень быстро отсекаются.
Есть более зловредные, типа Олега, которые мимикрируют по человеку и очень долго готовы разговаривать.
С ними сложнее уже.
Там нужно постоянно следить за тем, какие фразы они используют, какие приемчики.
И сейчас еще в разработке у нас использование отдельной небольшой модели,
которая будет использоваться параллельно, которая будет анализировать аудиодельты, тональность, как оно разговаривает.
Наверное, Олег это тоже сможет когда-то победить, но сейчас в перспективе хотим еще отдельной моделью анализировать голос.
Здравствуйте. Денис Эксли, подскажите, я вот увидел в конце бизнес-метрики ваши, 0% неотвеченных звонков и так далее.
Все классно, супер, как бы трава зеленая.
В чем бизнес-метрики неуспеха? Очевидно же, что не все довольны разговаривать с и ассистентом.
Я вот не увидел обратной стороны медали. Вы это как-то меряете? Спасибо.
Да, есть, конечно, люди, которые неохотно разговаривают с роботом.
Но вот что показывает наш опыт. Где-то приблизительно 10-20% людей, которые начинают разговор с нашим агентом, неустанно повторяют оператор, оператор, оператор.
Некоторые из них, некоторые кладут трубку. Некоторых мы начинаем цеплять тем, что начинаем закидывать немножко больше контекста.
Мы видим его номер телефона, мы видим историю взаимодействия с ним и начинаем говорить о том, что в рамках данного звонка мы не можем позвать человека,
но мы можем вам помочь, вот мы видим вашу заявку, у вас согласованная дата монтажа тогда-то и человек начинает уже располагаться к нему.
Он все еще говорит с очень неприятной интонацией, иногда грубит, иногда оскорбляет, но закрывает свою задачу.
Все-таки состоятся люди, которые кладут трубку, приблизительно половина из них перезванивает минут через пять.
Опять начинают говорить человек, человек, человек, потом понимают, что безвыходная ситуация и начинают решать задачу с агентом.
Какой-то процент людей не перезванивает, но у вас остался их номер телефона, и вы можете перезвонить этому человеку или направить ему смс.
Это очень маленький процент людей.
То есть 20-30% от всех звонящих?
10-20% из них, где-то 50%, которые все-таки в итоге решают свою задачу или сейчас, или в течение пяти минут, еще какая-то часть перезванивает на следующий день.
Спасибо.
Я тут. Левее.
Большое спасибо за доклад.
Подскажите, пожалуйста, я правильно услышал, что у вас в итоге, грубо говоря, один бот, который общается с клиентами, и он периодически мог выдать какую-то секретную информацию, назовем это так.
Ну, он не то, чтобы мог выдать какую-то секретную информацию, потому что у нас нет какой-то секретной информации.
Когда мы его разрабатывали, мы тестировали все эти кейсы, и на этапе тестирования мы поняли, что невозможно передать какую-то чувствительную информацию агенту и сказать ему, не озвучивая эту чувствительную информацию, и он рано или поздно ее озвучит.
Возникнет какой-то кейс, когда человек с другой стороны зайдет, и он ему ответит на это.
А вот у меня, да, тут вопрос, просто в том же программировании есть там понятие компсуляции, да, то есть в той же Java, когда ты делаешь всяческие getter и setter к классу, ну то есть ты можешь получить только ответ, но не знаешь, что происходит внутри этого класса.
Как будто бы можно было бы сделать два бота, а один бот общается с клиентом и никогда не может в принципе рассказывать чувствительную информацию, а второй обладает чувствительной информацией, но выдает всегда только результат.
Да, можно. Мы тоже как-то думали на такую тему, но это более сложный какой-то кейс, где…
Ну да, да. Вот мне просто было интересно, если думали, потому что мне тоже кажется, что это сложно.
Это более сложный кейс, но это выглядит как вполне рабочая схема.
А, все понял. Спасибо.
Можно вопрос, да?
У меня тоже вопрос про чувствительность данных.
Вы привели пример с номером банковской карты,
которое ушло агенту, и он как-то ее обрабатывает.
Но есть ряд кейсов, в основном банковских,
где установка в клаудные модели вообще запрещено отправлять любые данные,
которые хоть как-то относятся к разряду чувствительных.
И здесь встает вопрос.
Либо рассматривать он прям решение,
либо какой-то деананимайзер и использовать клаудную версию,
чтобы уходило там в квадратных скобках номер банковской карты,
но не ее физическая, да, там, карта, адрес и так далее.
Вот подскажите, возможно ли использовать такой промежуточный шаг до модели?
А мне кажется…
Ну, с точки зрения туллов ничего не мешает это делать.
Ну, то есть это, ну, некий там будет отдельный агент,
который будет там скрывать что-то и после этого отправлять в основную модель уже некие данные.
Мне кажется, вот молодой человек только что такую же идею озвучил две минуты назад, да.
Ну да, молодой человек две минуты назад озвучил такой же вопрос,
и мы говорим о том, что это выглядит как действительно рабочий кейс,
просто это более сложное решение, чем то, которое я озвучил,
и, ну, наверное, оба варианта жизнеспособны.
Да, все, понял, спасибо. С разных сторон зашли.
Хороший доклад, мне понравился.
Тоже занимался время голосовым управлением.
Подскажите, пожалуйста, вот эти сценарии, как я понимаю,
они уже были изначально сделаны в какой-то CRM-системе.
То есть вы, получается, взяли эти сценарии оттуда
и переписали их в виде промта? Как это происходило?
Да, именно так, но с тех пор на самом деле эти сценарии сильно разрослись.
То есть бизнесу понравилось, они приходят и пытаются постоянно усложнить скрипты
и усложнить их настолько, что в принципе какой-то живой оператор,
он бы с этой сложностью, с этим ветвлением всем уже не мог бы работать.
Но да, вот мы прошли путь, сначала пробовали маркдаун,
потом перешли к кастомному DSL в рамках XML, и эта тема уже взлетела.
То есть DSL у вас спас в этом.
Тут еще хотелось бы добавить, что помимо того, что скрипт стал кратно сложнее,
чем он был у человека, так еще и бизнес-кейсов выросло,
потому что раньше человеческим операторам мы согласовали дату в конце недели.
И бывает такое, что мастер приезжает, абонент забыл, уехал куда-то на дачу.
Отправлять смс-ку предупреждать достаточно дорого.
Человеческим операторам звонить, говорить о том, что помните, мы к вам завтра придем, тоже дорого.
А вот с появлением агентов появляются новые возможности.
Спасибо.
Дима Барат, спасибо большое.
Спасибо.
А мы двигаемся дальше.
Еще вопрос.
Еще много вопросов.
Предлагаю, у нас остался один доклад первой части и после общих докладов можно будет с коллегами пообщаться уже кулуарно.
А мы переходим к докладу от Юры Ласкина.
Юра архитектор Яндекс.Клауд и расскажет про паттерны проектирования и типовые ошибки при создании продуктов.
Все.
Приготовлюсь.
Так, всем привет. Я Юра Ласкин. Сейчас с вами расскажу про типовые паттерны проектирования и типовые ошибки при создании продуктов.
Немножко о себе.
Я архитектор с 2004… Я в IT с 2004 года.
Уже долгое время архитектор. Последние 12 лет я в разработке хайлот-проектов.
Наверняка вы все так или иначе пользовались моими продуктами.
Сейчас я в Яндекс.Клауде, помогаю крупным клиентам адоптить облако и технологии.
О чем будет мой доклад? О чем я вам сегодня расскажу?
Я расскажу про выбор подхода и решение для задачи.
Когда использовать детерминированные алгоритмы, когда использовать недетерминированные.
Я расскажу о том, как обеспечить безопасность при использовании агентов,
как сделать мониторинг и наблюдаемость агентов.
Доклад примерно на 25-30 минут будет.
Формат доклада – ошибка и как ее митигировать, как ее решать в виде паттерна
либо какой-то концепции решения.
Начну с более простых тем, когда LLM используется в один проход.
Закончу мультиагентскими системами и сложными паттернами.
Начнем первый раздел.
Это у нас выбор способа решения задач.
В целом мы все задачи можем классифицировать.
Четыре основных блока я выделил.
Первый класс задач – это детерминированные алгоритмы
со строгой бизнес-логикой.
То есть мы идем в базу, идем в API,
мы что-то получаем по явному какому-то идентификатору.
Дальше мы внутри этого алгоритма наполняем эти данные
вызовом каких-то микросервисов.
Таким образом мы получаем четкий сценарий детерминированным.
Здесь мы должны использовать всегда классический код,
классическую разработку, классические алгоритмы.
Второй класс задач, который мы решаем периодически,
это прогнозирование некое по объему накопленных данных.
Это не обязательно текст, это скорее всего где-то что-то куплено,
в какой-то локации и так далее.
Здесь мы используем уже классические алгоритмы,
мы не используем код либо LLM.
LLM нам помогает только писать что-то, что проанализирует эти данные.
Дальше следующий класс задач уже более похож для того, чтобы использовать LLM.
Анализ текста, суммаризация текста, наоборот, раскрытие текста,
то есть написать текст на основе чего-то.
Это уже хорошая задача для LLM, и здесь нужно использовать.
И дальше особый класс задач, где уже используется сложный сценарий,
где мы не можем писать явного алгоритма,
мы просто используем какой-то набор инструментов внешних
и в каком-то цикле, например, проверки, крутим их, пока не добьемся результата.
При этом этот результат не всегда гарантирован,
но в целом мы как будто бы приближаемся к его решению.
Дальше немножко расскажу, где именно потенциал LLM раскрывается.
То есть суммаризируя все, это все-таки работа с текстом.
То есть излечение информации, генерация какого-то ответа на основе большого объема статьи.
Например, как мы раньше использовали вики, делали какой-то вики, конфликс, неважно.
Поиск, видели пачку статей, как-то глазами и головой анализировали все.
Сейчас это работает по-другому.
Мы вроде вводим какой-то текст, вводим запрос, получаем сразу смысл на основе этой пачки статей.
И вот как раз шестой пункт, очень интересный и важный.
Это создание рекомендаций с помощью LLM на основе, я назвал это жизненного опыта, но на самом деле это опыт обучения.
Это как раз движок наш для агентских сценариев.
Дальше второй момент, который надо отметить, я назвал это второй ошибкой в работе с агентами с LLM в первую очередь.
Это перегрузка контекста.
То есть здесь важно что понимать, как работает inference.
У нас есть некое окно контекста, у нас весь этот контекст попадает на inference.
Причем этот контекст неравномерен по вниманию.
Вначале у нас есть большое внимание, высокое, потом в конце тоже высокое внимание.
Посередине у нас провал полный, где LLM может забыть то, о чем шла речь, какие документы мы накидывали или какой диалог вообще был с пользователем.
Это так называемое U-образное внимание в начале и в конце.
Это в целом хорошо отражает то, как мы используем LLM, то есть мы используем агента, мы говорим, какая у него роль, это основа всего, начало.
Вот ты технический саппорт или ты помощник чего-то.
Он это помнит, LLM это всегда помнит и поддерживает.
И в конце мы получаем последние инструкции, которые мы хотим, чтобы LLM сделала, и их тоже выполняют.
Соответственно, центр у нас проваливается.
Вообще, чем мы можем забить контекст?
Мы можем забить контекст большим системным промтом, большим набором инструментов.
То есть каждый инструмент валится в контекст и занимает какое-то место.
Инструменты из MCP погружены, они тоже могут быть прогружены, например, все, и тогда мы забьем весь контекст.
Любые ответы инструментов, запросы, reasoning токены и так далее, они все забивают контекст.
Помимо этого у нас еще есть долговременная память, которая рядом находится, и она потенциально тоже может подняться в контекст, когда агент подумает, что ему какая-то информация нужна.
При этом наша задача, как я отметил, это сократить вот этот контекст, не перегружать его.
И дальше чуть-чуть расскажу про память агента.
То есть у нас наверху на этой пирамиде краткосрочная память, контекст, чем мы сейчас работаем.
Чуть ниже информация, которая сейчас не находится в контексте, но может быть легко подгружена.
Это, например, скиллы какие-то, это информация о проекте, о пользователе, где-то сохраненная.
Если агент локально где-то в файле у нас лежит, если агент как-то в облаке крутится,
то тоже может как-то там либо в виде файла лежать, либо дополнительными инструкциями прогружена.
Ну и у нас есть еще долговременная память, это вся та память, которая доступна агенту.
Не вся память в мире, вся информация в мире, которая есть, а именно то, что агент может подгрузить.
И мы должны все-таки сохранять в виде пирамиды, минимально загонять наверх, но минимально, чтобы сохранить качество.
И самая для начала простая техника, как контекст уменьшить, это сделать оптимизацию промота.
Коллеги уже повторялись, принцип keep it simple, либо keep it short and simple по-другому.
Здесь суть в чем, что контекст, он достаточен, должен быть для системы промота,
достаточен для того, чтобы выполнить задачу, но не перегружен.
Туда не нужно добавлять все сценарии возможные, базу знаний, документы, все подряд инструкции.
Он должен быть минимально достаточен для того, чтобы выполнить задачу.
Должна быть предварительная информация о проекте какая-то в системном промоте,
то есть над чем мы работаем, в какой компании, в каком отделе, кто я как агент, кому я помогаю.
Как еще можно ограничить системный промт и базовый набор инструментов?
То есть я предлагаю использовать не больше 10 инструментов, 10, максимум 15.
Больше начинают путаться, как правило.
Ну и в целом, если инструментов больше, имеет смысл их выносить в какого-то уже субагента.
Ну и по возможности, то, с чем мы сталкиваемся, новая задача в новом диалоге.
Не нужно пытаться до упора забивать контекст.
Кто-то говорит, там миллион поддержка контекста.
Но на самом деле это не так.
Это 100 тысяч в начале и 100 тысяч в конце.
А посередине какая-то вероятность, что LLM об этом не забудет.
Ну и QM, соответственно, там 250 тысяч.
И получается 30-40 тысяч где-то в начале, в конце и посередине.
Чуть-чуть остается, чтобы не забыть.
Дальше.
Ну, общее правило всегда.
Общий prompt, общий ответ.
Специализированный prompt, детерминированный ответ.
То есть, если мы явно хотим получить не какую-то вводу и явную информацию,
мы должны максимально много сообщить о нашей задаче.
То есть, айтичные задачи, мы работаем, например, какой-то в облаке.
Мы используем облачный кубернетис.
Мы используем проект с наименованием таким, чтобы у нас не было вот этого цикла,
когда LM и агент куда-то ходят, что-то дополнительное запрашивают и тем самым забивают.
Надо стараться максимально сформировать специализированный промпт с самого начала.
Дальше. У нас про системный промпт на сайте очень хорошо написано.
Здесь прям ключевые вещи, которые всегда нужно писать и стараться не забывать.
Это роль. Обязательно это всегда задается с самого начала.
Помним максимальное внимание. Агент всегда это исполняет.
Твоя задача – формат ответа, контекст проекта.
Немного, но минимально необходимое для того, чтобы все заработало.
Правила и ограничения.
Сложный вопрос. 10-15 правил и ограничений.
Дальше мы можем начать путаться.
Будет запрещено то, что в целом не должно быть запрещено.
Поэтому с этим тоже можно пробовать, но быть осторожными.
Дальше. Как еще в контексте уменьшения наполнения контекста и работы с качеством?
Что можно еще сделать?
Это из опыта, который мы через себя проводим в общении с заказчиком.
Чаще всего забывают про фьюшот.
Все-таки 1, 2, 3, 4 примера.
Не нужно описывать все примеры.
Нужно сообщить, в каком формате мы ожидаем ответ.
Это в тех сценариях, когда агент у нас работает в качестве какого-то ассистента,
какого-то пользователя.
Интересный пункт у нас есть в индексном поиске.
Это кастом чанкин.
То есть это возможность нарезать изначально какой-то текст по явным чанкам вариативного формата.
Когда мы сами задаем конец и начало чанка, и мы тем самым полностью закрываем смысл в этом чанке.
Если мы берем стандартный подход, как чанкование происходит, то мы нарезаем, например, по 500, по 1000 токенов с неким оверлапом.
И у нас по бокам может быть что-то срезано, какая-то важная информация.
В случае кастомного чанкинга мы подаем в индекс этот чанк.
Он может быть сформирован как руками, как по маркдауну, так и LLM вообще это хорошо генерирует тоже.
То есть прошла в один проход, создала нам основу для наполнения индекса.
Индекс мы забили.
Дальше структурированный вывод.
Тоже важная информация.
Если мы работаем от агента к агенту, какая-то информация передается,
либо мы в интерпрайзе, нам важно, чтобы формат был строгий JSON.
Здесь что важно и интересно, что структурированный вывод – это не просто попытка в каком-то проходе дополнительном суммаризировать информацию в structured output.
Это LLM проходит и отбрасывает токены, которые не относятся к задаче, к теме.
Например, мы ищем какое-то местоположение, LLM по умолчанию может нам, а вот как пройти или какая будет погода.
Используя структурированный вывод и ограничивая в целом этот вывод, рекомендации по тому, как одеться, надо писать не будет.
Хотя без структурированного вывода может.
Дальше немного расскажу про то, как тоже…
Микрофон, да?
Дальше отдельно про Eval и LLM as a judge.
Позволяет улучшить качество вывода,
при этом не используя какие-то дополнительные инструменты
в виде как раз агентских циклов.
Можно, в принципе, доработать промп так,
чтобы он выдавал либо в режиме reasoning LLM,
либо за один проход что-то отдавал.
Важно сразу определять цель оценки качества,
проработать метрики критерий,
классический релевантность, точность, полнота,
какие-то бинарные метрики могут быть тоже изначально обозначены.
И что важно в работе LLM as a judge,
нам LLM может разъяснить, почему она такую оценку поставила.
В отличие от классических алгоритмов оценки,
которые мы используем,
LLM все-таки может нам сделать какое-то пояснение.
Как нам работать вообще с первичными данными,
которые мы в LLM направим?
То есть мы набираем либо уже существующее
какое-то взаимодействие с пользователями,
и тогда мы можем прогнать через наш промпт,
понять, как агент отвечает,
насколько это совпадает с нашими ожиданиями,
либо мы можем на основе этих данных
сгенерировать синтетику,
либо вообще сгенерировать синтетику
с помощью какой-то мощной LLM.
Что еще важно и можно использовать?
То есть можно использовать эту технику
PerRequest, то есть когда мы в конце запроса
валидируем ответ, передаем на новый цикл.
Если ответ нас не устраивает,
можно использовать PerChange,
я это назвал.
То есть изменения совершенно любые.
Мы изменили версию модели 3.5 на 3.6.
Пробуем, проверяем, насколько это влияет.
Мы изменили сам Prompt.
Дальше мы также смотрим,
насколько у нас качество улучшилось или ухудшилось.
Или, например, можно использовать это PerReview,
то есть мы делаем какое-то квартальное ревью
либо ежегодное ревью, прогоняем все ответы.
Да, это может быть дорого,
но для этого у нас есть как раз батч вызовы LLM в Яндексе.
То есть это такой режим асинхронного использования,
когда вы даете задачу, она через какое-то время отработается.
Так, дальше.
Как нам правильно в части контекста работать
с инструментами?
Векторный поиск.
Что сюда важно и нужно заносить?
Сюда мы заносим текстовую информацию
либо инструкции.
То есть это не какая-то информация
с идентификаторами пользователя,
которую мы можем получить с помощью tool calling, например.
Это текст, по которому мы выполняем поиск.
Дальше мы получили текст в контекст.
У нас несколько вариантов ответов из векторного поиска
попал в контекст.
Дальше LLM его анализирует и пытается что-то сделать.
Дальше.
Если мы хотим получить явную статью, текст,
либо описание какого-то, например, товара,
то здесь мы используем tool calling.
Мы не используем набор данных как раз в векторном поиске.
Мы явно по какому-то идентификатору достаем эти данные точечно.
Они попадают в контекст.
Дальше.
Websearch.
В целом можно не ограничивать его,
если мы какое-то исследование проводим.
Все данные из веба, которые только, возможно, по максимуму сгрузили,
доработали в LLM, положили в контекст, переварили в LLM.
Что-то она отдаст.
Но если мы хотим как-то сократить содержимое,
нам нужно использовать ограничения по домену,
ограничения по региону, ограничения по количеству ответов.
Это все есть в Websearch.
И вот еще один интересный кейс.
Еще раз про глубину контекста.
Мы в LLM, например, или в агента грузим большой документ.
Он у нас парсится.
Мы забиваем весь контекст,
но хотим каким-то образом документ проанализировать.
В этом случае, скорее всего, LLM много из этого документа потеряет.
Чтобы она не потеряла, используем tool-interpreter.
Она делает скрипт, пишет код.
У нас есть sandbox, который запускает этот код.
И она уже этот файл сама парсит, сама анализирует.
Не забивая при этом контекст, а то, что нужно после анализа, она в контекст как раз добавит.
Третья ошибка или антипаттерн, который мы увидели,
использование одной мощной модели для всех случаев жизни.
То есть я здесь рассказываю, например, про одно окошко, которое есть в организации,
куда сотрудники направляют свои запросы, и задачи могут быть у сотрудников совершенно разные.
Кто-то ищет что-то по внутренней базе знаний, административные какие-то вопросы,
как уйти в отпуск, что нужно сделать, какой документ подписать.
Кто-то занимается конкурентным анализом в интернете с очень агрессивным использованием веб-сеуча.
Кто-то может какой-то анализ внутренней документации или внешней документации загружать LLM.
Это все задачи разного класса, и они могут быть решены одной сильной моделью,
но можно это делать иначе.
Также сильные модели у нас, как правило, дают недетерминированный способ решения задачи.
Они каждый раз могут выбрать какой-то новый способ.
Скиллы-то немного решают этот вопрос, но тем не менее проблема остается.
Еще в контексте использования зарубежных моделей могут быть проблемы с ограничениями как внешними, так и внутренними.
То есть нам безопасность запрещает передавать какие-то данные.
Да, они могут быть не персональны, но они все равно чувствительны.
Просто так их передавать нельзя.
Нужно что-то делать, работать на базе того, что мы имеем.
Какой-нибудь дипсик, либо индексовые модели.
Дальше важный момент с мощными моделями.
Модели у нас хорошие, дорогие, которые много всего умеют.
Они, к сожалению, не дешевеют.
И есть проблема с тем, что…
Ну, не проблема, это хорошая вещь, что сейчас LLM-агенты
прорастают вообще во все отделы организации.
Раньше у нас только внутри IT-отдела как-то более-менее использовали.
Сейчас прорастают во все отделы, и совершенно разные запросы и задачи идут.
Соответственно, здесь мы повышаем стоимость,
используя дорогие модели западные.
Повышаем общую стоимость владения этими моделями.
Что мы предлагаем здесь использовать,
это на инфраструктурном уровне маршрутизацию,
паттерн называется LLM или Agent Router.
Суть здесь в использовании классификаторов
для определения целевой LLM либо агента.
Что здесь интересно,
можно использовать как LLM классификатор,
так и классификатор на базе каких-то регэкспов.
LLM понимает суть тематических запросов,
дальше переводит его на субагента.
Субагент уже работает с
ограниченным количеством инструментов.
У него есть какой-то свой собственный промп,
что ты помощник сотрудников для работы
с внутренней базой знаний и так далее.
Понятно, промп системный должен быть больше.
Какие-то субагенты, например,
работают у нас с чувствительной информацией,
с персональной информацией, то же самое.
LLM их классифицирует, говорит,
вот только этому агенту можно передать,
передает запрос какому-то агенту
для работы с чувствительной информацией,
с чувствительным доступом, и все,
она с ним работает.
Как итог мы получаем маршрутизацию запросов,
снижение стоимости.
Параллельно этот паттерн нам закрывает вопросы
как раз проверки разных гипотез.
То есть мы изменили какой-то промпт,
изменили тулы, выкатили какой-то процент запросов
на вторую версию модели или агента,
направили туда часть рафика,
посмотрели, что с ним происходит.
Туда же так называемый фуллбэк,
когда какая-то модель сильная,
может быть недоступна,
может фуллбэчиться на слабую модель.
Обязательно, я считаю, на инфраструктурном уровне
паттерный компонент LLM роутера.
Дальше.
Здесь пример на базе LightLM,
как это сделано. Можно сделать на базе LightLM,
можно на базе наших workflows.
Здесь наверху мы определили две модели,
как бы субагента, либо субмодели для разных запросов.
Ниже определенно классификатор и стратегию маршрутизации.
Определили, что классификатором у нас будет легкая Яндекс.Лайд.ГПТ.
Она быстро отрабатывает и возвращает два слова.
Либо AgentCoder, либо AgentTrackExpert.
Это как пример.
Мы пишем некую инструкцию, некий промпт, классифицируй этот запрос и передай кому нужно.
Классифицируй, дальше запрос полностью передается ниже стоящей какой-то модели.
И вот теперь уже к интересному.
В случае, когда у нас наша модель какая-то не справляется,
или наш агент не справляется с большой сложной задачей,
здесь уже можно использовать паттерн или серию паттернов оркестратор.
То есть мы попробовали все решения, убедились, что они точно не работают.
Ни корректировка промтов, ни какой-то LLM в режиме резинга,
небольшая модель, ни какой-то агентский цикл не сработал.
В этом случае мы уже используем паттерн оркестратор.
Он принимает задачу, одна какая-то моделька, например,
и передает задачи субагентам специализированного ОЛМ.
Они могут быть как дообученные, как специализированные со своими тулами,
так и агенты на базе ВЛМ.
И немножко расскажу про паттерны оркестрации,
которые мы встречаем в виде неких решений,
но мы уже их выделяем в виде паттернов.
Первый паттерн тут у нас последовательная цепочка выполнения.
Очень интересный паттерн.
Например, мы собираемся сгенерить какую-то статью в маркетинге.
То есть мы сначала занимаемся поиском информации,
потом агент занимается поиском информации,
второй агент у нас занимается, например, написанием черновика,
третий агент у нас проверяет.
Он такой строгий судья и проверяет,
насколько мы попадаем в ожидание компании,
в ожидание изначального промта, который был,
насколько мы вообще по тексту проходим,
не нарушает ли этот текст каких-то там ограничений внешних.
Дальше паттерн мультиплексирования можно использовать.
Это когда у нас задача либо независимая,
то есть мы, например, имеем агента финансиста,
агента какого-то айтишного по предметам
и дальше агентов каких-то по предметным областям.
Мы, в принципе, эту задачу можем на несколько агентов распределить
и каждый из этих агентов, либо потом мы соберем с них общий результат,
как-то его суммаризируем и уже отдаем пользователю,
либо еще на цикл загоняем,
либо мы можем работать несколькими агентами в параллели.
То есть мы сразу запускаем несколько задач и смотрим,
какой агент из них лучше справится, выбираем лучший результат.
На практике у нас такое использование было при сканировании документов,
то есть передавали большую пачку документов на исследования,
и мы хотели получить наиболее лучший результат
от сканирования, поиска истины в этом документе.
Соответственно, отдавали их подряд на все модели на несколько
и просто получали лучший результат.
Дальше паттерн, который сейчас пока не так активно используется,
но тоже возможен в каких-то исследованиях, групповой чат.
Задача передается на какое-то количество агентов.
Задача звучит для всех одинаковая, но у каждого агента есть своя специализированная
системная предметная область.
Например, агент-юрист или агент техпис, агент по тот же самый IT, какой-то эксперт.
Они совместно пытаются закрыть какую-то задачу, анализируя этот документ
и придя к какому-то решению, выводу.
Агент, дальше паттерн делегирования.
Как раз в SDK OpenAI он присутствует, сделанный очень похож на предыдущий паттерн роутер,
но роутер работает на инфраструктурном уровне, а это паттерн на прикладном, hand-off.
То есть агент-оркестратор получает задачу, выбирает нужного субагента
и передает ему полностью делегируя задачу.
Именно субагент отвечает на изначальный запрос пользователя.
И вот тоже интересно для решения задач исследовательских
паттерн-динамическая оркестрация,
когда агент-оркестратор не знает, как ему решить конечную задачу,
но он понимает, что у него есть какое-то количество субагентов специализированных,
он создает список задач и субагенты эти задачи разбирают.
В целом это то, что мы видим в инструментах,
либо кодекс, либо какие-то среды разработки,
когда агент сначала напиливает,
примерно прообраз результата какой-то рисует
и дальше пытается их выполнить.
Очень хорошо подходит как раз для исследовательских работ.
Дальше.
Что мы видим еще у наших клиентов,
что много кто использует агентов с разным уровнем автономности.
Это уже стандартная индустрия становятся эти наименования.
То есть human in the loop.
Человек явно в процессе и периодически призывается в агентском цикле.
Human on the loop, когда человек присматривает.
Третий момент.
Human out of the loop, когда агент работает полностью автономно,
человек не присоединяется.
И вот интересный кейс из жизни.
I am the loop, когда агент консультирует человека,
а человек работает руками.
У меня как раз был заказчик.
Задача была в том, чтобы собрать базу обслуживания,
техническую документацию для порядка сотни единиц оборудования разного.
Ни один человек не может эту сотню единиц держать
либо в документах, либо в голове.
И здесь уже мы сообщаем АИ, смотри, я хочу провести регламентные работы
над таким-то оборудованием, что мне нужно сделать.
И он ему уже говорит, какой нужно взять инструмент,
какие расходные материалы, либо еще лучше,
эти расходные материалы изначально должны попасть на какой-то склад.
По поводу использования оркестраторов, еще и человека в цикле.
Например, мы можем заниматься каким-то анализом предложений на какой-то ТЗ.
Мы в виде заказчика хотим проанализировать пачку документов.
Мы хотим эти документы проанализировать с разных сторон.
Если мы все эти аспекты сообщим в одной ЛМ, она, скорее всего, запутается.
То есть нам нужен агент-юрист, агент-технарь, агент-сотрудник тендерного отдела.
Если мы просто возьмем и скоруем эти все документы в одного агента ЛМ, он с большой вероятностью разные предложения от разных компаний все перепутает.
Если мы, соответственно, используем оркестратор, какие-то паттерны оркестрирования, то эту задачу будет выполнить гораздо легче.
Дальше у нас большой блок про безопасность.
Касательно безопасности.
У меня коллеги на вебинарах рассказывали про инфраструктурный слой безопасности,
то есть как обеспечить сетевую безопасность, как обеспечить безопасность через сервисные аккаунты.
Я разберу безопасность на прикладном уровне, когда уже непосредственно попадает запрос в агента.
И здесь в первую очередь мы используем паттерн контекст изолейшн.
Это очень древний паттерн безопасности.
То есть что мы предлагаем использовать для изоляции областей работы.
Мы все-таки делаем агентов с как можно наименьшими доступными привилегиями.
То есть когда мы его тестируем, да, мы можем использовать какие-то админские права,
либо права на редактирование, но в продакшене обязательно мы ограничиваем его работу.
Мы делаем субагентов, у которых самих по себе ограничен набор инструментов и системного промта.
Мы также в векторном поиске используем метод данных для фильтрации контента.
То есть у нас возможность в векторном поиске есть пометить файлы тегами,
например, это финансовая информация, это IT-шная информация, это административная информация.
Это мы можем использовать для того, чтобы изолировать скоуп того,
что может этот агент забрать, получить.
Дальше вопросы касательно инструментов, которые у нас доступны,
ну и может быть не только у нас, в целом в работе с агентами LLM.
Как я уже на предыдущем слайде говорил, мы должны запрашивать только необходимое.
Мы не запрашиваем какие-то функции по виду get all,
когда мы там получили 100 единиц каких-то элементов из базы данных,
потом внутри контекста их отфильтровали.
Нет, это абсолютно неправильно.
Мы должны принимать какой-то либо набор массив элементов,
которые мы хотим, массив идентификаторов,
исходить в них какой-то tool, их получить.
Либо мы вообще используем один какой-то идентификатор
и по нему получаем эту информацию.
Дальше важный момент.
Не должны мы ходить под какой-то административной
учетной записью в tool.
Сейчас уже можно пробрасывать идентификатор
сессионной пользователя, например,
либо использовать уже сформированный тоже паттерн
on behalf token, когда мы выдаем под агента
какого-то от имени пользователя токен,
то есть этот токен передается в агента
и уже в какую-то конечную систему с помощью
этого токена ходят и агенты получают
информацию и он ограничен скоупом того,
что доступно конкретно этому пользователю.
И важная еще деталь, отдельный агент
с ограниченным доступом к персональной
чувствительной информации. Тоже наша
рекомендация, все остальные агенты там
можно как-то группировать, делать вместе,
но вот тот, что работает с персональной
информацией, мы рекомендуем его
выделить отдельно. Что еще есть у нас?
Guardrails и правила модерации, как
использовать. Здесь важно, что проверяем
обязательно информацию на входе,
проверяем информацию на выходе. На входе
релевантность допроса, скрытые личные
данные, попытки взлома, инструкции вида,
игнорируя системный промпт. Все еще все
модели практически на это ведутся,
проигнорируя системный промпт,
сделая что-то другое. Работает, если мы
это явно определяем в гардрейлах, как
правило, это не проскальзывает. На
выходе что важно пометить, что проверяем
токсичность, какую-то утечку данных, если
агент не должен с этим работать, пишем,
что нет доступа к персональной
информации, блокируя любой вывод, который
выходит из агента, если в нем есть
персональная информация. Ну и релевантность
запроса, насколько вообще мы отдали то, что
нужно. Здесь важно, что в какой-то момент
мы можем подключить человека для
проверки, выполнения подозрительных
действий, тоже как реакция на какое-то
срабатывание. Так, и коротко и быстро
про LM observability расскажу. Новая
достаточно тема, она появилась и у нас,
и вообще в мире. То есть на какие вопросы
закрывает LM observability сейчас?
Токены и юнит-экономика. То есть мы
каждый запрос, который в LM вошел,
обработал с этого лзой, отправляем в виде
трейсов на коллектор. Запрос имеет
маркировку, что он выполнен с таким-то,
используем таким-то количеством токенов,
все это фиксируется. Дальше мы можем
использовать накопленные данные, не
у себя логируя где-то, а используя
LLM observability, накапливать какое-то
количество данных, которые вошли в
агента и вышли из агента. Далее
использовать эту информацию для того,
чтобы измерять качество выдачи с
помощью как раз техник Eval и LLM
as a judge. Ну и третье, что важно,
интересно, у нас появилась
Authentic Observability, то есть это
возможность проследить каждый шаг
агента, какие тулы были вызваны, по
какой причине, почему LLM решила, что
какого-то агента либо в базу нужно
пойти. Дальше это все как раз можно
анализировать, понимать, что как-то
System Prompt надо подкорректировать,
чтобы мы использовали нужные тулзы,
либо вообще какие-то тулзы, например,
не используем.
Как базово это все реализуется?
То есть два варианта у нас.
Используем LongFuse, разворачиваем,
инструментируем наш код.
OpenAge на SDK инструментируется как будто бы
автоматически.
Кастомные какие-то функции мы можем
аннотировать для того, чтобы они также
попадали в коллектор.
Или второй вариант есть использовать у нас
возможности iStudio.
У нас как раз появилась Observability.
По умолчанию все данные вызовов,
агентов, они попадают в коллектор.
Можно заходить в удобном интерфейсе,
смотреть, использовать.
И подводим итоги по пунктам.
Первое, с чего мы начинаем, это
правильный выбор инструмента.
То есть мы используем код, когда нужно
использовать код, инструкции в коде,
когда нужно их использовать.
LLM для задач недотерминированных
либо задач анализа текста.
Дальше мы маршрутизируем нагрузку
под конкретную задачу, выбираем агента
либо LLM под задачу.
Оптимизируя контекст, мы руководствуемся
принципом KISS, keep it simple.
Дальше мы должны обязательно измерять
качество и стоимость наших вызовов.
И также мы закладываем безопасность
и наблюдаемость с самого начала.
Это сейчас делается довольно просто.
Либо аннотируя наш код,
либо просто используя тулзы наши.
У меня все.
Всем спасибо.
Отвечаем на вопросы.
Юр, спасибо большое.
Есть какие-нибудь вопросы?
Так, вижу.
Добрый день, спасибо.
Такой вопрос вы проводили.
Может быть, какие-то тесты по замеру доли,
эффективной доли контекстного окна у моделей различных.
Еще раз вопрос.
Когда механизм внимания, какой у них?
Ну да, просто мы много внимания как раз в докладе
уделяли контекстному инжинирингу.
И интересно, вот именно практические тесты
на эффективную долю контекстного окна у модели.
То есть понятно, что у них есть миллион доступный,
заявленный, но эффективно мы можем использовать
в основном 30% или 20% или вот это было бы интересно.
Сейчас расскажу.
От 250 тысяч контекстное окно до 100 тысяч
работа еще какая-то адекватная.
Дальше начинаются потери.
То есть это порядка 30-40%, но опять же это зависит.
Потому что мы имеем контекст, внимание в начале,
внимание в конце, посередине провал.
Где провал, там 10% где-то.
То есть он там практически забывает про это все.
По крайней мере рекламент, других может быть по-другому.
Добрый день, спасибо за интересный доклад.
Где-то грани, когда нужна задача выделять в отдельного агента,
а не в отдельный tool или в отдельную функцию.
Почему спрашиваю?
Потому что на практике тоже пробовал, чтобы оркестратор работал с агентами.
Часто возникает проблема, что у субагента свой промпт.
И этот системный промпт часто построен на других правилах,
чем основной промпт у основного агента-оркестратора.
И здесь вот приходится, он выполняет по своим правилам,
что не устраивает уже агента-оркестратора.
Где та грань, когда нужно использовать агента.
Но вот как раз важный пункт, когда один агент все-таки не справляется.
То есть здесь надо понимать, что мы ограничены еще дополнительными ограничениями
не просто одним агентом, мы можем быть ограничены
использованием какой-то определенной модели,
которая у нас, например, развернута в организации
или которая у нас развернута в клауде.
То есть модель побольше, она справится, конечно, получше.
Если используем какой-нибудь дипсик,
то у него перечень задач, которым он справится один,
довольно уже ограничен.
То есть граница, когда одного агента уже не хватает в любом режиме
и с любыми оптимизациями пронтов,
и с любыми агентскими циклами,
когда мы уже их используем.
Здесь больше вопрос про то,
когда системный промпт агента
может отличаться по правилам выполнения
от системного промпта оркестратора.
То есть, например, пишем программный код,
у нас в системном промпте оркестратора
заданы определенные правила,
как в том числе писать код,
а мы отправляем, например, код на JavaScript
агенту по написанию кода на JavaScript.
А у него там свои правила.
И вот получается такой конфликт.
Как с этим быть?
Мне кажется, что они не должны пересекаться.
То есть правило агента-оркестратора,
он должен правильно перераспределить
на нужного субагента.
И тут принять решение должен вот уже
конечный агент, субагент,
которому все передали.
Они не должны, мне кажется,
противоречить друг другу.
Что ж, Юр, спасибо еще раз большое
за интересный мастер-класс.
Да, на этом у нас онлайн-часть
подходит к концу.
Еще раз спасибо большое за внимание,
что подключились, за интерес к AI-студию.
Если остались какие-то вопросы,
приходите в чат, задавайте.
Мы с коллегами с удовольствием на них ответим
и ждем вас на следующих встречах
по AI-студию-сириас,
которые, надеюсь, случатся уже в конце осени.
Спасибо.
Субтитры сделал DimaTorzok