Как системный аналитик может использовать ИИ в своей работе

Так, ну что ж, уже 8 вечера, значит, нам пора начинать. Те, кто не успели, я надеюсь, тянутся. Сейчас я пошарю экран и, собственно, мы начнём. А так, вроде всё. Ну, поехали.

А перед началом, если не сложно, поставьте плюсики в чат, если меня видно и слышно, мой экран видно. Включая презентацию. Спасибо. Спасибо.

А у нас сегодня открытый урок к старту курса Системный аналитик TeamL. Сегодня с вами буду я. Меня зовут Лавров Денис. Я старший архитектор компании МТС. А в данный момент занимаюсь проектированием архитектуры платформы синтеза распознавания речи, но в общем, достаточно много чем успел позаниматься и в качестве архитектора. В том числе на курсе системного Analyticul я в основном веду занятия такие более технические, которые, ну, связаны, перекликаются именно с функцией архитектуры, такие как High Load, ээ, проектирование observability и так далее.

А вот, собственно, моя телега здесь есть. Если какие-то вдруг там вопросы будут до курса, если вы вдруг на него ещё думаете записываться или нет, то можете в телегу в том числе писать.

А по правилам вебинара у нас открытые уроки проходят максимально приближенно к формату боевых обычных занятий на курсе. С единственной разницей: у нас другая платформа, то есть на курсе мы занятия проводим в МТС Линке, где есть возможность, скажем так, обратной связи с вами, голосом. Э-э, сегодня у нас платформа другая, собственно, Live Digital, и здесь вы можете со мной коммуницировать только вопросами в чате. Вот, в принципе, и вся разница. В остальном же приветствуется активное участие от вас. Задавайте вопросы. Постараюсь на них ответить, конечно, уложившись в тайминг. Хорошие вопросы по теме задавайте, а в топик не задавайте. В общем, хорошо делайте, плохо не делайте.

Э, запись вебинара будет, наверное, один из самых частых дефолтных вопросов. Он придёт на почту, на которую вы регистрировались на этот открытый урок. Ну, и соответственно, будет выложено, не помню, где там сейчас выкладывается, в ВК или в каких там других ээ системах обмена видео, какие сейчас разрешённые у нас есть.

А перед началом на открытом уроке мы обычно знакомимся. Если у вас у вас нету каких-то там секретов, ээ, то можете написать в чат, какая у вас актуальная позиция и с какой целью вы пришли сегодня на открытый урок. Возможно, просто поглазеть, возможно, думаете, стоит ли записываться на курс и так далее. Любая информация будет полезна команде курса. Мы любой информации рады, которую вы сможете предоставить. Поэтому, если не э сложно, то поделитесь в чате, пока я буду вещать. Собственно, это асинхронная история. Я отвлекаться на эту тему не буду. В принципе, можете и до конца занятия этой информацией делиться. Вот.

Ещё раз повторюсь, что у нас сегодня открытый урок к запуску курса Системный аналитик Team Lead. Он стартует у нас 27 марта. То есть это уже вообще вот-вот-вот, 4 дня осталось. Это, я так понимаю, последний открытый урок к этому запуску. Курс длится 5 месяцев. Занятия идут два раза в неделю по средам, пятницам. Если форс-мажоров никаких не происходит, в 8:00 вечера стартуют занятия. Длятся два академических часа. То есть от часа 30 до 2 часов могут длиться. То есть где-то с 8:00 до 10:00 вечера два раза в неделю вы будете заняты. Конечно, все занятия идут в формате онлайн. Это накладывает некоторые возможные форс-мажоры вроде того, что там у преподавателя может быть что-то там с интернетом, здоровьем и так далее. Поэтому иногда может что-то меняться, но в общем ориентироваться можно на среду и пятницу для запуска вашего курса.

Э курс ориентирован на системных и бизнес-аналитиков, преимущественно уровня middle. Понятное дело, что совсем джун позиции, наверное, будет там тяжело, на материал всё-таки такой с частично уже с переходом на функцию архитектуры. То есть он будет полезен и джунам архитекторам, но и частично ещё в курсе где-то такая добрая часть его отдана менеджерским скилам. То есть это будет интересно тем, кто смотрит ещё в управление персоналом. Э вот при этом, ну, думаю, это будет интересно не только тем аналитикам, но, возможно, каким-то позициям, которые с ними коммуницируют и тесно связаны по работе.

А-а вебинары проходят в формате live. Вопросы можно задавать голосом преподавателям. Каждый вебинар ведёт какой-то компетентный преподаватель в этой теме. То есть нет такого, что весь поток ведёт кто-то один. За время курса вы познакомитесь с несколькими преподавателями, там 5, 7, 8, 10, в зависимости от того, как там конкретно выстроится расписание. Вот. То есть, но каждое занятие будет вести тот, кто в этой теме хорошо разбирается. Не бывает специалистов, которые одинаково хорошо разбираются во всех темах.

Также будет отдельно, ну, достаточно большое количество домашних заданий. Не к каждому уроку, но где-то каждому второму, каждому третьему занятию будет домашка. Ну, а в конце будет проектная работа. Программа курса по блокам, она на экране, то есть мы к ней ещё вернёмся в конце, посмотрим лендинг самого курса и более детально глянем, чтобы сейчас пока не отвлекаться. Ну, всё поделено на блоки. Э, ну, в конце проектной работы, думаю, здесь добавить нечего. Лендинг более чем подробно рассказывает о программе.

Ну и теперь мы постепенно переходим уже к теме нашего занятия непосредственно. Ээ у нас сегодня, поскольку тайминг немного сокращён по сравнению с обычным занятием, пришлось кое-что вырезать. Ээ у нас сегодня задача уложиться в, ну, часовой тайминг, по сути. Вот. Ну и поэтому давайте начинать.

Как системный аналитик может использовать плоды искусственного интеллекта в своей работе? Сразу же дисклеймер: ээ у нас на курсе базовый уровень ээ компетенции в области ИИ у студентов, мы оцениваем как совсем минимальный. Поэтому и подача материала сегодня будет совершенно базовая. То есть я начну с самых азов и буду рассказывать в том числе и базовые совершенно вещи. То есть, если кто-то уже прям имеет хороший опыт работы с ИИ инструментами, то, возможно, будет, скажем так, немного простовато и скучновато. Но, повторюсь, сегодняшний материал, он подаётся для тех, кто базово, в принципе, почти ничего не знает про ИИ, там, слышал про чат GPT и так далее, не более того.

Вот теперь после дисклеймера поехали. Поговорим сегодня про основы, собственно, LLM. Ээ, это большие языковые модели. Поговорим о техниках работы с промтами как один из основных инструментов повышения качества результата от ИИ. Поговорим о том, что такое ИИ-агенты, для чего они нужны, как они помогут, могут вам помочь в вашей задачах и не только в задачах по работе, но может быть каких-то других. И в конце посмотрим демку, как с помощью no-code инструмента создавать свои ИИ-агенты с помощью популярного инструмента. Понятное дело, что ИИ-агенты можно делать, в том числе не печатая код непосредственно ручками, но повторюсь, мы целимся в аудиторию, которая только знакомится с этим. И поэтому предлагаем простой сегодня путь такой entry-level по входу в эту нишу с no-code решений.

А вот, ну, в общем-то, и всё. И после этого вернёмся и поговорим ещё про курс. Я поотвечаю на ваши вопросы, и на этом мы с вами попрощаемся на сегодня.

А для чего это вам надо? В общем, глобально для того, чтобы быть в тренде. Это первое. Ну, как бы это не звучало для кого, но так или иначе ИИ инструменты все по-разному к ним относятся, но они могут ускорять работу за счёт автоматизации некоторых рутинных операций. То есть ИИ – это не панацея, он не сделает за вас всю работу, но он может улучшать, ускорять, повышать качество определённых рутинных операций. Насколько вам это подойдёт, зависит от того, сколько у вас рутины, всякой различной в вашей работе. Всё-таки функционал системного аналитика, а уж тем более роль тимлида для аналитиков, она от компании к компании очень сильно различается. Руководить людьми за вас ИИшка точно не будет, но где-то в каких-то аспектах она вам поможет.

Ну, начнём. Собственно, первое самое простое, что может, как может аналитик системный использовать ИИ в своей работе – это использовать популярные чат-боты. Все слышали, думаю, ну, исторически там популяризовалось всё это после выхода GPT третьего. Сейчас есть целая плеяда различных инструментов, как российских, типа Гигачата. Блин, забыл, как у Яндекса называется. Яндекс GPT, по-моему. То есть различные решения от, скажем так, мейнстримных гигантов вроде Gemini, Grok, Llama. GPT сам по себе тоже никуда не делся. Есть, собственно, китайские братья, Псик и так далее. О, либо бы есть своя модель. В общем, решений много. И по большей части это уже готовые. То есть это нужно понимать, что это непосредственно не сами по себе там языковые модели вы используете напрямую, когда общаетесь с чат-ботом. Это уже вы используете комплексный продукт, который, ну, по сути, является чат-ботом, где над моделью искусственного интеллекта есть определённая обвязка, которая вам делает жизнь, ээ, простой.

А вот какие плюсы использования такого рода решений – это, конечно, простота. То есть у вас есть сервис, да? Ну, конечно, сейчас у нас в наших реалиях простота ещё начинается с того, что вы думаете, как оплатить какой-нибудь зарубежный сервис, какой-нибудь зарубежные карточки, и особенно если это в корпоративной среде всё происходит. Ну, допустим, вы лишены этого недостатка, вы или вы используете русские сервисы, допустим, у вас всё есть. Вот после этого всё просто. У вас есть диалоговая система, вы задаёте туда вопросы, вам отвечают, как будто бы у вас сразу же знание всего мира есть под рукой. Вы можете использовать это для различных целей. Для чего используют это чаще всего аналитики? Из того, что я видел, ээ, это различные истории. Ну, как бы так, упростить рутину. Какая рутина? То есть у аналитиков это постоянные истории с формализацией требований, user story. То есть есть какая-то постановка, из неё на выходе нужно выплюнуть строго формализованный набор пунктов каких-то. Используется, используется. Про всякие нюансики поговорим чуть позже, какие есть подводные камни здесь.

А генерация различных спек, то есть надо сделать ERDшку для БД. Если правильно зададите вопрос, вам ээ моделька сгенерирует. То есть она мультимодальная, спеку либо как минимум в какой-нибудь нотации её выдаст. Не обязательно картинку вам будет генерить. Ээ какие-нибудь ээ Swagger погенерить, да, придётся заморочиться с тем, чтобы описать спецификацию всех методов. На выходе можно получить валидную Swagger спецификацию. А BPMN нотации, различные flow описания, sequence диаграммы – это всё спокойно справляются языковые модели. То есть, если правильно поставить вопрос, нужно написать какой-нибудь SQL запрос. У многих аналитиков с этим проблема – писать хороший запрос с SQL. Ну, как минимум сейчас, если нормально, опять же, поставить задачу, то вам чат-бот, в принципе, выдаст на выходе валидный SQL запрос, возможно, даже оптимизированный под какое-то производительное выполнение.

Ээ, нужно написать какие-то куски кода, тоже не проблема. Понятно, что полноценный код LLM и полноценный код – это отдельная история и холиварная. Но если там вам для работы там нужен какой-то написать небольшой скриптик на Python и так далее, то с этим спокойно справится, собственно, чат-бот, тем более специализированная модель какая-нибудь, которая для этих целей создана.

Различные истории с обработкой больших массивов данных, сделать самаризацию. То есть у вас есть куча данных. Часто, например, для тимлида это, ну, в принципе, для всех позиций ледовых, которые занимаются подбором персонала, это история. Давайте-ка, у меня есть 100 резюме, мне нужно отобрать наиболее подходящих кандидатов. Прекрасно. А вам с этим сможет помочь, в принципе, чат-бот. Или у вас есть какой-нибудь стенограмма какой-нибудь встречи. Вам нужно выделить основные тезисы, чтобы отправить по почте всем основные тезисы, например, тоже можно загнать. Модель вам выделит основные тезисы. Многие, собственно, системы сейчас для, собственно, видеоконференции уже встроенную такую историю имеют, когда в процессе беседы голос записывается, потом переводится, собственно, в стенограмму в текстовую, и из этого текста выделяется уже саммари, и оно рассылается, как бы, то есть, в принципе, типовых задач можно ещё список расширить. Тут есть троеточие. То есть я сам не практикующий системный аналитик, чтобы прям знать все абсолютно рутинные аспекты, какие встречаются у аналитиков. Но тем не менее это всё работает. Это всё мм аэ то, где можно ИИшку использовать.

Интереснее, что здесь у нас какие подводные камни есть и минусы, потому что если бы всё было так просто, то мы бы закончили сегодняшнюю встречу на первом слайде и дальше бы не пошли. Вот у вас есть чат GPT и вперёд, все проблемы им решаете. Но это не так. Ну, основной концептуальный минус использования диалоговых систем – это то, что это сугубо ручное взаимодействие без какой-либо автоматизации и интеграции. То есть, да, конечно, сейчас современные диалоговые системы пытаются там и заигрывать в эту сторону. Опять же, не буду отвлекаться там на технологии, какие там используются. Договорились, что у нас сегодня базовый всё-таки курс молодого бойца. Но так или иначе, всё равно это всё построено на том, что вы вручную что-то собираете информацию, пишете запрос. От того, насколько качественно вы её собрали, поставили задачу. Тут не забываем, что как-то без хорошего ТЗ результат хз. Здесь всё то же самое. То есть, чтобы поставить корректно запрос в языковой модели и диалоговой системе, собственно, нужно потрудиться ээ и в зависимости от того, какая у вас сложная задача. Вот. И это всё ещё, кроме этого, не автоматизировано. То есть модель вам не будет делать что-то по расписанию. У вас есть какие-то истории там, что вам нужно каждое утро формировать какую-то, не знаю, там саммари о инцидентах там на продакшене за за ночь, например, которые приходят вам, не знаю, там в Telegram-канал или где-нибудь там в графане подсвечиваются. Ну, как бы диалоговая система вам здесь особо не поможет. Автоматизировать какую-то историю вы не сможете. Там хотите что-то опять же делать регулярно по событию, по расписанию. Ну нет, вам придётся это делать руками. Интеграции тоже нет. Модель вам выплюнет ответ в чат, и дальше вы её понесёте туда, куда донесёте. То есть пойдёте создавать на основании этой информации тикет в Jira, пойдёте рассылать email, сами пойдёте в Confluence страничку заводить и так далее. То есть здесь всё всё равно всё на ручнике, интеграции нету. Это концептуальный минус именно самих диалоговых систем. Он решается именно переходом на модель и агентов, ну, о которой мы будем говорить ближе, собственно, к концу и смотреть на демки.

Дальше, что у нас из минусов есть? Обычно, если вы общаетесь с моделью, она вам не всегда даст ответ, который вы хотели бы видеть. Ээ то есть, ну, банально могут быть истории сугубо стилевые. То есть вам нужно вс микрофон отключился немножечко. Ээ то есть стилистические истории. Модель может вам говорить в неподходящем стиле, может быть давать сообщение в каком-нибудь слишком неформальном. То есть вам надо как-то явно модель настроить на нужный вам стиль или наоборот вам нужно, чтобы модель беседовала как-то неформально, напротив и так далее. Зачастую вы хотите явно понимать, а, иметь ссылки на те материалы, на которые модель опиралась, а их обычно в ответе у модели тоже нету. То есть она вам просто выдаёт портянку текста и каких-то ссылок на источники этой информации часто не бывает.

Ну и самая большая история – это то, что это ошибки, слэш галлюцинации. Обычно они называются у модели. То есть то, что выдаёт модель, нельзя принимать на веру. Это самая основная из проблем, потому что модель, ну, сейчас мы дальше будем базово говорить, как модель работает, почему так происходит, но модель не всегда отвечает правильно. То есть она может с абсолютной уверенностью говорить вам бред, ээ, то, чего не было, то, чего, что не соответствует реальности. И в общем случае вы даже об этом не догадаетесь. И это фундаментальная проблема. Стопроцентного решения у неё нету, но как бороться, способы есть. Мы базово о них сегодня поговорим тоже. Вот, собственно, эта история касательно вот качества, по сути, работы модели. Тут и агенты вам сами по себе не помогут в лоб, но тут поможет работа корректная постановка задачи для модели. Зачастую это, собственно, работа с, ну, по сути, с заданием, с техническим заданием для модели. Об этом мы тоже сегодня поговорим.

А что ещё у плохого, ну, то есть такого минусов каких есть модель? В общем случае вам, то есть, ну, думаю, вы понимаете, что модель машинного обучения, она обучается на каких-то данных, и она обучается на каких-то данных конечного, то есть, и это происходит когда-то. То есть условно там, не знаю, там чат GPT, по-моему, там 4-5 последний, он учился в двадцать пятом году ближе к концу, если им память не изменяет. Он, то есть, и модель ничего не может знать о каких-то событиях, которые произошли после того, как её обучили. И, ну, в общем, она не знает ничего о событиях, которые не входили в обучающую информацию для неё, обучающий датасет. Вот. А вам зачастую это надо, в общем-то, либо в лоб знать какие-то истории, там, не знаю, какой курс доллара сегодня, модель об этом знать ничего не может, соответственно, или какие-то такие истории. И в принципе, фундаментально модель ничего не может знать о каких-то, ээ, ну, приватных данных. А ваши корпоративные данные, скорее всего, они явно не были в датасете у модели. Вряд ли у вас код вашего там репозитория утёк куда-нибудь к Гуглу, чтобы на нём учили модель, или вряд ли вы сливали содержимое своего Confluence и так далее. Поэтому модель объективно ничего не знает о вашей м ситуации у вас внутри компании, если мы говорим про использование в рабочих целях её. То есть она вам ничего не расскажет про там какие-то странички у вас в Confluence, про какие-то задачи в Jira, про там там Trello задачи, про всё, что угодно, она ничего этого не знает. И это тоже как бы, ну, проблема. Это сильно сужает спектр задач, которые можно решить. То есть, условно, какие-то нет доступа к базе знаний вашей компании у модели. И тут тоже, ну, диалоговая система вам в лоб никак не поможет, классическая, потому что она может просто с вами прекрасно беседовать, но и отвечать на какие-то вопросы широкого спектра знаний, но на узко специализированную информацию она вам ответит. Ничего она вам не ответит, если вы ей как-то явно не поможете.

Ну и фундаментальная проблема, опять же, что использование всех этих облачных сервисов упирается в то, что а туда не безопасно, в общем-то, грузить всякую чувствительную информацию. Вроде как вы бы и могли бы, конечно, взять и задать вопрос модели, скопировав во входной запрос содержимое там, не знаю, какого-нибудь вашего репозитория или там вашего Confluence там и так далее. Но это просто банально небезопасно. Вам безопасники поголовно вас не погладят, если такое узнают. Соответственно, облачные сервисы использовать можно ограниченно. В этом плане нужно сильно 100 раз подумать: "А что же вы туда грузите? Вы можете грузить что-то очень такое публичное, но задавать какие-то приватные вопросы не стоит с приватной информацией".

Собственно, поэтому смотрим, какие есть пути решения. Но перед тем, как говорить про пути решения, нужно вообще базово устаканиться на тему того, что какие термины здесь есть. Потому что, если вы пользуетесь чатом, чат GPT, условно там или Дипсиком, ну, вы пользуетесь этим как обычный пользователь, просто задаёте вопросики, он вам что-то отвечает, вы ничего не знаете о его устройстве под капотом. А чтобы дальше пойти, что-то там делать и агентов или правильные, корректные там запросы формулировать для модели, нужно хотя бы чуть-чуть понимать. Чуть-чуть. мы сегодня сильно не будем, то есть чуть-чуть понимать, ээ, а что же там вообще происходит внутри и почему что-то работает, что-то не работает и почему это работает именно так. Поэтому начнём с первого.

То есть LLM – это большая языковая модель – это то, что, собственно, является сердцем всех диалоговых систем популярных. Это определённый тип моделей машинного обучения, которые понимают естественный язык человеческий и умеют в ответ генерировать тоже человекоподобный текст. Это, собственно, основная их история, потому что и то благодаря чему они там произвели в своё там в двадцать там втором году там фурор в двадцать третьем, когда, собственно, вы общаться настали с моделью, которая почти неотличима по манере беседовать от обычного человека. Эти модели обучаются на огромных массивах данных, огромных, прямо огромных. Там слышали, думаю, там выкачиваю чуть ли не весь интернет втихаря. Всякие нехорошие ребята из там из Facebook, из Google и прочих запрещённых организаций. Они эти данные получают на вход, по сути, выявляют закономерности в этих данных и запоминают эти закономерности. И на самом деле эти языковые модели ничего более не умеют, кроме как предсказывать наиболее вероятное следующее слово. То есть не нужно думать, что большая языковая модель умеет думать, что она у имеет там сознание или что-то ещё, что она понимает ваш вопрос и так далее. Нет, вы пишете: "Привет, меня зовут Денис". И она пытается предсказать, а какое слово должно быть следующим, то есть на основе всего того массива данных, что она видела до этого. И скорее всего, она наиболее вероятно представит, что следующее слово должно быть "привет". Потом к ней уже на вход подаётся вот вся последовательность: "Привет, меня зовут Денис". И ответ её: "Привет". Она дальше предсказывает следующее слово: нужно ли тут закончить? Может, нужно тоже самой представиться, например. И так постепенно оперативно получится ответ, там, "Привет, меня зовут там ИИ-ассистент, я там могу помочь тебе на что-то ла-ла-ла". Вот. То есть всё на этом, в общем-то, вся функциональность языковых моделей, она заканчивается. То есть нужно понимать, что это, по сути, это как модели в своё время были давно ещё регрессионные, которые просто предсказывали какую-то там стоимость объекта недвижимости, там, не знаю, стоимость земельного участка, там стоимость автомобиля на основании данных. Моделька – это тут то тут просто очень навороченная история архитектурная и технически, которая просто умеет предсказывать следующее самое вероятное слово. На самом деле там слово в кавычках, потому что модели оперируют не словами, а чуть-чуть другой сущностью, мы до неё ещё дойдём.

А что у нас следующее? Это промпт. То есть промпт – это терминология для входного запроса к модели. То есть этот чётко сформулированный запрос к модели. И он, в отличие от простых там казуальных фраз, там "привет", там "ла-ла", "как дела", "ответь мне что-то там такое", это прямо чётко действительно сформулированный запрос. Он обычно включает в себя саму задачу, контекст задачи, ожидаемый результат, формат этого результата. То есть, если вы хотите на выходе получить таблицу, вы чётко описываете таблицу там с колонками и так далее. Описывается обычно роль модели, то есть, чтобы она давала более качественный ответ, ей явно нужно дать директиву, что она выступает там в качестве, например, там системного аналитика, например, опытного, либо она там, не знаю, медик, ээ, либо она просто там помощник, который, ээ, должен там как-то там управлять календарём, например, руководителя и так далее. То есть и различная другая важная информация. В принципе, промпт не имеет жёстких каких-то рамок, но важно понимать, что качественно составленный промпт – это является, по сути, таким обязательным требованием получения качественного результата от модели. То есть одна и та же модель, вы можете к ней обратиться без явного какого-то хорошего промпта, явно не сформулировав критерии качества ответа, какой формат ответа, какая задача, какой контекст и так далее. И она вам ответит плохо. И к этой же модели вы сформулируете правильно вопрос, и она вам ответит хорошо уже. Собственно, на основе этого целая индустрия промпт-инжиниринга существует или промтинга. Есть целые мастера промпт-инженерии, но мы сегодня базово знакомимся с тем, что это очень важная история. Просто спросить, как у Google, например, там написать ээ какой-то рандомный набор слов, которые вас интересует, и надеяться на качество, тут не получится.

Возвращаемся. По сути, это ТЗшка для модели. Некачественная ТЗшка ведёт к плохому результату. А я уже говорил, что модель не оперирует, строго говоря, словами. Да и вы, когда будете работать, или если работали уже с какими-то диалоговыми системами, слышали, наверное, там там 100.000 токенов купил, там там миллион токенов, модель работает с токенами. То есть токен – это минимальная единица, с которой работает модель. Модель не умеет, ну, как бы в общем случае работать именно со словами. То есть она бьёт текст на так называемые токены. И у каждой модели токенизация своя. То есть зачастую это обычно части слов. То есть условно, обычно какие-то корни слов целые. То есть обычно токен – это чуть меньше единица, чем слово. Просто это как бы на какие-то там сегодняшние наши там телодвижения это никак не повлияет, но просто слово токен повсеместно встречается и понимает то, что модель оперирует токенами.

И из этого всего вытекает понятие контекст модели. Это набор. Это количество токенов, которые можно подать на вход модели. То есть на мо на модели на вход нельзя подать бесконечный запрос. То есть ей можно подать ограниченное количество токенов на то есть вы "Войну и мир" вы ей не подадите на вход. Вот, соответственно, и ответить она вам тоже может не бесконечный текст за раз. Она тоже какое-то конечное количество токенов может выдать. Да, у современных моделей это много, то есть там до миллиона там токенов доходит, но у большинства

Широкоупотребимых это меньше, конечно. Это тоже надо учитывать, это контекст модели. Это определённое ограничение, которое, ну, сказывается на нюансах работы с ней.

Соответственно, переходим уже дальше к практике. Ну, как с этим всем жить? То есть по глосарию, я считаю, больше, в принципе, заморачиваться не нужно какими-то дополнительными терминами на сегодня.

Что у нас в плане работы с промтом интересного и что здесь нужно учитывать? А первое, что нужно понимать, когда мы переходим от работы с диалоговой системой к попытке проектировать что-то там более сложное, типа и агента или работать напрямую с самой лмкой, нужно понимать, что модель ничего не знает про она не имеет памяти. То есть, если вы напишите модели непосредственно, то есть повторюсь не чатботу, ээ, а именно самой модели отправите, ну, не знаю, там подключитесь там копишки Open апи или там гигачатуберовскому, отправите запрос, там, скажете: "Привет, меня зовут Денис, ээ, модель вам ответит: "Да, там, добрый день, Денис, там, чем могу помочь?" А потом спросите следующим вопросом: "Как меня зовут?" Та модель скажет: "Я не знаю, как вас зовут". Потому что у модели нету совершенно никакой памяти.

То есть, когда вы общаетесь именно с диалоговой системой, эта история там решается под капотом уже непосредственно разработчиками этой диалоговой системы. Как она решается? Она решается обычно как раз-таки тоже через промпт в тупую. Самый простой вариант это просто незаметно от вас. То есть вы пишете вопрос там, как меня зовут? Э а история вашей переписки, ну, как в как, не знаю, как в Телеграме, в Ватсаппе, просто добавляется незаметно в этот промт. То есть условно вы пишете вопрос: "Как меня зовут?" А диалоговый бот добавляет в конец использует для ответа на вопрос историю предыдущего диалога и копирует туда всю историю диалога, которая у вас была. Соответственно, модель в входном запросе видит и сам запрос, и видит входную информацию на которую она может ответить, потому что, повторюсь, памяти у неё нету.

То есть, соответственно, когда мы говорим про работу с промтом, это одна из историй, можем добавлять туда по сути такую небольшую память. модели в плане беседы, и это так повсеместно используется. Вторая история, добавлять контекста. Понятно, что повторюсь, модель не может абсолютно всё знать, потому что что-то она не в курсе, и вы должны добавить там нужную информацию. Если вы хотите, чтобы вам моделька от, не знаю, описала какие-нибудь usеerстории или, например, функциональные требования по какой-нибудь задаче, вы должны подробно эту задачу описать. Собственно, вот добавлять контекст, собственно, через проomт.

Это, собственно, одна из основных историй. Почему это такая задача а компромиссная? Повторюсь, потому что отмотаемся вот сюда, что контекст у всей моде у каждой модели он ограничен. вы не можете передать туда абсолютно всё. То есть, конечно, было бы идеально взять и всю базу знаний компании запихать во входной запрос и сказать: "Вот на основе этой базы знаний ответь мне что-нибудь". Но у модели входной контекст он ограничен, поэтому, да, и в принципе модели современные, они плохо работают, когда вы закидываете в них абсолютно безграничную информацию. Соответственно, искусство составления промкта и добавление в него контекста, оно заключается в том, что вам нужно чётко дать необходимую информацию, а личнюю информацию, которая будет засорять и или, например, переполнять контекст, вам не давать. То есть вы должны очень такую чёткую выжимку сделать, и тогда всё будет неплохо. У вас будет короткий контекст, в котором есть весь смысл, и модель сможет на основе него строить свой ответ.

Собственно, дальше, что мы хотим ещё сделать через промт? Мы хотим, очевидно, задавать стиль общения, роль модели, чтобы она понимала, что она выступает в роли аналитика, что ей тут нужно генерировать ответ в формальном стиле, в строгом. Где-то ей нужно вести беседу неформально, например, и так далее. То есть мы хотим через промт явно задавать формат ответа. Мы хотим на выходе получить SQL-запрос. Мы строго в промке должны описать, а какие колонки, какие параметры этого запроса должны быть, под какой, например, диалект SQL адаптировать этот запрос нужно, там под MySQL, под MS, под PSG. Ээ, хотим получить на виде на выходе Jon структуру, явно описываем структуру, какие должны быть названия атрибутов и так далее. Вот, собственно, думаю, понятная история. Если мы явно не определим формат ответа, дель вам что-то выдаст, ну, такое размытое.

Аа мы хотим иногда, то есть современные модели умеют не просто выдавать ответ, они умеют последовательно имитировать рассуждение. То есть, ну, по сути, это называется Chain of Sours, ээ, чаще всего. И, то есть, модель умеет показывать, как она рассуждала, при каких-то логических задачах это бывает тоже нужно. И мы можем явно, например, модели через промт указать, что покажи свои рассуждения, как ты действовала по пунктам. А вот и так далее. То есть, чтобы, если для вас важен в ответе не просто ответ, а то, как он был достигнут, то, соответственно, тут надо работать, собственно, с промтом, чтобы модель поняла вас.

Ну, соответственно, через правильное создание промкта можно минимизировать галлюцинации модели. Собственно, ну, про галлюцинации ещё базово скажу. То есть почему галлюцинация есть, повторюсь, потому что лмка, как я уже сказал, она просто предсказывает следующее слово. Она ничего не знает, у неё нету ни морали, ни стыда, ничего. Она не будет стеснительно краснеть, когда будет вам врать. Она просто будет генерировать наиболее следующий подходящий э какой-то токен сшлово. Вот и всё. То есть она условно как такой патологический врун, который что-то знает, что-то не знает, он вам постоянно говорит, а что он врёт, а что он отвечает, вы не знаете. Через правильное задание промта вы можете явно модели подсказывать, что ей не нужно, например, пытаться фантазировать, когда она чего-то не знает, а просто явно сказать: "Нет, я не знаю". Это не абсолютная понацессия. Повторюсь, полностью от галлюцинации не спасётесь. Э, но через промт качественно это можно делать.

Дальше, собственно, что у нас? Вы можете добавить в промт подсказку или недостающие данные для ответа. Собственно, тот самый контекст. Вы можете, ну, в принципе, это перекликается вот с первым пунктом, когда мы добавляем контекст или память в диалог. То есть вы можете в пром добавлять какую-то информацию, которая на основе которой модель будет вам генерировать ответ, ну или хотя бы брать эту информацию оттуда. Вот. Ну и, в принципе, вы можете явно говорить, что делать нельзя, какие-то чувствительные темы делать и так далее, какие-то запреты делать модели. То есть это тоже важно явно задавать ограничения и что делать модели нельзя.

По принципам, собственно, что у нас? То есть здесь нет смысла сейчас говорить полностью про промнженерию. Там много различных есть приёмов, и это целые занятия можно посвятить принципам промт инженеринга. Я базово пробегусь, что, ну, как бы, делая раз, делая два, что нужно делать, и покажу примеры. То есть всегда нужно задавать максимально точное и лаконичное описание задачи. То есть помним о компромиссе между размером контекста и тем, что то есть нам надо попытаться максимально точно в сжатые количество символов описать задачу. Чем точнее мы это сделаем и чем менее распывчато это будет, тем лучше. Определяем контекст, соответственно. То есть мы чётко должны модели поставить в какие-то рамки, потому что модель ничего об этих рамках не знает. Она может, в принципе, если ей не указать, она будет будет как просто как свободный художник пытаться вам что-то нагенерить. Соответственно, задаём модели роль. То есть это практически все серьёзные промты, они всегда это используют. То есть в модели явно говорится в начале, что ты там помощник директора, там ты там или ты системный аналитик, там ты DBA инженер, ты опытный devops. То есть модель должна чётко понимать, в рамках какой доменной области она сейчас работает, и как бы и чтобы это был качественный ответ. Определять ей, что делать нельзя. И отдельная история обработка каких-то ошибок, потому что модель пытаться будет, во-первых, фантазировать, если чего-то не знает. Обычно сразу чатку говорят в промпте, что если не знаешь, то так и скажи: "Нет". Типа не придумывай или там, ну или там дополнительные какие-то истории. Сейчас посмотрим на практике. А определяется формат выходных данных. Это прямо обязательно, если вам не нужен просто текстовый ответ, а в работе часто вам нужен не текстовый ответ, а что-то структурное. Хотите отправлять email, например, на основе результата этой модели, она вам должна сгенерить какую-нибудь там HTML-разметку. Хотите там, не знаю, это там в Маркдауне получать, явно напишите, что нужно в в Маркдауне отдать. Хотите это в Jсоне получить ответ, определите структуру, ну и так далее. А добавляете в промт те знания, которыми модель не может в принципе обладать. То есть это либо что-то такое специфичное для этой задачи, либо просто какая-то информация, которая, ну, сейчас вот произошла. Не знаю, если вам в выходящем запросе нужно знать там, не знаю, у чтобы модель знала погоду в Краснодаре или в Москве сегодня, то лучше это нужно добавить в промт, иначе модель просто здесь запнётся, потому что она не может ничего знать физически о событиях, которые произошли после того, как модель обучили. Вот. Ну и отдельная история, опять же, если вы явно хотите прослеживать цепочку рассуждений, вы явно модели говорите, что там рассуждай последовательно, каждый свой шаг озвучивай и так далее. Ну каких-то логических таких сложных историй, когда там надо проследить, как модель там ээ шаг за шагом распутывает какую-то логическую задачу. Наиболее частая история вот именно рассуждение явно указывать.

Если говорить про примеры хороших промтов, они как вариант на экране, это не претендует на супер какие-то промты, но если ваш промт хотя бы в принципе базово не похож вот на что-то такое, то, скорее всего, он у вас плохой. Э потому что вы явно должны вот всё вышеперечисленное или, ну, по большей части использовать. Хотите там SQL получить, чётко описываете таблицы, колонки, ээ, хотите явно, что запрос должен быть под диалектом MySQL, проверить запрос на ошибки и так далее. То есть модель может галлюцинировать, да, дать вам неверный SQL. Вы явно указываете, что проверь ещё свой же запрос. То есть есть различные, конечно, техники. Можно доверить это дело другой модели, чтобы она перепроверила за первой, но, в общем, как минимум базово попробовать, чтобы модель сама же проверила свой результат, тоже неплохо. модель гораздо лучше так критик, чем фантазёр. То есть она фонафантазировать может всё что угодно, но если ей же этой модели подсунуть её фантазии, она спокойно явно укажет на какие-то ошибки, что это невалидный, например, SQL и так далее. То есть это как бы как примеры хороших промтов. Вот про промты можно говорить ещё много, но у нас времени мало, и мы так уже задержались, поэтому, то есть, думаю, с промтингом понятно. Это техники, которые вы можете использовать и как в работе с теми же популярными чатботами, которые в облаках везде есть. Так они нам потребуются и вот при проектировании и агентов.

Собственно, теперь, что такое и агент? Я уже говорил. То есть, если промтингом мы решали вопросы, вот сейчас перемотаю на минусы, какие у нас здесь были, то есть у нас вот были минусы и проблемы промтингом. Мы решали вот, например, пункт номер два, то есть что ответ модели не такой, какой у нас нам нравится. Мы решали его вот с помощью правильных промтов. Ээ частично мы решали пункт номер три, например, ээ, э, который в части того, чтобы через промт дать модели информацию о том, о чём она не может знать дополнительно. То есть это тоже нормально. Мы можем явно там, я уже сказал, в промкте внизу где-нибудь там дать информацию, модель на основе этого будет пытаться ответ. Вот. Остальные минусы промтинг особо не решает, то есть и особенно он не решает. Вот первый пункт - это автоматизацию, интеграции и ручные взаимодействия. И эту историю решают как раз-таки и агенты.

А, то есть перематываем опять на агент. Собственно, что такое? То есть иагент - это полноценная автономная программная система. Да, в основе этой системы та же самая языковая модель, но она умеет автономно и проактивно работать с использованием этой большой языковой модели под капотом, способна решать многошаговые сложные задачи и при этом взаимодействовать ещё с внешним миром с помощью некоторого набора инструментов, которые вы этому и агенту предоставите. Ну и, собственно, самой LLM. То есть здесь уже есть ээ помимо автономности, то есть она может работать как по расписанию, так непрерывно, постоянно по по событию запускаться и так далее. И она ещё может вызывать инструменты какие-то, то есть может пойти в поисковую систему, может вызвать опийку джиры, может вызвать опиайку там конфлюенса, может обратиться Google диску, вычитать оттуда файлы и так далее, и так далее. То есть это очень важная история, что она может работать с инструментами, которые мы ей дали явно. Ну и косвенно одним из инструментов может быть вызов других и агентов. То есть из- агентов можно строить целые большие разренные цепочки, чтобы они по сути получается целые такие графы взаимодействия агентов. То есть он может не только инструмент вызвать внешний, но и другого агента вызвать и передать ему какую-то задачу ну там дальше. То есть по сути получается как полноценная такая разрелённая система сотрудников, каждый из которых отвечает за какую-то свою задачку.

То есть какие проблемы это решает? В основном это проблема автоматизации и интеграции. То есть то то, что в лоб делать с обычными диалоговыми системами нельзя, агенты делают на ура. То есть он работает автономно, работает проактивно. Мы настроили как-то способ его запуска и поехали. Интеграции, повторюсь, он может всё, что угодно делать в зависимости от того, что мы ему дадим. Чаще всего это вызовы внешних API, это отправка сообщений, запросы к внешним базам данных, ээ, ээ, и так далее, и так далее. То есть здесь прямо широкий спектр задач, который открывается, который можно этим решать. Ну, думаю, вы сами там можете придумать для своих сценариев. Аэ, гибкость, ээ, повторюсь, что агенты можно выстраивать в цепочке. То есть, если, например, для конкретного запроса к диалоговой системе там очень решает узкий контекст и строго сформулированы, чтобы модель могла ответить, э, чётко, то с агентами мы можем получить некоторую гибкость, выстраивая цепочки из разных агентов. Этот агент хорошо отвечает в этой доменной области. Этот агент, например, он функцию там системного аналитика выполняет. Второй агент выполняет функции, например, там DBA. он больше разбирается там и умеет работать с инструментами там ээ с базами данных. А это условный агент, это DevOps, он хорошо работает с ICD инструментами, и они могут друг с другом коммуницировать. То есть за счёт этого можно достичь гибкость путём того, что мы очень предметные области узкие, назначаем определённым агентом, и агент не пытается сразу быть мастером на все руки. Собственно, собственно, то, что и не умеет как раз-таки делать сразу хорошо в одном запросе LLM модель, а агенты за счёт распределения функциональностей, они это делать вполне себе неплохо справляются. Ну и, соответственно, история вытекает, это специализация.

Вот. И что ещё агент добавляют сюда? Это даже не столько агенты, сколько фреймворки, которые строят вам агент, добавляют. Это память. Я уже говорил, что сами по себе языковые модели из коробки памяти не имеют. Вот. И её нужно как-то явно пытаться туда довести. Вот, собственно, обычно все фреймворки, которые позволяют работать вам и проектировать агенты, они сразу вам как функциональность добавляют память в различных вариациях: короткосрочную, долгосрочную, глобальную память. Вот её тоже обязательно нужно учитывать, потому что без памяти и Ллэмка плохо работает, и агенты вообще почти не работают никак.

Архитектурно можно представить это вот как-то так. То есть у нас есть некоторый пользовательский запрос, то есть это промт, он взаимодействует с агентом как целым. Э, что у нас здесь есть? Понятно, что основная история - это LLM. LLM в рамках агента, она занимается тем, что она планирует все шаги, которые нужно сделать. То есть ЛМ знает о агенте, она знает, какие у него есть инструменты, и она может задачу входящую разбить на шаги, попытаться или в один шаг её сделать, или в несколько шагов её сделать. Так или иначе понимает, какие инструменты нужно использовать, какие не нужно использовать. Может, нужно вызвать другого агента какого-то. Это всё лмка может понять. Соответственно, это основная прямо такая часть. Это, по сути, мозг э агента. Дальше идут, собственно, те самые инструменты. Это тулзы. Это непосредственно те самые там интеграция с жирой, это интеграция там с Google диском, это интеграция с конфлюенсом, это интеграция там с почтой, это интеграция с поисковиками и так далее, и так далее. Это, можно сказать, это руки ээ агента. То есть лмка говорит, что делать. Она разбивает задачу на шаги, на последовательность шагов, на вызовы этих самых тулзов, надо ли их вызывать или не надо, и они вызываются в той очерёдности, какую там LLM придумала, то есть. Но это всё равно руки, и она добавляет ту самую, собственно, интерактивность агентом. Понятно, что есть ещё и память отдельно. Обычно это либо какая-то просто память в оперативке бывает там какая-нибудь там хэшмапа. Это может быть долгосрочная память в какой-нибудь специализированной БД типа Редиса. Это может быть прямо память полноценно в Постгресе. Там могут быть специфичные хранилища вроде векторных. Мы сегодня про них говорить не будем. Это прямо отдельная тема, что это такое. Но мы сегодня объективно не сможем об этом поговорить. Так или иначе, память у агента тоже должна быть, потому что агент он циклически обрабатывает ваши запросы. Он должен предоставлять э модели память о том, что было на предыдущем шаге, что было при предыдущем запросе и так далее, и так далее. Алмка, повторюсь, сама этого ничего не помнит. Ну и шаблон запроса. То есть мы должны явно объяснить агенту, кем он является, какие у него есть инструменты и что он может делать, что он не может делать. Это тот самый системный промт, который добавляться будет ко всем запросам к Ллэмки, чтобы она понимала, что кем она является, какую функцию она выполняет, что это вот агент конкретно выполняющий там, не знаю, функции там условно системного аналитика и что у него есть инструмент вызовать жиры. вызова, там, отправки почты и так далее. И больше других инструментов нет. То есть, после template - это ээ шаблон общего такого системного запроса к модели, который ограничивает ей рамки. И он не незаметно для вас добавляется ко всем пользовательским запросам, которые вы вот в этот агент посылаете, чтобы модель в рамках каждого запроса получала не сам только ваш запрос, но ещё получала, ну, набор, скажем так, базовых правил постоянно и их не забывала. Если в общем говорить, это вот, в принципе, вся архитектура агента и всё базово. То есть архитектуру именно под капотом агентов великое множество. Собственно, не так давно видел как раз занятия на эту тему на курсе я и архитектора. То есть там целое занятие прямо посвящённое различным архитектурным паттернам внутри агентов. То есть примитивно это может выглядеть примерно вот так. То есть мы задаём какой-то вопрос, моделька сначала включается в действие, она планирует шаги, какие надо сделать. То есть просто состаётся, по сути, набор итераций, какие надо сделать. После этого эти итеративно эти задачи поступают опять же в ээ к к этому же агенту и к этой же возможно ЛМК. Она вызывает какие-то внешние инструменты, которые нужно на этих шагах сделать или не надо. И каждый раз после каждого шага оценивает, а выполнена конечная задача. Если выполнена, то всё, мы отдаём ответ пользователю. Если нет, не выполнено, мы можем перепланировать входящий запрос, ну, изначальный запрос, список тасок и продолжить дальше делать. Это, собственно, называется план план подход. Ну, их там великое множество этих архитектурных подходов для проектирования. Не обязательно так всегда делать надо. Это один из базовых таких самых, ну, частых таких итеративных подходов к работе агента. Но в общем случае агент может и по-другому работать. Повторюсь, важно, что есть модель, она знает, что надо делать, потому что знает изначальный запрос пользователя, знает, какие у неё есть инструменты, и может этими инструментами пользоваться, чтобы достичь цели.

Теперь вопрос, как же эти агенты могут помочь аналитику? Основная основной вектор здесь, повторюсь, в автоматизации, то есть и в интеграциях, то есть то, что мы раньше делали с помощью чатботов, ээ, но пытались запихнуть в запрос, э, к этому чатботу, например, там нюансы контекста, весь текст задачи и так далее. Здесь уже и и не всегда это у нас получалось, например, потому что весь конфлюнс, повторюсь, вы не запихнёте в входящий пром чатботу. Здесь за счёт интеграций вы можете добавить себе вариативности к этим же задачам за счёт того, что можете добавить опишку по обращению, например, к жире, к конфлюенсу, там, куда-то ещё. И модель, когда будет понимать, что у неё знаний нету, будет обращаться по этой опишке, например, или выполнять поиск там или идти в хранилище, какие-то файлики читать их содержимое, если это явно следует. То есть, условно, вы здесь можете очень сильно расширить спектр решаемых задач. За счёт того, что вы модельки своей добавляете по сути палочку уручалочку в виде пойди туда, возьми оттуда информацию, если тебе чего-то не хватает. Это по сути такая же история, да, не автоматизированная, но уже есть какие-то интеграции.

Следующая история, что аналитику это обязательно может помочь, да, и в принципе и архитектору. Я сейчас как раз в рамках своей работы делаю тоже архитектурного такого же агента. Это автоматизация. То есть здесь нет необходимости ээ в агентах запускать это всё руками. То есть да, конечно, могут быть агенты, которые запускаются по требованию, это частый сценарий, но большинство агентов могут работать автономно. Они могут запускаться по расписанию, запускаться по возникновению определённых событий, по достижению каких-то там лимитов. Например, у вас там накапало 100 сообщений в Телеграме, в каком-то канале вашем там с какими-то уведомлениями о сбоях, например, и после 100 сообщений, например, срабатывает модель этот агент, он самзирует, например, всю информацию и засылает её вам в виде самари, например, или какой-то другой там обработку делает. Как бы здесь можно делать именно автоматизацию, и это очень прямо важно, потому что, ну, безагентный подход не подразумевает такую автоматизацию.

Ну и опять же, следовательно, следуя из функциональности интеграций, теперь вы можете получать готовые артефакты, а не делать их сами. То есть, если когда мы работаем с чатботом классическим, он нам ответил в чате и мы взяли эту информацию, понесли куда-то сами создавать конечный артефакт, то, э, с иагентом мы можем доверить создание конечных артефактов ээ непосредственно агенту. Хотите на выходе получить задачу в жире, а не текстовое просто сообщение в диалоговой системе, не вопрос. Добавляете интеграцию жира и модель, когда понимаешь, что она закончила свою работу, она может поставить на основании своих там результатов задачу в жире. А хотите напоминания в календаре, хотите встречу в почту отправить, хотите отправить просто email, хотите сразу страничку в конфлюенсе завести, не проблема. То есть здесь спектр широкий, то есть как бы и специально не было цели какие-то конкретные сценарии прямо написать, потому что у всех абсолютно разные, скажем так, направления деятельности, которые можно автоматизировать с помощью и агентов. Но простор очень широкий. То есть, в принципе, за счёт того, что теперь модели могут вызывать внешние функции, в том числе апи внешние, вы можете на выходе получать вполне себе готовые артефакты. Сообщения в Телеграме можете получать записи в БДЭшке можете получать всё, что угодно. В принципе, в разумных пределах можно отдать уже на откуп и агенту.

А, ну и, собственно, что при этом нужно помнить, что это не волшебная палочка какая-то, чудес не бывает. Есть определённые ограничения здесь. самые основные, постарался сфокусироваться на них- это то, что всё равно нельзя доверять результатам работы и беспрекословно их нужно проверять и нельзя. И когда я говорю, что там создавать задачу в жире, это значит, что это не задача какая-то, которая безукоснительно будет выполняться или ставиться на ваших подчинённых. В идеале бы, чтобы эта задача ставилась на вас. Например, вы её проверяли и если всё хорошо, только после этого переводили на реального, ответственного, например, там и так далее, и так далее. Если это отправка имейлов, то, возможно, это отправка имейлов вам на почту, чтобы вы могли их перепроверить, их содержимое, а не сразу директору отправляли и так далее, и так далее. То есть, ну, то есть проверять ээ по-прежнему работу и надо. Нельзя её воспринимать за истину последней инстанции и давать ей какие-то расширенные полномочия. В идеале, конечно, пытаться иишку же привести на, ну, на службу проверки. Повторюсь, что и модели они хорошо работают как рецензенты, именно как критиковать они умеют очень неплохо. Можно интеративно это использовать. То есть в идеале не обязательно нужно самим всё проверять, иначе потому что, ну, теряется много мм пользы. То есть, если реально абсолютно всё, что генерируют вам агенты или, например, диалоговая система, всё скурприёзно проверять самостоятельно, то вроде как может получиться, что как будто проще работу сделать самому. То есть здесь, конечно, тоже нужно использовать функциональность и базово давать проверку ей.

и так далее, но всё равно не пытайтесь сделать так, чтобы критические действия выполняли и агенты, или, например, там не не пытайтесь пересылать какую-то полученную от лэмки модель кому-то, кому это важно, без проверки.

И вторая история — это то, что очень важно понимать, что почти всё, ну, нужно всегда понимать, что информация какая-то бывает конфиденциальной, чувствительной, приватной и так далее. И использовать облачные сервисы здесь очень осторожно нужно. То есть это касается и облачных LLM.

А мы знаем, что это, ну, достаточно дорогая история для эксплуатации. То есть и самой частой, наверное, такой проблемой с внедрением и и агентов, и вообще лэмок в корпоративной деятельности является то, что просто там, где они могут принести пользу, например, вот в тех же сценариях там работы с базой знаний корпоративных, там с внутренними системами компаний, вроде там Джиры, Конфлюенса и так далее, что банально, вы не можете предоставить облачным системам доступ к к этим данным, потому что это, ну, чувствительные данные, они могут утечь.

Поэтому тут для таких сценариев всегда нужно стараться ставить модель у себя в инфраструктуре, разворачивать, да, выделять на это ресурсы, тратить на это деньги. Системному аналитику это зачастую не по карману и вообще не в его полномочиях. Но если у вас в компании есть такая инфраструктура, то это нужно использовать, а главное обязательно это учитывать. Не нужно выкачивать свой Конфлюенс, приходить его Чат GPT скармливать результаты его деятельности, того, что вы выгрузили, чтобы он дал вам ответ. Это не есть хорошо. Нужно чётко понимать, что есть вот какие-то такие казуальные запросы, которые вам могут облачные системы помочь, но грузить туда конфиденциальную корпоративную информацию или какие-то персональные данные или что-то ещё не надо. И это нужно как-то всегда обыгрывать. Это отдельная история. Какие решения для этого есть?

А вот, собственно, это всё по материалу. В принципе, дальше мы сейчас перейдём на демо. Какие-то вопросы, если у вас есть, пишите в чат. По материалу и дальше, да, если по демо они дальше тоже будут у вас. А я постараюсь на них ответить уже в конце, когда демка закончится.

Пока я вижу только вопрос от Надежды: как реализуется доступ агента к данным Канфы или в Жиру при условии, что это в закрытом контуре компании? Ну как, если у вас модель или агент не находится в в закрытом контуре компании, конечно, никак. Вам нужно этот открывать этот как-то явно доступ. Вот, вот об этом я, собственно, и говорил, что если контур закрыт, вопрос, как он закрыт, что это VPN, что это, какое-то микросегментирование там у вас или что-то ещё. То есть вот если у вас действительно вопрос закрытости контура, то, скорее всего, вам нужно притащить этот этого агента и всю инфраструктуру с лэмкой вам внутрь контура и всё. В принципе, обычно это делается так. Конечно, можно попытаться дать доступ агенту через VPN, например, специально выделить, но, скорее всего, останут вопросы: "А а что делать, если данные эти утекут?" У вас же закрытый контур не просто так, скорее всего. Значит, там есть что-то ценное. Давать доступ и инструментам сторонних компаний в ваш защищённый контур, нехорошо. Поэтому, скорее всего, вы упрётесь в то, что если у вас действительно такая история есть, давайте ставьте себе и лэмку, всю инфраструктуру для работы с этим агентом, и она будет работать у вас внутри закрытого контура. И всё. Обычно это делается именно так.

А, собственно, переходим к демке. А-а, сейчас я переключусь сюда. То есть, в принципе, такое небольшое предусловие. Это, чтобы создавать агентов, есть много разных подходов. Самый простой подход — это, конечно, взять взять и написать весь код на каком-то языке программирования. И так делают обычно, когда пишут большие компании себе какое-то костомное решение, подходящее под их сценарий, очень производительно и так далее. Это, конечно, это, конечно, не наш путь. э-э уж точно не для системного аналитика.

Поэтому более простой путь для создания агента — это использование фреймворков, ээ, которые тоже подразумевают написание кода. То есть здесь уже у вас есть какой-то базовый набор функций. И самый популярный фреймворк такого рода — это lph/langchain. Может, кто-то из вас слышал про него. Там это, по сути, набор библиотек, в которых вы всё равно тоже кодом пишите код вашего агента и что он должен делать, как взаимодействовать с какими-то инструментами. Но здесь у вас уже есть готовые, по сути, библиотечные функции и так далее, которые позволяют вам, по сути, строить вот эти самые графы жизни агента. Это тоже, я считаю, не путь сегодняшнего занятия. То есть это мы вот на курсе там и архитектора смотрим на примере лонграфа, как с этим работать.

Есть третий, самый простой путь. Это как раз такой казуальный путь. Он подходит как раз-таки не самым искушённым в глубокой разработке ээ специалистам. И в принципе тем, кто хочет попробовать базово, а а зайдёт, не зайдёт, прототипы агентов делать прекрасно этим путём, чтобы не тратить время понять, хорошая идея, нехорошая. Это подход ээ, собственно, код решений визуальных, которые позволяют вам строить графы взаимодействия внутри агента с внешним миром и внутри, ээ, с помощью вот таких вот юайных инструментов. Самый популярный инструмент этого класса — это N810N собственно или N8N. Может, опять же, кто-то слышал. Вот это облачное решение, популярное, позволяющее вот в визуальном интерфейсе строить, вот мы сейчас как раз смотрим на него, строить агентов своих и публиковать их и так далее и работать с ними. Есть, собственно, ещё относительно популярный, то есть, ну, в общем, NA, наверное, самый известный сейчас инструмент именно такой с очень низким порогом входа.

А, понятное дело, что есть облачная версия, за неё надо платить, там есть четырнадцатидневный триал, все нюансы в плане локальности и безопасности, потому что эти данные хранятся тоже где-то в облаке, тоже есть. Поэтому есть вариант NN поставить локально, что я, собственно, и сделал. Видите, у меня есть local host порт 55678. Я его развернул в докере. Разворачивается буквально в одну строку. Если говорить про базовое развёртывание, если хотите нормально прямо развернуть, то лучше разворачивать doкеer compмзом. Есть вариант поставить его с помощью НПМА, но я считаю, это не очень есть хорошо и изоляции нету. В общем, не нравится мне вариант с НПМом, поэтому я вам рекомендую ставьте его с помощью докера или докер композа.

Поэтому вот у нас как вводная история, это N8N, N8N, как бы, собственно, вот N8N название. А он позволяет в визуальном интерфейсе нам создавать агентов и автоматизации, по сути, по взаимодействию агентов друг с другом. То есть можно целые разённые сетки агентов строить. Мы сейчас посмотрим на примере, как вообще с этим работать.

Аа нужно использовать какую-то, понятно, что какую-то внешнюю лмку использовать. В состав NN не входит какая-то лмка. То есть вы должны использовать либо чат GPTшный Openпи, собственно, с ну взаимодействовать с ним, либо там любую другую, но они стоят все денег и плюс есть проблемы с оплатой их. Понимаете, что сейчас условно напрямую оплачивать там Open AI без там зарубежных карт и так далее не получается. Поэтому в рамках нашей демки я буду использовать в качестве lм-модели сбербанковскую гигачат. То есть у меня вот в соседней вкладке открыт студио Гигачата, собственно, с бесплатным тарифом, на котором почти миллион токенов даётся для работы. Соответственно, можно попробовать это всё бесплатно. Там традиционная история: зарегистрироваться в кабинете гигачата, получить APIK для взаимодействия с моделью. То есть, повторюсь, сам по себе N — это workflow проектировщик. То есть он позволяет вам сделать workflow. Сама лмка нужна из внешнего мира, и вам как-то её нужно вызывать через AP. Ну, как бы поэтому озаботиться этим надо. У меня, повторюсь, это Сберовское решение, чтобы бесплатно просто это всё показать без каких-то приседаний. В реальных сценариях это возможно будет ваша внутренняя модель какая-нибудь у вас в инфраструктуре, которую вы развернули и которая крутится.

А теперь начнём, собственно. А, ну и понятно, что локально установить его нужно. Начнём. То есть всё, что касается работы в N всех workflow, они все начинаются с так называемого триггера. То есть когда вы начинаете проектировать, у вас выбираете, что будет триггерить этот workflow. Тут есть самые разные варианты. Вы можете триггерить его вручную, это как бы, ну, понятно, что неудобно, но возможно есть. По расписанию какой-то ивент может происходить ивентом может быть всё, что угодно, различное количество интеграций. Может быть, например, там из Телеграма, например, сообщение. Вот из Телеграма, если настроите интеграцию с каким-нибудь ботом, сообщение в Telegram может триггерить ваш workflow. В принципе, у меня так много чего работает. Я я просто принципиально не буду показывать интеграцию с Телеграмом. Там слишком много придётся светить приватной информации, показывать Telegram ботов и креды. Не хочется это делать, поэтому я буду показывать абстрактно. На, э, я выберу вариант, чат системы, когда я буду писать в чат сообщение и сообщение, приходящее в чат, будет её тригерить, собственно. Ну, а в принципе тут много разных естьпхуш, расписание, другой workflлоow может вызывать старт этого workкфлоу, как бы вот я выбираю простой вариант именно для демонстрации. Повторюсь, это не для реального использования вами. Вы можете выбрать в реальном проекте тот способ запуска пайплайна, который вам нужен. Повторюсь, самые частое — это вот какие-то события внешних приложениях, либо расписание.

А вот я выбираю как бы старт по сообщению. Ну и в принципе дальше могу в принципе тестировать его. Ну пока тестировать нечего. То есть я вот могу здесь написать намер вот тестирование. Я могу написать привет, отправить сообщение здесь. И, собственно, всё отработало хорошо. Но дальше ничего не произошло. Понятно, что это просто у меня пока кубик с сообщением из чата.

Теперь что я могу добавить? Я могу добавить следом какую-то самую простейшую логику. Я, например, могу добавить, у меня уже стоит интеграция с гигачатом, потому что из коробки вм она не идёт. Я её поставил отдельно. Аэ, вот я её сейчас сразу найду. Вот у меня гигачат AI есть. Собственно, я могу вот добавить его в workflow как обработчик запроса. Вот у меня открывается настройка, собственно, моей модели. То есть здесь всё очень просто. У меня вот есть от предыдущего этапа данные, то есть есть название действия отправить, есть session ID, мне они не интересны. Я хочу на вход моему гигачату подавать сообщение chat input. Я могу его просто перетащить здесь в поле промот, и это будет переменная, которая передаётся на вход моей модели. То есть Jonathat Input будет передаваться сюда. То есть привет будет передаваться для этого конкретного случая. Понятно, что нужно настроить ещё криншлы. То есть у меня уже настроены криншлы гигачату. Повторюсь, я в студии здесь зарегистрировался, получил токен, ээ, получил AP, то есть это у меня всё настроено. Вам это тоже нужно сделать. Понятно, что вызвать модель нужно по какому-то апи. А вот и можно выбрать, какие модели доступны. То есть я сейчас самую дешёвую, самую простую модель использую просто гигачат. Подаю ей на вход ээ то, что получил ээ из чата, собственно, и на этом всё. То есть можем дальше попытаться execute сделать. Вот я написал: "Привет". Мне модель ответила: "Привет, как настроение?" Собственно, ла-ла-ла-ла-ла-ла-ла. То есть можем это всё дело закрыть. То есть я теперь могу даже спросить её, например, ээ, что такое, что мы там из области системного анализа, например, что такое функциональные требования. Вот. И здесь всё как бы втем всё понятно. То есть отработал этот шаг, потом видели, выполнялся этот шаг, теперь он выполнился, получился ответ. Соответственно, что получилось в ответе? Тут в ответе получилось, что вот он целый большой текст. Можем даже посмотреть его вот на выходе здесь. Ээ модель ответила много функциональные требования — это описание условий, которыми должен удовлетворять продукт. Ла-ла-ла-ла-ла-лала. Вот вот большая партянка того, что мне ответила лмка. Что, ну вот я могу развернуть, в принципе, чтобы было более видно, что она ответила. Пока это режим отладки, понятное дело, ещё никуда не не выводится, но я хотя бы вижу в виде Джейсона, что мне модель отвечает. Это это ещё пока не ответ.

А что я могу сейчас добавить? Я могу пойти добавить, во-первых, куда отвечать. То есть я хочу всё-таки полноценный чат. Я хочу сделать респонс, чтобы мне это тоже отвечало в чат. А, собственно, здесь есть чат функция и send message я в ответ буду делать. То есть вот у меня есть responsс, я этот спонс тоже перетаскиваю. Что теперь меessдж будет? Вот. И выполняю Execute Step. Мне говорят, что нужно responsс mod поменять у триггерящего события. Сейчас пойдём это поменяем. Здесь вот есть respons в опциях. Вот field есть response mode. И надо указать, по-моему, вот этот вот. Там благо всё подробно описывается. Вот после этого можно протестить. То есть я могу, например, написать что-нибудь ещё новое. Теперь уже А ещё раз привет, например, как дела? Как дела? Отработает следующий этап и отработает вот этот этап. А, так, видимо, надо обновить, чтобы это всё нормально отработало, чтобы оно мне прямо в чат это всё переслало. Давайте ещё раз попробуем это всё сделать. то не всегда сразу делает как следует. Ну вот, собственно, теперь уже никаких джейсонов, теперь уже обычная чат переписка. Привет, как дела мне в ответ привет. Всё отлично, готов общаться, помогать с разными вопросами.

Теперь это это простейшая история работы с моделью. Это ещё не агент, это просто, по сути, мы пытаемся эмулировать работу с моделью как диалоговой системы. То есть здесь, что есть есть интересного? Во-первых, если я, например, сейчас напишу: "Меня зовут Денис". Модель мне ответит, что: "Привет, Денис, рада знакомству, чем займёмся". Но если я в следующему просто спрошу: "Как меня зовут, то что мне ответит модель? Она ничего знать про это не будет, потому что у неё памяти, повторюсь, явно нет. Твоё имя мне неизвестно, можно назвать его самостоятельно". Поэтому, собственно, к модели и здесь можно добавлять память. Собственно, памяти разное много. Пос можно монгоis. Я выберу самую простейшую inmemory память, пока у неё будет длина контекста пять сообщений последних. В принципе, это, конечно, маловато, но пойдёт. Вот. То есть и теперь уже у меня есть мемори, и я могу теперь написать, например, меня зовут Денис снова, чтобы она запомнила. модель ответила. Теперь, если я спрошу, как меня зовут, мне уже ответят, что тебя зовут Денис. Как бы вот всё, ээ, уже теперь память появилась. Это уже и для агентов тоже нужно. Хотя, опять же повторюсь, это ничего не агент.

Что ещё здесь интересного? Есть история с мы сейчас никак не работали с промтом. То есть я могу здесь добавить явно, например, добавить системные сообщения, системный промт и написать модели, что ты системный аналитик. А даже не знаю, опытный системный аналитик. Системный аналитик. А, отвечай. Развёр отвечай. развёр. Ну то а-а так что ещё, например, если какая-то информация тебе неизвестна, например, тебе неизвестно, а, а не фантазируй руй. Скажи прямо, например, что не знаешь. Ну, это как пример. Понятное дело, что это тоже такой очень совсем лайтовый промпт. Вот. И теперь как бы мы уже получаем другой ответ. То есть мы получаем информацию, что на данный момент у меня нет информации о твоём имени за пределами тех данных, которые ты сам предоставил. То есть модель уже так отвечает не очень уверенно. Она говорит: "Ты мне сам сказал, что тебя зовут Денис, я это помню. Но, в общем-то, я не могу быть уверенной в этой информации, потому что мы ей явно сказали, что у тебя этой информации нет. Прямо говорит, что ты не знаешь. То есть мы уже за счёт промта явно ей как-то подсказываем, что нужно как-то по-другому себя вести. Если мы спросим, например, не знаю, какая погода сейчас в Краснодаре, то, очевидно, нам она ответит, что, извините, я вообще не в курсе такой информации. То есть, то есть она скажет у меня, но при этом она теперь отвечает уже развёрнута, то есть она уже не укладывается в одно какое-то предложение. Ээ нет доступа к актуальным данным в реальном времени. Если нужно, пользуйтесь, пожалуйста, там соответствующими сервисами. То есть, в общем, это классический сценарий работы с моделью, но это ещё по-прежнему не и агент.

Мы это можем сейчас всё удалить и пойти, собственно, опять создать новый workflow, например. Также триггерить будем по сообщению в чате. А, а так пускай будет пока. Привет. А вот и теперь мы здесь добавим другой компонент. Уже мы добавим непосредственно есть компонент агент, который более комплексный компонент. И ему нужно будет, ну, сейчас посмотрим, как с ним дальше работать. Тут также ему нужно перетащить, что ему на вход мы передаём. Э, так, прот у нас, да, здесь есть. Тут сразу автоматом подтягивается уже из подключённого чата события. То есть здесь мы также можем добавлять системное сообщение. То есть мы также, например, напишем системное. Здесь уже есть сообщение по дефолту, что вы ассистент. Мы здесь напишем, не знаю, ты опытный системный аналитик. Пока напишем просто, чтобы время не тратить. Отвечай, например, раз. на вопрос развёрнуто. Ну, пока ограничимся этим. Повторюсь, это не очень хорошая история, но видите, модель не подключена никакая к агенту. К агенту отдельно ещё нужно подключать модель. То есть пока мы на этом эта завалились, теперь нужно у агента уже есть отдельно выход под чат-модель. Также есть мемори и есть ещё тулзы, о которых я говорил. Собственно, это инструменты, которыми агент может распоряжаться. То есть чат-модель мы также подключим гигачат. У меня здесь есть, собственно, тоже Gigчаat модель. Здесь в этом плане ничего не меняется. То есть я отдельно подключаю её. Также явно говорю, что выбирать модельгичат буду. И что у нас чата редл у меня уже пере есть, собственно, что у нас? И в общем, так, ну, больше перетягивать здесь нету. Здесь инпуты сразу все есть. Можно добавить различные другие опции, но это уже прямо тема отдельной настройки. Всё это дело закрываем.

А теперь, в принципе, можем попробовать вызвать. Теперь нам, собственно, отвечает обратно видить Jсоon в ответ: привет. Как бы привет и привет. Но опять же повторюсь, здесь это просто jсонина, потому что мы не добавили пока никакого вывода. Давайте опять добавим также, например, чат. А send message output, собственно, поедет сюда. А это закроем. Здесь также надо добавить responс mode, чтобы был корректный. Ну, и, собственно, давайте проверим это всё дело. Ну, правда, тут какая-то ещё абракадабра добавилась. Не знаю, кстати, от чего это просто, ну, там модель иногда бывает, это самое дешёвое любит этим спамить, но у меня просто токенов на дорогой модели сейчас нету. А вот понятно, что также надо добавить память. без памяти. Сейчас будет всё то же самая история, что будет совершенно непонятно, а кто, собственно, а ну кто я и какие, ну, варианты есть ответа мне. То есть теперь, собственно, память я добавил. И, в принципе, здесь самое интересное начинается, когда я пытаюсь добавить теперь инструменты. То есть теперь, что я могу хотеть сделать? Я могу хотеть, чтобы модель, например, могла взаимодействовать с внешним миром. Да, здесь количество разных инструментов в тулзах огромное количество. То есть здесь можно выбирать различные действия в приложениях. То есть вы экшенами можете там вызывать жиру. Ээ, например, можете там confluent хотя не хотя это конфлюuент, надо там отдельно ставить интеграцию с конфлюенсом. Как бы вариантов инструментов огромное количество. У меня есть, я хочу вызвать веб-поиск. У меня Tavли стоит. Это, собственно, ну, такой опичный веб-поиск дляишек. часто используется. По сути, это обычный компонент, который позволяет выполнить запрос на в через web модели как инструменту. То есть я я вот явно передаю ей, что в в запрос у меня query будет input от модели идти. Вот. И, собственно, здесь в остальном также криды у меня уже настроен, но это вам нужно будет настроить. Вот отдельно desриption тулы, конечно, обычно в нормальном рабочем сценарии нужно явно предоставлять руками для модели, но есть опция автоматического. Она чуть менее качественная, но работать тоже будет. Вот. В остальном какие-то опции для демонстрации я сейчас не буду включать.

А что ещё здесь надо? Единственное, по-моему, надо сессией. Тут немножечко аэ ээ контекст этот. Так, это пять. Вот. И в общем-то здесь это остальное всё-таки уже тюнинг идёт. И теперь, в принципе, что мы можем теперь? Ну, на на вопрос привет. Как видите, модель не вызывает поиск. Она прекрасно знает, что ответить мне на вопрос привет. Если же я сейчас явно спрошу, например, у модели, ну, давайте, не знаю, кто, я вот Формула-1 люблю, кто выиграл гран при Китая в 2026 году, то есть это вот было буквально недавно. Понятно, что модель об этом ничегошеньки не знает. Видите, здесь уже поехал поиск задействоваться. Агент пошёл в поиск. И он сейчас будет формировать свой ответ на основании тех данных, которые он получил уже в поиске. То есть и поехала история, то есть итоговый ответ в результате анализа доступных источников и так далее, и так далее. Понятно, что промт у меня сейчас неоптимальный, то есть я, может быть, хотел в другом формате получать ответы, но у меня не так много времени, чтобы вам всё показать. Но уже, видите, в принципе, работает внешний инструмент модели.

А в принципе, повторюсь, можно добавить тулзов разное количество. Может быть вызов простейшей функции по HTTP. Это может быть, ээ, например, отправка сообщения, например, через Gmail или просто рандомную поитовую систему. Э модель будет в зависимости от того, когда поймёшь, что ей нужно эту функцию вызывать, она будет её вызывать. А вы это можете через промт конфигурировать явно, говоря, какие тулзы есть у модели. В общем, систему можно делать различной степени разветлённости, поэтому для ваших задач, то есть, ну, в реальности, конечно, вы будете, скорее всего, не не способ триггера использовать такой, как чат. Вы будете использовать какие-нибудь сообщения из Телеграма, запуск по расписанию. как тулы вы будете использовать, скорее всего, интеграции с реальными сервисами вашей компании, возможно, там, не знаю, с каким-нибудь Google диском вашим личным, может быть, там жира и с чем-то ещё, с вашим почтовиком корпоративным. Но в рамках демонстрации это показать достаточно проблематично. Вашу инфраструктуру внутреннюю или мне мою рабочую я тоже показывать не особо хочу. А вот, но сама концепция не поменяется. Вы также будете вот с помощью этих кубиков проектировать агент. у которого будет какая-то лм-модель мозгом, у которого будет какая-то память, может быть, не такая простая, как здесь, а более сложная, там, постгрес, например, и так далее. И будет какие-то тузы.

Остаётся один вопрос: как этим всем пользоваться? Это пока инструмент разработчика. Вот здесь есть кнопочка публиковать. То есть мы можем опубликовать это, ну, сохранить, опубликовать именно эту версию, которая сейчас есть. Вот. После того, как мы её сохранили, нам нужно понимать, а как, собственно, по какой ссылке, ну, для того же чата получать доступ. Здесь у чата есть кнопочка make чат доступным публично. Я её включаю. Соответственно, у меня получается ссылка, по которой я могу обращаться к этому своему чату. А, и я могу теперь по ней обратиться. Аэ, так. А мне надо после этого ещё раз сохранить, потому что я ещё должен ещё раз сохранить, потому что эти изменения внесли изменения в проект. И видите, уже загорелась жёлтенькая, что сейчас не актуально сохранённая информация, поэтому оно ещё недоступно. Вот теперь, в общем, вот мой чат, ээ, который я опубликовал по сути свой workкlлоу. Теперь я могу также его спросить, ээ, там, привет, привет, кто ты? Он мне сейчас ответит что-то, что-то вроде, что он помощник системного аналитика или что там мы ему там задавали, какую информацию. О, а не, он он не знает, кто ты. Давайте ему всё-таки как-то научим его, кто ты. Потому что контекст мы так ты системный аналитик. Давайте там ты там системный аналитик, э, там, не знаю. Отвечай на вопрос. развёрнуто. Если не знаешь ответ на вопрос, ээ, воспользуйся поиском в интернете, например, вот как быто как вариант. Вот так. То есть сейчас он он воспринял вопрос: "Кто ты?" Как неизвестный ему вопрос, и пошёл искать это всё в интернет, потому что мы ему такую возможность дали. Вопрос: кто ты? Он не знал на него ответ. А так теперь давай с вами как тебя зовут. Ну, видимо, он сейчас пойдёт в интернет. Потому что моделька гигачатовская слабенькая. Видимо, судя по времени ответа, он опять пошёл в интернет. Ээ, а поэтому, ну, в принципе, ну, конечно, какие-то вопросы здесь, видите, сейчас нормально не отрабатывает история с идентификацией. он идентифицирует, что этот ответ он не знает и идёт в ну в поиск. Вот. Но, в принципе, наш пайплайн, он хоть и каличный, но опубликован и работает в таком виде.

А что как его можно оптимизировать? Конечно, нужно более качественно задать промт системный для самого агента. Ему более чётко надо дать понять, кто он, какие инструменты он может использовать. Не использовать автоматическую настройку тулзы, которая вот здесь есть сейчас автоматическая. Её лучше сделать руками. Ээ сделать лучше вход на запрос на вход не весь входной от модели, а какую-то её часть только в определённых сценариях. Ну а в общем, в остальном, в принципе, такой сценарий будет работать. Ну или, конечно, его сделать его более жизненным, что ли, добавить определённых реальных функций, которые вам нужны.

А так, в принципе, по демке это всё на сегодня. Я возвращаюсь к презентации. По вопросам. Единственный вопрос я вижу от Юрия. К каким MCP серверам можно подключиться из N8N? Да, ответ, в принципе, ко всем абсолютно MCP совместимым, потому что там MCPшный коннектор он дефолтный. Вы вы сможете подключиться к нему ко всем MCPшным серверам, которые доступны по сети. То есть, если вот как у меня, например, развёрнут локально N8N сейчас, то, конечно, я достучусь из него только туда, куда сетевая связанность позволяет. Если у вас облачный N8N, то, соответственно, он достучится только до тех MCP серверов, которые в публичном доступе есть. Поэтому с точки зрения взаимодействия, интеграции с ними принципиального вопросов нету, потому что вы можете к любому из них интегрироваться. Где есть? Сейчас вам покажу. Так, где тут у нас была история с добавлением? Собственно, можно, ну, MCP клиент, MCP сервер как триггер использовать, собственно, и и выступать MCP-клиентом. А вот вопрос только в сетевой связанности, поэтому тут нету какой-то, то есть все MCP совместимые сервера реализуют IP, который позволяет любому MCPшному клиенту общаться с ним. Главное, чтобы у вас была возможность туда там из вашего ВПНА или, наоборот, внутрь вашего ВПНА достучаться и так далее. А так, ну, собственно, вопросы вы можете задавать. Сегодня, честно говоря, их что-то маловато или настолько всё просто или наоборот настолько всё непонятно.

А я возвращаюсь к презентации. У нас тут немножечко осталось материала про курс, собственно, из-за которого мы сегодня здесь собрались. Ээ а дальше будем уже прощаться. Собственно, мы вас приглашаем на курс, который стартует через 4 дня уже. Ээ ну, в принципе, по стоимости информацию вы, думаю, так, если интересуетесь курсом, знаете. Про дате старта я уже говорил, длительность и так далее. А-а, что ещё интересного мы не прошли? Собственно, команда курса, она на лендинге у нас есть. Я сейчас не буду переключаться на сам сайт, хотя, наверное, имеет смысл. Всё-таки программу курса лучше смотреть на сайте. Аа, а что есть, чтобы, ну, скажем так, перед каждым курсом у нас есть вступительное тестирование, которое, ну, позволяет определить, подходите ли вы по базовым навыкам для курса. Вот опять же, я думаю, что если вы на открытом занятии присутствуете, я думаю, вы его уже проходили, на лендинге были. Но в общем случае, конечно, я всем рекомендую вся проходить тестирование, чтобы не оказаться на курсе, который, например, вам ещё рановат.

А по программе курса у нас там несколько блоков есть. Ээ они, ну, разделены в основном в части компетенции. То есть часть блоков посвящена менеджменту такой как первый. Это история про софтскилы, про управление командой. занятий там было 10, сейчас уже 11. Э, это история про уже дальше второй блок — это про паттерны проектирования. По сути, это средств такой знаний между серьёзным сеньорным аналитиком и начинающим архитектором. Так. Solution история про проектирование систем и подсистем данных. Какие есть принципы? То есть вот как раз в этих двух блоках я наибольшее участие принимаю. Так, как это наибольшие мои компетенции. История про документирование, собственно, неотъемлемая часть работы системного аналитика и проект, который вы выполняете уже сами и потом защищаете в конце. Чтобы успешно закончить курс, нужно, соответственно, защитить проект успешно. Тогда вы сможете получить все там документы об окончании курса, повышении квалификации и прочие прочие документы. А у Отуса есть такая возможность их давать, потому что есть аккредитация, как у, знаю, компании, оказывающие услуги образования.

А по преподавателям, собственно, у нас преподавателей достаточно много на курсе. Не все здесь отображены на странице. Собственно, меня здесь тоже нету. Надо будет узнать, почему до сих пор, повторюсь, вы встретитесь не обязательно со всеми на курсе, но встретитесь с теми, кто конкретно попадут к вам на поток по расписанию и с теми, кто будет непосредственно компетентен в тех темах, которые вы будете проходить. То есть нет такого, что там из потока в поток, например, один и тот же человек ведёт одно и то же занятие 100%. Есть несколько специалистов, кто могут подхватить это. У кого-то расписание не позволяют, у кого-то там отпуска, графики и так далее. А вот, ну, открытые уроки у нас уже к курсу все прошли, то есть вы можете только посмотреть записи открытых уроков, которые были до этого. Сегодня завершающий открытый урок, дальше только курс уже стартует, поэтому тут могу порекомендовать только посмотреть другие открытые занятия, если они вам их тема вам интересна.

А-а, собственно, всё. На этом точно всё. Мм, я могу ещё вас попросить оставить в конце, а-а, ээ, пройти опрос, ээ, по ссылке, которую я сейчас скину в чат. А-а, вот она. Собственно, это очень важно для нашего для нашей команды курса, э, с теми, кто работает над продажами курса и над его наполнением. Вот.

И я вижу ещё вопрос есть от Алексея. Так, в итоге для чего и как правило используют и системные аналитики. Схемы рисовать, разделы ПТЗ, функции, требования генерить. Э, ну, повторюсь, каждый решает сам, для чего использовать. Сейчас время такое, что, ну, нету бест-практисов каких-то. То есть сейчас это всё активно осваивается. В каждой компании, ээ, ну, те, которые пытаются быть на остре, ээ, пытаются автоматизировать какой-то, то есть пласт своей работы. То есть нету компании, я не видел, а я взаимодействую с многими в индустрии, я не видел каких-то компаний, где полностью уже взяли и покрыли ишкой всю работу системного аналитика и говорят: "Вот это вот эталон". Все сейчас пытаются взять и выделить наиболее рутинные операции, подверженные автоматизации. Каких операций у вас больше, каких у вас меньше, это вопрос уже к вашей, потому что обычно садятся, исследуют, чем вот вы занимаетесь ежедневно. Если у вас очень всё сильно завязано на, не знаю, на то, что вы создаёте 20 20 там пять задач в жире в день, то логично взять и агент, и который бы хотя бы базово за вас эти задачи создавал, да, по потом вы будете делать ревью, но он будет за вас их делать. Если вы, например, постоянно пытаетесь перелопатить содержимое вашего конфлюенса, это прямая дорога, то чтобы интегрировать с конфлюенсом вашего иагента, чтобы он сам мог его проиндексировать и использовать как базу знаний для того, чтобы, например, сразу давать вам ответи по базе знаний конфлюнса. Это, например, не знаю, как это у системных аналитиков, но как я как архитектор вот часто этой историей пользуюсь. А то есть и так, собственно, далее. То есть, если у вас, например, вот какая-нибудь история, что вы сидите на поддержке и у вас очень много занимает обработка сообщений, там, например, в каком-нибудь чате Телеграма, куда алерты прилетают, то сделать агента, который будет получать эти все алерты, как-то их саморизировать и вам присылать выжимку раз в день, например. Это тоже ваш путь. То есть, в общем, здесь нету серебряной пули. Здесь есть история про то, что, э, и агенты — это универсальный инструмент, который позволяет вам автоматизировать рутину, которая у вас в работе есть, ну, в определённом таком вот диапазоне там функциональности, о котором мы сегодня говорили. Э какая у вас часть работы наиболее рутинна и занимает больше всего времени? Это вы как потенциальный Team Elлит, я думаю, можете проанализировать сами. И только вы это можете сделать, потому что нету кто-то какого-то там волшебника, который придёт вам и скажет: "А, сделайте вот это". Поэтому я как бы всё сегодняшнее занятие веду именно к тому, что э вам, ну, вот полезно понимать, как эти инструменты можно использовать, но как вы будете их пользовать? То есть в каких задачах можете решить только вы сами. Только перечислить какие-то такие примеры, которые видел на практике, что их люди делают, не более того. Вот. Вот, надеюсь, Алексей ответил на ваш вопрос.

А давайте так, я ещё минуту подожду, э, вопросы какие-то дополнительные, потому что на самом деле сегодня вопросиков достаточно немного, на удивление. И если вопросов не будет, то будем прощаться на сегодня. Так, ну что, вам спасибо всем, что пришли. Я вижу в чате только прощание и благодарности, а не вопросы. Поэтому на этом я тоже вам говорю спасибо, что пришли. Надеюсь, увидите вас на курсе. Приходите, там будет интересно. -Э на этом прощаюсь. Всем хорошего вечера и пока.