Transcription
Всем привет. Это второе видео про prod продакш разработку и агентов. С момента выхода первого видео и агенты у нас уже вышли на новый уровень. Они фактически существуют автономно, да? У них есть своя соцсеть, и они взаимодействуют там без участия человека. Контроль над ними - это лишь иллюзия.
Ну, вопрос риторический, но, конечно, уже каждый понимает и призадумался о важности грамотно уметь создавать, запускать, эксплуатировать и агентов, чтобы они решали всё-таки задачи наши и нашего бизнеса. А продаж разработка - это не про завайпкодил и всё готово, а это про системный подход к непрерывному улучшению. Это и отличает prodдакш систему от там некого прототипа. Она должна работать не только в идеальных условиях, а в любых реальных условиях. И сделать это можно только за счёт контроля над ситуацией.
В первой части, в первом видео мы с вами начали проектировать и агента для нашего агентства lmst.ru. Наше агентство занимается разработкой и решений, конечно же, грамотной разработкой Prodдаction Ready решений, но также консультируют и обучают специалистов и компании, а как перестраивать свой процесс работы на AI Driven, EIF подход, а особенно всё, что касается жизненного цикла разработки программного обеспечения и, конечно же, тому как создавать продакш, а, и агентов, агентские системы, которые будут решать задачи бизнеса.
Ну, про программы обучения подробно на этот год мы поговорим в конце видео. А в этом видео мы поговорим с вами про подводную часть агентской системы, про безопасность, про контроль качества, про мониторинг, про работу с данными, датасетами, про сбор обратной связи от пользователя, про инструментарий, про MCP-сервера, про продвинутые техники построения рак системы, про векторные базы данных. В общем, всё то, что лежит действительно под водой, не видно конечным пользователям, но составляет львиную долю работы или, как по принципу паретов, составляет 80% реальной а работы.
Ну и начнём мы с безопасности. Ну и начнём мы с безопасности, а так называемый гарс или первая линия защиты, цель которых защитить нашу систему от вредоносных атак. Довольно много существует и способов атаки, способов защиты. Ну, наиболее типовые - это ограничивать аа количество вызовов моделей, вызовов инструменты, чтобы нашу систему не задосили там из ней или она сама себя как бы не ввела там в какие-то бесконечные циклы размышлений или там избыточного вызова инструментов.
А отдельно блок важный связанный с защитой персональных данных. А чтобы персональные данные не передавались, соответственно, там вне системы и внутри даже системы, там туда, куда их нельзя передавать, они не утекли. А используются способы там и маскирования, и замены подстановки, там, деперсонализации этих данных. Ну и, конечно же, блок, связанный с фильтрацией контента, а, на токсичность, запрещённые темы, промнъекции, ну, и так далее.
Ну вот ещё один из способов защиты, да, контроль затрат, а там по пользователю, по стоимости, по токенам, а по количествам запросов в минуту, по количестве условных единиц, да, там в час, в день. А-а, соответственно, тоже полезно и нужно делать и контролировать.
Важно в целом рассматривать такую технику, как Human Enelope, и понимать, для каких операций вашей системе необходимо её встраивать, да? Что это за техника? Ну, по сути, человек в цикле, да, а когда система запрашивает подтверждение на выполнение того или иного инструмента той или иной операции, создать там заявку, аа, назначить, запланировать встречу на определённое время, обратиться к вашей файловой системе, создать там запись в вашем календаре. А, соответственно, надо определить для себя, какие операции требуют финального прова человека и использовать её. Ну вот, например, а для финансовых операций, изменения критичных данных, отправ аа ненужные там, скорее всего, для поиска информации, ответы на вопросы, чтение истории. Соответственно, общее правило хитл нужно использовать, если операция необратима там или имеет высокие последствия.
Отдельный блок важный, да, по работу с инструментами, которым обогащён, скажем так, вооружён наш агент, это MCP протокол, который стандартизирует, э, по сути инструментарий предоставлением агентов. Это протокол, который компания Антропив выпустила уже там более года. назад. А единый стандарт подключения инструментов, на самом деле, он предоставляет удобный доступ не только к инструментам, но и ресурсом и промтам. Аа смысл этого заключается в том, чтобы это всё можно было удобно переиспользовать множеством агентов, которые там, скажем, в одном домене или в одной корпорации применяются, ну или в целом там эти MCP протоколы выпускаются публично и, в общем-то, могут применяться там разными а-а разными разработчиками других агентов и систем.
Ну, в нашем проекте мы будем использовать MCP сервер для и обернём наши инструменты поиска истории взаимодействия с клиентом, создание заявок, консультацию, назначение встречи с клиентами в MTP-сервер. Преимущества, какие мы от этого получим? Ну, во-первых, сервер подключил, агент к нему обратился, забрал доступный ему перечень инструментов, и мне нужно вручную как бы интегрировать каждый инструмент и там повторно реализовывать его код. Соответственно, решается задача переиспользования. Изоляция. Агент ничего не знает о реализации каждого инструмента, да, там в коде непосредственно нашего агента нет этой реализации. Он вынесен в одно место. аа в реализацию инструментов в MCP-сервере. А безопасность тоже есть плюсы. Централизовать контроль доступа в одном месте. Ну и, соответственно, все выход, все вызовы проводятся через MCP, легко там тресить и логировать.
Дальше один из инструментов у нас Retrif или там Rock Search, поиск информации по, соответственно, нашей базе знаний, там, нашему портфолио. Проблема рак в продакшене, ну, зачастую типовые, они следующие. BlackБоx. Откуда эта информация? Из каких документов она была получена? Сложность отлаживать, да? Почему именно этот документ? Какой был скор в припоиске? А что же в итоге попало в контекст? Аа бороться с галлюцинациями зачастую сложно. Модель придумала ответ или он из документа получен? А какой чанк был использован? В общем, всё это невозможно улучшать без нормальной прозрачной там прозрачности.
Ну, помимо там а логирования истории, связанной с трейсингом, о котором говорим позже, а сейчас хотелось бы акцентировать внимание, что хороший подход - это в целом источники предоставлять вместе с ответом, да? То есть мы как бы извлекаем информацию, а получаем контекст, метаданные и вместе с, соответственно, с источниками LM генерирует ответ с указанием источников, откуда этот ответ был получен. Это может быть там примерно в таком формате выдано, да, на вопрос пользователя есть ответ системы и перечень источников там со ссылками, да, чтобы их можно было перейти, открыть и посмотреть. А отдельно удобно делать как бы там в нейропоиски делаются с указанием цитат, чтобы можно было понять там какая часть ответа на основе какого документа сгенерирована. В целом это полезно, да, для пользователей, повышает их доверие к ответу, возможность обратиться к первоисточнику для разработчиков, соответственно, быстро отладка без перехода в систем мониторинга, логирования, да, вот прямо вот непосредственно через там интерфейс работы с агентом. Аа, ну, в общем, для бизнеса тоже также удобно смотреть, проверять, прослеживать и давать обратную связь. Самое главное, нам быстро, особенно на этапе разработки альфа-бета тестирования. Аа, ну, зачастую эту опцию там в зависимости от назначения приложения там закрывает какой-то конфигом. Либо она доступна, либо нет для конечных пользователей. Аа, но в любом случае логируется это всегда, то есть на основе каких источников был получен ответ.
Ну и заканчивая уже тему улучшения, скажем так, нашего ретри компонента. поговорим про векторные базы данных, которые нам, конечно же, нужны, если мы хотим персистентности, то есть постоянности хранения нашего индекса, аа довольно большой скорости доступа, если наша база, а документов разрастается, масштабируется, нам уже inmemory решения, да, здесь будут не очень удобны по всем этим, соответственно, параметрам. А популярные векторные базы квадрант, Chrom, Pincone. На самом деле, э, для разработки, там первые стадии разработки решений можно использовать Chrome на database, но, а, как бы такая рекомендация, скажем так, некая абстрактный конь в вакууме для продакшена использовать квадрант, поскольку оно может быть в том числе и селфost решения, а, предоставляется, и она в себе имплементирует и, соответственно, частотный поиск, и семантический поиск. Ну или point как менеджер решения. А-а, конечно же, этих баз намного больше, поэтому это лишь такая, а сравнение как бы основных типов.
Ну, архитектурное наше решение с векторами базы данных будет выглядеть следующим образом, да. Соответственно, оно в себя хранит, а, непосредственно вектор, а, какого документа. И перед тем, как произвести поиск, у нас высчитывается вектор поискового запроса. И внутри векторной базы данных у нас происходит поиск документов, релевантных заданному вопросу по сравнению их векторов, и отдаётся топка результатов на выход. Очень важно зачастую, да, и не надо этим пренеберегать, а формировать метаданные и использовать их для фильтрации, а, сужения области поиска, соответственно, наших документов. Ну, высчитывать их на этапе индексации, на этапе обработки, предобработки запросов и на дан напрямую спрашивать у пользователя, а чтобы сужать сужать область поиска. Ну, например, да, там типы документов, там ключевые слова, теги, а, язык, даты какие-то, ну, любые другие атрибуты.
Ну, и теперь давайте перейдём, а, к большой теме, да, там платформы, а, мы её назвали для контроля за агентами. А, ну наиболее распространённые там платформы, это LMI от разработ от компании разработчика знаменитого фреймворка Lchain Landph. И также у неё есть много аналогов. Ну, один из распространённых - это LFUS, который может быть уже не только как бы ачит решением, облачным решением, но и поставлен а локальная self-хоost версия openсоourсная. в общем-то, по функционалу очень сильно похож на LMI. Ну и по собственному, в общем-то, способам работы, интеграции в свои решения. А эти платформы покрывают там три ключевые, которые мы в этом видео рассматриваем области. Это observability, мониторинг, да, работы агентов, а evaluation, контроль качества и dataset management, observability, соответственно мониторинг и треacing. М, что это такое? Нам надо всегда понимать, что происходит внутри lm системы. И мы не про традиционный мониторинг, да, там ЦПУ, мери, там сетевого доступа. А это, конечно, тоже важно. Мы здесь проспецифичные вопросы сейчас говорим. Какой промт использовался? Какие параметры передавали в ЛМ? А сколько токенов потрачено? Сколько стоит запрос? Какие документы нашлись в рак? А с каким скор? А какие инструменты агент вызывал, сколько шагов сделано, где произошла ошибка. В общем, весь тот полноценный трейсинг путь запроса от начала до конца, там с детализацией каждого шага. очень полезен, а, чтобы был сохранён, ну и, конечно, удобен для анализа и изучения, да.
Ну, вот, например, там юзер спрашивает: "Расскажи о ваших услугах по AI, и мы видим весь трейс старта агента, вызова э языковой модели для планирования вопроса, вызов инструментария в ответы, сколько времени заняло, а, тот или иной шаг, и, соответственно, там генерация ответа". а-э, языковой моделью и выход, конец работы агента. Всё это один, а, как бы такой цикл, трейс, каждый шаг нам виден до финального ответа. Ну и пример там графического интерфейса там с документацией Fuse. Как это может быть, как это предоставляет визуализацию этого трейса непосредственно такие платформы? В общем, эти платформы позволяют вот за счёт того, что они сохраняют такие трейсы, да, нам отслеживать там важные метрики, строить дашборды, а для анализа, в том числе и производительности, и стоимости, и качества работы наших агентов, и различных агентских метрик. А-а, ну и там в том числе можно там делать свои уже кастомные там метрики для оценки там бизнес показателей возврата пользователей, конверсии в заявки и так далее и тому подобное.
Также в этих платформах э существует хороший а-а пласт а функций для эволюэation контроля качества. Ведь без контроля качества, да, как нам понять, а что агент работает хорошо, что он стал лучше после наших изменений там в коде, после изменения в данных? А какие запросы работают плохо? А когда он галлюционирует? В общем, evaluation, контроль качества отвечает э отвечает нам. А какое качество ответов мы имеем, да? Вот лучше или худше, там, пошла регрессия после изменений, а подсвечивает там проблемные какие-то кейсы. А, ну и, конечно же, мы там можем понимать, где у нас основные источники там галлюцинации появляются.
С точки зрения контроля качества есть два подхода. Это офлайн evaluation и онлайн evaluation. Ну, сейчас мы их отдельно рассмотрим. offline evaluation. Его суть в том, что мы тестируем работу нашей системы, а, скажем так, либо на этапе разработки, ну, как бы вне мм непосредственно прямого контакта с пользователем. Тестируем на заранее подготовленных датасетах. Это прямо обязательно. вещь и любую разработку агентской системы надо начинать с анализа данных, дасетов, вариантов использования, и подготовки датасета для аа для того, чтобы нам иметь целочис численную метрику качества работы нашей системы. По сути, это датасет - это, скажем так, упрощённая это пара вопросов, эталонный ответ, а, на котором мы запускаем агента. Сравниваем ответы с эталоном, вычисляем метрики, сохраняем результаты. И, соответственно, это быстро, дёшево в том плане, что мы ещё не запустили там внешнюю систему, уже получили оценку качества, хорошо воспроизводимо и легко сравнивать версии наших пайплайнов, наших систем между собой, имея вот эти самые метрики для Retrieval компоненты. А, ну, скажем так, стандарт там де-факто это метрики от фреймворка Рогаз, а, соответственно, точность найденных документов, полнота поиска, а там есть галлюцинации, нет ли галлюцинации на этапах генерации, отвечают ли ответ на заданный вопрос, корректность этого ответа. Причём многие метрики, а даже не требуют подготовки эталонных ответов, а оцениваются через lm jge подход, когда другая языковая модель оценивает, в общем-то, работу нашей системы. Фреймворков довольно много. Там и не только Рагаз, да, это и True Lance, Deep Evel, а и в общем-то есть встроенные оценки метрики Smith, Wuse. А, ну как такой bestс, там для быстрого старта использовать газ и Lмиit или Luse для удобной а визуализации.
Метрики для агентов - это отдельный блок, который тоже надо понимать, что не такой тривиальный, да, поскольку агент может выполнить одну и ту же задачу абсолютно разными путями, и надо понимать, как правильно оценивать его качество, да? А, ну нам в помощь, в общем-то, набор метрик, а способности агента размышлять, логичность рассуждений, качество планирования, достижения целей, а работы с инструментами, да, как он, насколько правильно он выбирает корректный инструмент, успешность вызов инструментов, эффективность, а, эффективность достижения задачи, да, сколько за сколько шагов он достиг цели, а, соответственно, какая стоимость у нас получилась выполнения задач. время выполнения, качество результата, да, там процент успешных задач, корректность результата, удовлетворённость там пользователей, а, соответственно, применяется тоже зачастую как бы как lm a judge подход для способности оценки там ризинг и планирования. Ну и, конечно, классические метрики тоже никто не исключал там прямого, например, сравнения, что там для, а, ну, с эталонным детасетом, что, например, для решения такой-то задачи должны быть вызваны такие-то инструменты, возможно, ещё и с такими-то параметрами. Ну, про User Feedback мы поговорим как раз дальше и переходим к уже от оффлайн оценки качества к онлайн оценке качества, когда мы собираем вот эту обратную связь о качестве работы в нашей системе в режиме онлайн на реальных диалогах реальных пользователей.
Ну, у нас тут есть традиционно два подхода. Собрать, а, непосредственно ответ от пользователя, условно кнопочкой лайк, дизлайк, а, оцени ответ. и LM judge, когда у нас мы сами попытаемся фон фоне от пользователя оценить, в общем-то, насколько хорошо наша система отвечает, ведёт диалог. Например, usеer feedback, э, ну, уже разобрали, да, соответственно, где-то агент даёт ответ пользователю, и мы у нему предоставляем возможность отправить нам обратную связь об этом ответе. Все эти данные собираются, и вот такие платформы, как Landsmith, они предоставляют удобный там, в общем-то, способ их агрегации и последующего анализа.
Подход LM the Judge, а когда мы используем lm для автоматической оценки ответов, ну, выглядит следующим образом. Пользователь задал вопрос, агентст создал, отдал ему ответ, и в фоне у нас языковая модель оценила этот ответ и какие-то метрики посчитала. А, ну, например, релевателен был ответ вопросу или нет, насколько он полный был ответ, а насколько он был фактически точно, то есть построен на извлечённом контексте, невыдуманной модели на основе каких-то своих там домыслов и своей параметрической памяти. Громматику, стиль можно оценить галлюцинации, соответственно, токсичный, нетоксичный ответ, тональность ответа, ну, в общем, всё, что угодно, а можно настроить сути системный промто для вот такого судьи третейского. Важно использовать, конечно, сильную модель, использовать желательно другую модель для оценки, нежели то, что использовать для регенерации. Ну и понятно, что надо комбинировать это с usерфидбеком.
И вот собираемый такой онлайнфидбк, да, то есть когда система работает, мы понимаем, что есть у нас какие-то трейсы, какие-то диалоги, кусочки диалогов, которые, а, качество у нас не удовлетворяет. Конечно же, нам важно улучшить свою систему, чтобы эти наша система научилась там по таким вопросам, по таким сценариям отвечать корректно. Для этого эти платформы предоставляют удобный способ, в общем-то, там, а, аннотирования таких трейсов и формирование на основе них датасетов, да? То есть у нас какая-то версия работает там в проде. А проишёл такой онлайнсбор обратной связи. Мы создаём отдельный детасет, наполняем его из промышленных там вопросов ответов, сценарий траектории работы нашего агента. И дальше в уже переходим в оффлайн аuation стадию, да, когда мы дорабатываем наше решение, а готовим какую-то новую версию и проводим вот этот оффлайн оценку качества. Если мы понимаем, что она там достигнута, её цель, качество улучшилось, ну, можно выпустить новую версию и уже отправить её, а обратно в prodдакшн.
И здесь у нас рождается, да, уже такое понятие, как dataset manджмент. А что очень важно? Все эти детасеты грамотно уметь хранить, чтобы можно было к ним вернуться, посмотреть, там, переосмыслить, а, посмотреть, а вот эта оценка качества метрики, она была на каком датасете создана, чтобы это всё не было потеряно, утеряно. И, в общем-то, это то, что мы у нас уже в конце видео разбирается, но на самом деле одна из первых вещей, с которыми мы сталкиваемся при разработке вот такой prodдаction ready системы, да? То есть нам, нужно вначале создать этот датасет, а руками либо синтезировать, да, его с помощью языковой модели на основе там базы знаний или реальных диалогов, логов. А если мы, например, эмулируем уже работу какого-то, а, ну, реальной системы, где у нас человек раньше взаимодействовал с пользователями, всё это разобрать, создать датасет и зачастую использовать гибридный подход, то есть синтезировать и руками выверить. сохранить систему контроля версий, загрузить на платформу LMI, то есть присвоить там детаименование версию и дальше проводить эксперименты, то есть оценки качества нашего решения на том или ином датасете. И у каждого эксперимента тоже присваивается свой номер, а, фиксировать полученные метрики и, конечно же, анализировать, сравнивать метрики каждого версии нашего приложения, чтобы выбирать лучшую версию, которая пойдёт уже в prodдаction.
За эти два видео мы с вами разобрали очень многое, а, ну, по сути, ту самую необходимую базу, которая нужна для того, чтобы построить prodдакш систему, агентскую систему, готовую для запуску в реальных условиях, по крайней мере, чтобы её было не страшно запускать, а поскольку аа бороться с этим страхом нам позволяет контроль над ситуацией. Но это ещё не всё. А с ростом системы, с её масштабированием, появлением большего количества пользователей, ростом диалогов, задач, количество инструментов, ну и в целом с ростом ваших запросов, вы, конечно же, столкнётесь с необходимостью знать и понимать ещё большее количество тем, аа такие как планирование, декомпозиция задач, да, выстраивание там траектории выполнения той или иной задачи. Тут понадобится и подключать и техники работы. с памятью агентов, с его скилами, навыками, а возможно подключать субагентов или делегировать ряд задачи другим агентам, конечно же, продвинутой техники контекст инженениринга, да, как работать с разрастающимся контекстом, управления состоянием, возможно, выгрузкой контекста в файловую систему, а работы с мультимодальным контекстом, на вход поступаемых изображений или там видеоаудиоконтента. А с точки зрения компоненты актуально там для больших обознаний графовые системы знаний графы. А тот же самый граф рак подход, мультимодальный рак, да, когда у нас и в базе знаний хранятся не только тексты, но и изображения, таблицы, там сложные, акту сложные структуры, документа. С точки зрения безопасности очень полезно использовать сканеры безопасности, да, так называемый redтиминг для тестирования, а, нашей системы, а, противостояние известным угрозам, да, безопасности. В целом промтменеджмент полезная история, да, чтобы у нас было централизованное управление промтами, версиями, проводить а-тесты разных промтов. Ну и, конечно же, уже переход к мультиагентным системам. различные архитектурные паттерны построения таких мультиагентных систем. И одновременно с этим возможно распределённых агентских систем с помощью протоколов agent to agent. А есть отдельный, да, там протокол, например, а агентские коммерции. И, конечно же, будет полезно знать про Agent to UI протокол, да, ну и любые подходы к генерации пользовательского интерфейса, да, в агентский цикл, в агентском цикле, когда для сбора информации с пользователя агент не просто в чате ему, а, пытается из него извлечь информацию, а предоставляет удобные, компактные форму для ввода той или иной информации.
Мы у себя на lmstart.ru разработали три программы обучения. Одна из них интенсивного формата умный вайбкодинг и агентов, где мы знакомим слушателей с основой работы, а с кодовым инструментарием, кодовым агентом Курсор для ведения грамотной разработки и решений, в рамках которой уже сразу создаём портфолио из там пяти проектов. Ну, по сути, она является таким быстрым стартом в умный вайб-кодинг и агентов. а-а как для технических, да, специалистов, то есть с бэкграундом техническим там программистов-разработчиков, так и для предпринимателей, стартаперов, в общем, людей из больше из бизнеса, нежели из технологий. И более углубленный курс Eriвен разработка и агентов, где мы разбираем вот всё то, что было в первых двух этих видео озвучено уже подробно, и обучаем создавать prodдакш системы, а, пошагово, последовательно. в общем так, полным пониманием всего, что необходимо. И, конечно же, тоже с помощью AI Driven подхода, а ни в одной из этих программ, а потребности писать код вручную, а, ни у кого нету. Ну и третья программа Deep Aged - это продвинутая разработка и агентов, где уже как раз разбираются вот все вот эти темы с предыдущего слайда аа подробно, детально. А, соответственно, тоже она у нас запланирована на этот 2026 год. Поэтому переходите на lstart.ru, выбирайте нужную вам программу. А если вы хотите заказать разработку там и решения или проконсультироваться по внедрению искусственного интеллекта в ваш бизнес, пишите мне в Telegram SNF AI. Подписывайтесь на наш Telegram-канал AI Dialog. Ну и, конечно, выбирайте понравящиеся вам тренинги, курсы на нашем сайте lmstart.ru. Спасибо за просмотр. До новых встреч.