Transcription
Ну что, всем привет. А очередной вебинар по Декстау. Мы продолжаем погружаться, а в то, каким образом профессионалы рынка используют и инструменты для создания различных приложений. И сегодня, собственно, продолжим эту тему разбирать. Поговорим о том, как инструменты no-code и low-code, так как NV semen и помогают, а, создавать клиентские приложения, решать, э, конкретные бизнес-задачи. И сегодня с нами будет делиться своим опытом Иван Четвериков, я надеюсь, правильное ударение поставил. А, ведущий архитектор Четвериков. Супер, сорри. А, Иван Четвериков. Ведущий Я архитектор в Рафте. И я и разработчик, э, там, по-моему, более чем пятилетним опытом работы, ну и, собственно, эксперт в создании приложений и внедрении искусственного интеллекта в бизнес. Аа, Ваня, ещё раз спасибо, что согласился к нам присоединиться. И передаю слово и умолкаю.
Да. Всем ещё раз привет. Э, у нас сегодня будет такая интересная тема. Это low-code автоматизация бизнеса. Совсем в платформы идти сегодня не будем. Будем разбирать в том числе, аспекты, когда можно применять небольшую автоматизацию на low-code платформах, в том числе NCMN, Naton и DFI. А, соответственно, я являюсь я архитектором, работаю в компании RAFT. Мы внедряем очень классные проекты в множество разных сфер, от чат-ассистентов до копайтов и, а, прочих вообще AI инструментов, которые только можно представить. У нас есть за плечами огромный опыт с несколькими десятками, наверное, проектов, как малым, средним бизнесом, так и с большими компаниями и также госухами.
Сегодня у нас будут несколько основных тем. Рассмотрим вообще, что такое DIF, а поговорим про RAG. А далее немножечко затронем Meit. А он у нас будет являться ядром. Афай нас интересует с точки зрения базы знаний, организации и хранения данных конкретно о вашем бизнесе либо о каком-то процессе. Далее покажу, как можно быстро настроить и создать AI ассистента. И вообще затронем такую глобальную тему, что же выбрать open source, инструменты или всё-таки в каких-то моментах можно уйти в кастомную разработку.
А, во-первых, начнём с того, что мы решаем. А у нас есть множество разных проблем бизнеса. Здесь вы можете увидеть одни из них. Что у нас самый, наверное, такой востребованный кейс - это автоматизация техподдержки, обработка каких-то заявок, обработка сторонних процессов. Э, то есть все сейчас стремятся вывести общение с клиентами, то есть первый уровень техподдержки на И, тем самым, э, облегчить работу своих сотрудников и в некоторых случаях, возможно, даже сократить штат, если мы говорим про какие-то компании с многотысячными штатами техподдержки.
А, соответственно, что такое Nathan? А Nthon - это такой некий швейцарский нож для автоматизации. Вы, в принципе, уже с ним знакомы, как мы поняли. А у нас всё то же самое в нём. Это полностью Open source платформа, которую можно развернуть в облаке, можно развернуть в себя локально поставить. У нас есть визуальный редактор workflow. Можно создавать кубиками любые практически пайплайны и агенты. У нас множество готовых интеграций с мессенджерами, с почтой, с какими-то сервисами. И у нас нет ограничений по масштабированию и выполняемым задачам. Natбироваться архитектурно, как вертикально, так и горизонтально.
А, и давайте чуть подробнее про DIF, что это вообще такое. Начнём с того, что это тоже Open Source платформа. Это тоже платформа для создания AI приложений. У неё есть визуальный конструктор без кода. А на самом деле, пока я готовил материалы, там появился тоже редактор кода. Мы его затронем а в уже непосредственно показе. Там есть также поддержка различных вендеров LLM. Можно поставить Open Source, там Oлаama Connectр, просто connector, ну всякие любые вообще inference модели оно поддерживает. Ну и самое популярное Open AI, Deepsic, там GRК и прочее подобное. А также у нас есть полноценная платформа с векторной базой знаний для RAG приложений.
А что же вообще такое RAG? Давайте поговорим, зачем он нужен. Единственная проблема у LLM, они не знают контекст вашей компании и очень много могут коллекционировать и придумывать то, чего у вас на самом деле не существует. RAG работает следующим образом. А у нас есть векторная база знаний. В векторную базу знаний. Мы по определённым алгоритмам, по определённым структурам загружаем документы текстовые. Они могут быть любые. То есть в целом, ну, в основном это всё PDF, Word, Excel, просто CSV, а парсеры, практически всё могут взять и вычленить оттуда отдельные куски текстов. Далее мы этот текст распределяем по чанкам и преобразуем каким-нибудь из алгоритмов. Алгоритмов тоже может быть множество и отдельные embedding модели в вектора и кладём в векторную базу. А далее мы используем этот кусочек RAG для того, чтобы поместить релевантный контекст от запроса пользователя к модели. Это что мы делаем? Аэ, пользователь спрашивает какой-то вопрос, например, я хочу получить ваш ассортимент. А ваш ассортимент уже загружен в векторную базу. И получается передаётся вопрос пользователя и ищется максимально похожий вектор к запросу пользователя. И следующий чанк и плюс-минус там, как вы настроите, то есть, допустим, топ-пять самых подходящих, близких по векторному представлению текста чанков будут попадать в запрос, в контекст к LLM. Соответственно, преимущество RAG - это то, что мы используем минимальное количество токенов и подтягиваем самую релевантную информацию к LLM модели. А также мы можем вручную сделать проверку ответа и вообще как угодно переконвертировать информацию, потому что RAG - это достаточно независимый такой шаг в работе модельки.
И давайте вообще посмотрим, а как нам можно подружить DIFI и Nation. У нас есть два таких ярких примера. Сейчас я переключу демонстрацию уже на полный экран. Так, а всё видно, всё хорошо? Ну, мы видим презентацию. А, ну весь экран видно. Вот появился тулбар. Да, дада. Да, с тулбаром и с оперой на весь экран. А, да, всё супер. А у нас есть два пайплайна. У нас есть тул для агента и у нас есть вариант сделать прослойку RAG через Wi-Fi, которая загружается всегда. А ещё один буквально слайдик презентации про развёртывание. Самое интересное, самая, наверное, сложная часть в проверке вообще, как это всё работает. А, в принципе, если с Нейтоном все уже знакомы, там в одну команду из докера всё это разворачивается, то же самое можно сделать и с DIF. Здесь есть тоже ссылочка. Здесь, правда, не одна команда, а нужно сделать ещё копии .env, но в целом он также собирает dockerфайл и через docker compos всё поднимает. А я буду сегодня показывать на развёрнутых Дайфа и Нейтне у нас в облаке в рафте, потому что у Нейтона работает интеграция с телеграмом, и через Telegram будет показывать удобнее. Telegram требует деплоймент непосредственно на домене с SSL-сертификатом и протоколом, иначе локально нужно там делать танцы с бубном, подключать проксирование через какой-нибудь сервис, и это не всегда работает и не всегда очень удобно получается.
А, соответственно, теперь перейдём вообще к практике, будем показывать. А что у нас есть? Я подготовил такую небольшую базу знаний. Вот, честно признаюсь, я её сгенерировал. А, допустим, у нас есть какой-то магазин, который продаёт двери, и у него есть техподдержка, у него есть какой-то ассортимент и вообще пайплайн, как общаться. Ну, будь то сотрудник техподдержки, будь то продавец. Соответственно, у нас здесь есть в файлике структура наших данных. А эта структура может быть практически любой. То есть здесь можно вообще тестировать и загружать от, например, тех файлов, которые у вас уже есть, и потом в будущем преобразовывать. Но самый, наверное, такой оптимальный способ делить его по небольшим чанкам, и потом эти чанки отдельно будут парситься по примерно количеству токенов. То есть там один токен примерно три символа, в среднем по 3.000 где-то символов на один чанк - это достаточно оптимальный вариант. То есть у нас есть пример, а, соответственно, товаров. У нас есть некоторые там параметры для условно быстрого ответа. Также сюда можно добавлять всякие скрипты для того, чтобы работал. Ну, например, у нас есть несколько классов обращений. Под каждый класс у нас есть определённые функции, которые должен там спросить или задать вопрос покупателю непосредственно продавец или сотрудник техподан. В данном случае можно вообще сюда добавлять что угодно в зависимости от потребностей.
А, и теперь в интерфейс Wi-Fi пойдёмте. А у нас, соответственно, есть много всяких тут вкладочек. А начнём с самого, наверное, базового - это настройки с вендерами моделей. То есть у нас здесь есть множество моделей. Нам сегодня потребуется только Open AI. Мы будем использовать embeddings от Open AI в данном случае. И пока что больше ничего не потребуется. То есть я покажу, конечно, как ещё тут создавать чаты. Тоже отдельная интересная тема есть для внутреннего использования, но пока что нас интересует конкретно вкладочка с базой знаний. То есть здесь мы можем создать базу какой ты взял просад и всё. Так очень плохо слышно. Сейчас, пардон, я всех за ещё и проконтролирую, чтобы я деньги перевёл. Так, всё, продолжаем.
А, да, соответственно, у нас здесь есть, ну, я уже создал базу знаний в настройках. Здесь есть из интересного выбора как раз вот embedding модели. Здесь можно выбирать разные модельки. у нас text-embedding-3-large от Open AI - это самая, наверное, оптимальная модель, если ваши данные не такие чувствительные и могут, в принципе, отправляться в облако. Если данные в облако отправляться не могут, здесь, соответственно, можно настроить в, ну, поднять локальную какую-то модель и уже в поставщика моделей добавлять какой-нибудь из ваших локальных. Вот. Далее у нас есть базовые настройки поиска, которые будут использоваться изнутри DIF для местных чатботов. А здесь есть векторный поиск. Здесь есть полнотекстовый и гибридный. А, соответственно, гибридный - это векторный и полнотекстовый в соотношении либо через ранжирование. То есть сейчас модели ранжирования мы рассматривать не будем, мы поставим просто гибридный поиск. А ранжирование на самом деле тоже штука интересная. Э, есть здесь базовая модель джина, джина условно бесплатная. Можно для неё будет локально самим поиграться, потестировать, но сегодня просто возьмём, что у нас есть только ключ Open AI и мы хотим что-то быстро запустить. А, соответственно, при создании базы мы это сохраняем. А, и нам нужно будет загружать документ. А, ну давайте, наверное, мы его удалим сейчас и загрузим заново. А, и здесь как раз у нас есть настройки нашего чанкинга. То есть здесь есть идентификатор, который будет базово использоваться как разделитель. Здесь у нас есть максимальная длина в символах, то есть, ну, вот, допустим, 1024 символа и перекрытие. Чтобы лучше улавливать семантику. То есть, допустим, у нас есть какой-то абзац на 200 символов, и у нас будет перекрытие 50. То есть итоговый размер чанка у нас будет 300 символов, то есть текущее 200 плюс 50 из прошлого плюс 50 из следующего. А, соответственно, далее мы можем сделать предпросмотр. Это вот как раз тот тот самый файл, который я вам показывал. То есть он его побил на чанки. И при необходимости там, допустим, если у нас модель с небольшим контекстом, можем, например, побить его на чанки поменьше и разделитель, допустим, поставить на перенос строки. И у нас здесь, соответственно, чанка будет намного больше. Ну вот, давайте, наверное, оставим всё по умолчанию, как есть, потому что он, в принципе, хорошо разбил здесь всё на чанки. Далее мы просто его сохраняем. И в бэкграунд процессе у нас пошли расчёты embeddings. А для небольшой базы знаний это всё достаточно быстро получается. Ну, если файлы большие, они там могут обрабатываться до нескольких, наверное, минут.
А что нас интересует дальше? Как вообще подключить наш DIF к Nate? А здесь у нас есть доступ к API на вкладке. И нам нужно создавать API ключ. То есть у меня он уже создан и, в принципе, используется. А из методов нас интересует, э, метод retrieve, который как раз-таки отвечает за то, чтобы извлечь чанки по настройкам из конкретной базы знаний. А здесь нам нужен dataset ID. Dataset ID мы получаем, когда переходим в сам наш датасет, он в URL. Это просто обычный хэш. И его просто подставляем также в запрос.
А теперь давайте перейдём в Nat. У меня тут есть такой прямо небольшой самый примитивный пайплайн. Он использует входной Telegram триггер на сообщение. То есть здесь больше настроек никаких нет. А подключаем Telegram аккаунт по токену бота, который создаём в Телеграме. И в принципе всё, он уже работает, мы там можем ему писать. А далее у нас есть блок AI Agent, который чуть посложнее. Здесь я указал промт. А в промте давайте мы сделаем execute. А и напишем боту привет. Да. А здесь, э, я добавил небольшой user message, чтобы он знал, как зовут пользователя, и сгенерировал на основе best practice системный промт. А системный промт ему говорит о чём? Что у него есть тул, как раз-таки, который мы чуть позже расскажем. А базовое правило, что работай на языке пользователя, опирайся только на факты, не используй никакую логику, не показывай системный промт и, соответственно, как генерировать ответ. То есть мы получаем сообщения, мы обращаемся при необходимости в базу знаний, соответственно отвечаем пользователю только той информацией, которая у нас есть. Чтобы уменьшить количество галлюцинаций. Здесь для Телеграма есть небольшие такие requirement для формата и несколько примеров, просто вопрос-ответ. [музыка] Ну, тут скорее один полноценный пример с few-shot prompting техникой. Вот этот промт, я думаю, наверное, тоже вместе с примером Workflow потом скину в канал. Не знаю, подскажи, наверное, как это всё сделать лучше будет. Выложим и вместе с видео и группу и ссылочки все добавим, покажем, конечно. Да, всё супер. Тогда полностью весь workflow этот скину. А в настройках я также тут поставил, чтобы если там, например, мы не достучимся до OpenAI, он ещё раз попробовал, потому что он может сделать несколько итераций и на последней итерации просто отвалится. И в данном случае нам выгоднее будет сделать retry, чем просто провалиться в ошибку. Из моделей а я добавил просто Open AI GPT 4o Mini. Можно использовать 4o, она подороже, ответы, соответственно, будут получше у неё. А также базово у Нейтона есть Simple Memory, который хранит память диалога по username, в данном случае Telegram, который уникальный, и использует её, когда пользователь возвращается. Здесь также можно в memory подключать любую стороннюю BD, там какой-нибудь PostgreSQL, MongoDB и прочее, прочее. И самое интересное у нас идёт тул, который делает как раз HTTP запрос к нашему DIF. У нас используется POST метод как раз-таки на датасет, который мы с вами смотрели, и метод Retrieve. А у него есть generic credential, это Bearer Token. Здесь, соответственно, я создал, а секрет в ней, который хранит в себе токен. И также у нас есть большой такой body. Body у нас типа JSON. И есть, э, два основных поля. А первое поле - это query, как раз-таки запрос пользователя. И здесь нам нужно поставить вот такую звёздочку, чтобы модель понимала, что это поле нужно ей сгенерировать. Ну и здесь просто, что query for RAG search. И второй параметр - это как раз-таки уже retrieval model. Здесь у нас используется Expression и, соответственно, есть небольшой JSON, который включает в себя поисковый метод. То есть в нашем случае это Hybrid. Также есть full text и vector, как мы смотрели. И также можно включать дополнительные параметры, то есть threshold и как раз наш ranking. В данном случае я пока это всё выключил для простоты примера и без необходимости погружения в большую теорию. Вот. И, соответственно, у нас, в принципе, на этом всё. То есть здесь мы можем проверить, например, что вообще наш запрос работает и отдаёт нам какую-то информацию. Вот, как видим, он действительно отдал три чанка, которые нашлись. Вот. И обратно отправляем сообщение в Telegram. Вот.
А для примера вообще работы тулов я тут ещё добавил такой интересный тул. Это random cat Fact. Так, а давайте сохраним и вообще сделаем execute на полностью наш workflow. Например, там, не знаю, какие двери у вас есть в наличии. То есть видим, что у нас AI агент сразу пошёл в наш тул и вернулся на опять в модель и сейчас вообще думает, как это всё отформатировать. Так, а мы видим, что он действительно обратился к нам по имени, потому что у нас есть имя, и вывел 1 2 3 4 5 6 дверей из нашего ассортимента. Шесть ли точно? Пять. Всё правильно. Пять. Мы там действительно можем свериться, что наши параметры, они сходятся с тем, что у нас лежит в нашей базе знаний. То есть таким образом мы понимаем, что у нас агент сходил в наш RAG и верно получил те данные, которые там нужны. А что мы можем сделать? Ну, это, например, не знаю, изменим какой-нибудь артикул. То есть напишем сюда тест и вообще посмотрим, перезагрузим наш документ, что оно работает и никуда не кэшируется. То есть давайте удалим ещё раз и добавим новый файл. Также здесь пока ничего менять не будем. И давайте ещё раз спросим. То есть здесь как раз есть а такое опасение, что иногда бот может не ходить в наш RAG, и тем самым придётся подкручивать ему системный промт. То есть так, да, то есть мы как раз столкнулись с тем, что у нас есть история сообщений, а, которая хранит в себе какие-то sensitive данные. То есть вот в данном случае мы либо должны её почистить, а либо прописывать ограничения к промту, что мы должны почаще ходить, должны почаще ходить соответственно к базе знаний, потому что она будет обновляться. Давайте сохраним и проверим это ещё раз. Да. Вот как видим, базу знаний, точнее базу данных нашего диалога мы обновили, и теперь он сходил в нашу базу знаний. Но всё равно что-то он нам выдал не то. Точно ли я сохранил? Давайте посмотрим. Да, здесь точно тест. А, возможно, он в нескольких местах указан. Нет, должно быть верно, вроде бы. Не знаю, сохранилось или не здесь. Ок. здесь. Ок. Давайте тогда посмотрим, что нам выдал наш HTTP request. То есть он, а, спросил двери в наличии получил. Он всё-таки, видимо, получил историю сообщений или нет? Нет, он получил тест, но в какой-то момент решил сгаллюцинировать и всё-таки отрезать тест, потому что подумал, что это что-то действительно тестовое на основе остальных. А, да, вот такие моменты как раз-таки в процессе промт тюнинга или тюнинга самой структуры базы знаний, они решаются. То есть, либо мы прописываем какие-то конкретные ограничения в промт агента, если они более статические, а если они более динамические, мы можем записать их в базу знаний. Аа также здесь есть из интересного, когда мы смотрим наши чанки, мы эти чанки как раз-таки можем отредактировать. То есть, например, если мы там не тест напишем, мы можем там вот A написать, допустим, и также это сохранить. То есть, что нам позволяет хранить базу знаний и редактировать её напрямую в интерфейсе без перезагрузки файлов. Допустим, если они будут на сотни мегабайт. Вот, конечно, на сотни мегабайт файлы загружать я не рекомендую. Они могут очень сильно засорять контекст своей нерелевантностью.
Так, а теперь вообще давайте побольше поработаем с базой знаний. А если вообще, может, есть у кого сейчас вопросы именно по интеграции, как интегрировать Nathan с DFI? А, да, хорошо. А пока вопросов нет. А, у меня есть короткий вопрос, который Угу. Давай уже неоднократно. Не, не про связку, а про документы. Нередко спрашивают по поводу того, что типа есть, например, какой-то наработанный объём контента, там гайдлайны в PDF и так далее и тому подобное. И вот все вот эти файлы, есть ли какие-то лучшие практики по трансформации контента? Вот как лучше его для RAG условно преобразовывать?
А, да, а вопрос вообще отличный и очень релевантный. А для RAG самое главное соблюдать структуру документов. То есть, если у вас есть какая-то база знаний, а у вас должен быть под неё определённый парсер, и у неё должна быть у всей, а, желательно одинаковая структура. То есть, допустим, я сейчас вот генерировал базу знаний, а здесь есть для каждого заголовка отдельная такая своя табличка, либо отдельный набор свод правил. То есть можно заметить, что они все в примерно одного размера и примерно похожи по структуре. То есть у нас должна быть ээ только релевантная информация в своём кусочке. У нас при необходимости должны быть ссылки на какой-то другой чанк, чтобы этот чанк тоже мог подцепиться при векторном поиске от того, что он может быть с перекрытием. А и не должно быть похожих терминов, которые были бы размыто описаны в разных пунктах базы знаний, потому что, а, не знаю, ну, вот, допустим, на тех же дверях и ассортименте может быть, например, пункт релевантных и пункт допустим, какие-то устаревшие модели, которые вышли из продажи. Но, допустим, а по поддержке ещё нужно отвечать на вопросы, если таковые будут. А здесь совет, какой здесь совет? это как раз-таки расписывать в метаданных, то есть здесь в принципе, ну, в любом фреймворке, то есть будь то какой-нибудь LangChain, будь то самописный, будь то DIF, который с интерфейсом. Здесь для каждого чанка можно добавить ключевые слова - это метаданные. И по этим метаданным у нас будет более релевантный вывод. То есть, если информация похожая, мы должны, а, отсеивать её по метаданным. Аа отдельный, конечно, есть случаи, когда нам нужно проваливаться по структуре, например, по иерархии. Если у нас есть, например, классификация обращений верхняя, там несколько уровней и сотни нижних подуровней, а здесь может подойти стратегия, когда мы делаем это итеративно, то есть в несколько запросов. Сначала моделька ищет первый уровень, по первому уровню уже мы фильтруем в следующий раз э наши метаданные из RAG, ну и, соответственно, и так далее. Можно делать это до бесконечности. Да, надеюсь, на вопрос ответил.
Да, спасибо большое. Если у кого-то ещё есть вопросы, кнопочка поднять руку, и тогда я разберу. А, да, супер. А давайте тогда, наверное, ещё покажу вообще второй вариант, как можно добавить нашу базу знаний. То есть, чтобы мы ходили в неё не итеративно по выбору LLM, как тула, а мы можем сделать отдельный тул как HTTP request шаг. То есть мы, грубо говоря, копируем сейчас всё то же самое. И у нас идёт отдельный уже запрос, и он ходит туда всегда. То есть в данном случае query у нас будет это прямой запрос от пользователя, то есть без преобразованных э каких-то параметров от LLM. То есть это, если мы уверены, что у нас именно база знаний заточена на тот список вопросов, который задаёт пользователь всегда. То есть в таком случае мы можем избавиться от того, что LLM будет галлюцинировать, но нужно более тщательно делать структуру нашей базы знаний. Да. Всё. То есть мы получаем теперь полный запрос от пользователя. И у нас полностью сохраняется наш workflow. Только наша база знаний будет вызываться всегда на первом шаге. Давайте обновим без сохранений, да, просто вообще я показал вам как пример, а, конечно же, а более эффективно, когда LLM решает, когда использовать базу знаний.
Так, и пойдём теперь к DIF. А-а, мы поговорили про вообще то, как настраивает RAG в DIFI и что есть база знаний, но на самом деле сейчас это не все функции. Также теперь есть у нас, а, студия, а, где мы можем создать какое-то своё приложение для внутреннего, например, пользователя, для сотрудника компании, которому нужен доступ к той же базе знаний. Из шаблонов у нас есть тут, на самом деле, очень много различных ботов, но давайте попробуем создать с нуля. Здесь есть самый базовый - это чатбот. Здесь есть агент, у которого есть чуть больше настроек. У него также есть различные тулы, которые мы можем добавлять. А есть, соответственно, просто генератор текста и уже более сложные - это рабочий процесс или чатфу. Чат flow - это, по сути, тот же самый рабочий процесс, только чуть попроще для настройки. То есть здесь есть отдельные ноды из рабочего процесса. Нас здесь может заинтересовать то, что здесь также добавился блок кода. То есть раньше DIF был полностью no-code инструментом, теперь он стал low-code инструментом. И в отличие от Нейтона у него есть кроме JS ещё и Python. И здесь можно писать полноценные функции, какие-то блоки, что-то вызывать. И, в принципе, это всё будет, э, прекрасно работать. А для чего вообще можно это использовать? Соответственно, мы можем создавать примерно похожих агентов, как в Нейтоне. Конечно, чуть поменьше здесь есть каких-то различных автоматизаций, чуть поменьше здесь есть интеграции, но базовые вот HTTP запросы, базовые вот эти вот блоки кода, какие какие-то преобразования данных он уже умеет поддерживать. Это, наверное, больше тема для отдельного вебинара, чтобы сейчас очень много времени не занимать. Вот тоже можно показывать много проектов. А давайте, наверное, создадим вообще какой-нибудь простейший flow, то есть, чтобы показать, как он работает. Здесь для вообще простоты можно самому сгенерировать инструкции. То есть мы можем написать, что там консультант, и он сейчас просто что-то сгенерирует нам, чтобы не тратить время на написание промта. Да, соответственно, он нам сгенерил небольшой пайплайн. Давайте просто применим его полностью. И здесь как раз мы можем добавить э наш контекст. Наш контекст - это как раз полностью нашу базу знаний. То есть здесь мы можем добавлять ну не одну, можем добавлять больше разных.
и также сделать э-э федерацию по метаданным. То есть, если мы размечали какие-то чанки, а мы можем здесь также добавить какое-то условие. Ну, сейчас мы, в принципе, не размечали, можем её отключить.
Так, а здесь, наверное, переменную мы удалим. То есть сейчас у нас, а, переменных нет. И как раз вот у нас есть, а, наш чат-бот, а, в предпросмотре. То есть, допустим, спросим у него, что есть в наличии, и он нам... Так, м, какой тип нас интересует? Давайте скажем, что нас интересует всё. Не знаю, очень настойчиво следовать своим сгенерированным скриптом. Ну, давайте сив плюс mdf. Да. Ну, вот как раз он нашёл двери, которые у нас койный массив плюс МДФ. В принципе, это приложение мы уже можем опубликовать, а, его запустить. То есть для пользователя это будет выглядеть как полноценный чат в любом, не знаю, сейчас приложении.
И также из интересного, мы можем использовать данный чат в пайплайне в Nat. То есть, также есть отдельная вкладочка доступ к API. Также мы можем создать ключ и здесь, соответственно, пользоваться методами вот основной sendт message и, допустим, переместить в Telegram, в почту, там, не знаю, в любую, наверное, соцсеть, которая открытая API поддерживает, и тем самым добиться больше автоматизации. Ну, и, в принципе, генерации самой базы знаний и оркестрации в одном месте, а именно интеграция по API и весь пайплайн работы с сторонними вендерами там в духе Телеграма, Ватсаппа, SMTP и прочего, прочего уже делать через Naton рядом с каким-нибудь Workflow, допустим, по синхронизации данных каких-то других пайплайнов, которые требуются в вашей работе.
Так, здесь вопросы есть какие по данной части? Да, ну, если что, вопросы, пишите тогда в чат. А-а, и давайте сейчас я переключусь на браузер. Подведём небольшие итоги. Так, а пойдём вообще к самой проверке гипотез через open source. Соответственно, вот мы с вами сидим здесь чуть меньше часа, и за этот час можно было уже полностью вообще с нуля создать такое же приложение, просто понимая, что мы это умеем. И, в принципе, до полноценной реализации здесь нужно потратить, наверное, не больше пары недель, чтобы отточить там какой-то список вопросов базовый, которые пользователи всегда спрашивают. И далее уже можно это всё подготавливать к продакшену и какой-то боевой работе.
Если мы использовали бы кастомную разработку, нам бы дополнительно пришлось смотреть, какие вообще сейчас технологии актуальны, что сейчас используется, потом понять это всё спроектировать, как мы это будем разворачивать, на каких мы технологиях, какой стек будем использовать, чтобы это всё написать, кто это будет писать. Нужно где-то ещё организовывать код CCD, и только потом мы будем переходить к этапу реализации. Это может затянуться, наверное, на несколько месяцев. Ну, если использовать стандартный подход к разработке, не включая сюда какой-нибудь вайп-кодинг. Вот свайпкодинговым, конечно, этап реализации тоже сокращается там до нескольких дней. Вот. Но тем не менее, это всё равно будет дольше, чем уже реализовывать это всё на готовых инструментах. И, соответственно, дальше проверка нашей гипотезы и подготовка к продакшену, они, в принципе, похожи.
А небольшую табличку сделал. А что же вообще выбирать? Да, тут на самом деле сейчас плюс больше кенсорсу, что у нас идёт быстрее разработка, что стартовые затраты у нас практически бесплатные, только на человеческий ресурс. А масштабируемость, да, масштабируемость у нас более ограничена, потому что зависит от тех сервисов, которые мы используем. Но если брать Natйan, Nathan, как я уже говорил, он может разворачиваться внутри того же Кубернетса. Можно настроить ему вертикальное масштабирование, можно настроить горизонтальное. На некоторых проектах и на тестах он себя очень хорошо показывает и не падает.
А дальше самое интересное, что в Open source нас ждёт, это поддержка от сообщества. У нас есть много тысяч контрибуторов в каждой из проектов, и эти много тысяч быстрее разрабатывают новые фичи, фиксят какие-то баги, уязвимости и прочее минорные фиксы. Из функционального покрытия, как раз-таки у нас интересно то, что мы можем сделать какой-то небольшой прототип, впоследствии подумать, что мы хотим добавить что-то ещё и добавить это уже сегодня, потому что есть полноценная интеграция. Например, хотим сделать уведомление на почту. Создали Gmail, скопировали креден от SMTP, добавили в нейтоне в каком-нибудь отдельный блок, что вот нужно отправить уведомление, и всё, уведомление уже отправляется. Вот. Ну, и, соответственно, в принципе, это как раз вот про интеграции уже я и рассказал.
А из минусов, конечно, минусы тоже есть. Кроме масштабируемости, есть ещё минус по безопасности. Во-первых, не все хотят запускать код без аудита. То есть это нужно в некоторых компаниях будет провести аудит от либо сторонней компании по инфобезу, либо внутренним отделом ИБ для того, чтобы просто вообще понять, не утекут ли ваши данные куда-то в облако. И второе - это уязвимости. Если какие-нибудь злоумышленники найдут в открытом коде уязвимость, то они могут эксплуатировать ваш сервис, а вы даже можете об этом не узнать, например. Вот. Ну, в принципе, у меня рассказ на этом заканчивается. Жду, наверное, вопросов. Готовы? Наверное, теперь к бурному обсуждению, если оно будет. Да, спасибо. Я ещё раз напоминаю, что если у кого-то возникли вопросы, нажимаете кнопочку поднять руку. А, хотя я сейчас просто для всех разрешу, э, чтобы сами могли микрофон включать, да, поэтому не стесняйтесь.
Мне маленький вопрос прислали по поводу дифи. Ты тогда показывал, что там модель для имбединга выбирается. Можно ли там использовать локальные модели, которые вот, например, через оламы запущены или там только что-то, что уключу можно? Так, а давайте вообще посмотрим, какие здесь есть модели по умолчанию. Именно речь идёт о моделях для имбинга. То, что ты показывал GMA. А можно ли там как А уламышки? Ага. Можем вообще посмотреть вот. Ну, то есть как бы она подключается, ну вот по локалхасту. Ну, и в принципе, ну, все модели она распарса, да? То есть ответ определённый, да? Супер. То есть можно использовать на полностью локальной истории тоже. И, соответственно, это всё может даже внутри какого-то корпоративного контура работать. Да. Да. Это можно вообще запускать всё даже без интернета. То есть и Naton, и DIFI, они прекрасно работают в онпреми. Супер. Ещё вопросы? Ну, тем лучше. Редко когда бывает, когда всем сразу с ходу всё понятно, но сейчас, мне кажется, да, действительно, было всё очень подробно, полезно и стало ближе понимать, э, как именно на примерах таких корпоративных сценариев. Клёво. А, да, размьютить секунду, конечно. А вы на самом деле сами себя можете размьютить также. Сейчас, секунду. Да. А, здравствуйте. А можно вопрос больше по NAже по вот тому, как с этой базой работать? Я просто его развернула и столкнулась с проблемой, а как отправлять вместе с промтом изображение в Open AI Chat. Там, как я понимаю, это можно делать только с изображение, только с урлом изображения. То есть, грубо говоря, надо где-то его размещать. Нельзя просто сразу отправлять его. А с ходу? А точно можно. Так, сейчас я, может, быстренько даже смогу Vision модель подключить. Так, наверное, я тогда верну демонстрацию. Так, а именно про агента, да, интересует. Угу. Очень много зума. Так, о, и open AI. Я понимаю. Так. Здесь вот отш. Возможно, здесь, а версия у нас в облаке не та стоит. По-моему, тут что-то должно было быть, да? Ну, на, наверное, сходу сейчас не найду, но изображение точно мы отправлялиформа. Ну да, тут, наверное, чуть-чуть ушла версия назад от последних. Там, кстати, есть точно, если использовать не AI агента, а использовать именно ноду Open AI, там есть работа с изображениями, да, если использовать ноду, нода точно есть, да, он anй, да, и analй есть, и generate, то есть, а, возможно, имеет смысл, а, именно подключить, а, отдельную ноду Нет, я ещё то есть, ну, вот так вот её, допустим, воткнуть и уже потом, а, проанализированное изображение в текстовом формате отправлять в агента. Возможно, есть уже отдельная тула. Да, но возможно ещё нет. А, да, я пробовала добавлять, ну, вот analyй image и generate image. Она принимает только изображение, а мне нужно ещё и промпт прописывать, чтобы она мне в итоге вернула изображение. там предлагает сделать кастомную ноду через HTTP requкст. И почему-то там он просит именно урлом изображения, то есть не хочет ни base 64, ни просто изображение в сыром виде принимать. И хотелось как-то вот это вроде обойти, потому что пока что подключиться через, например, Google Drive и через временное сохранение файла выглядит немножко сложновато. Ну, через Google Drive точно, наверное, смысла нет сохранять в таком ключе, но, по-моему, в analй идже тут также есть кампи, кстати. А здесь есть текст инпут, как раз который должен являться именно промптом тем самым. То есть он же, получается, вернёт мне текст, а не изображение. А, а нужно, а, я хочу прислать изображение, написать промт, что сделать с этим изображением, чтобы он мне его вернул. А, ну то есть нужно именно изменить условно, да, например. А можно тогда отменяю ещё вопрос? А изображение типа редактирование оригинального изображения или мы раскладываем изображение, добавляем к нему промт и потом на основе того, что получилось, генерируем новые изображения? Нет, редактирование. А, да, ну, на самом деле, не сталкивался ещё с редактированием именно изображений. А, в принципе, в наших проектах не было редактирования, был анализ и была генерация. Угу. То есть в таком ключе, ну, я на самом деле посмотрю, может ещё что-то интересного сможем придумать. Хорошо. Ну и на самом деле сценарий с промежуточным сохранением вполне вероятно не такой ужасный, потому что, ну вот тоже сталкивался с похожими вещами, не совсем конкретно этим сценарием. И, ну, промежуточное через Google Drive там не сильно сложно это всё реализуется. Главное айдишники этих изображений в сохране. Но я честно не знаю. То есть он должен взять изображение, внести в него изменения и снова сохраниться. То есть там довольно много, ну, типа четыре нода промежуточных получается. То есть возможно типа через промежуточное хранилище объяснительно всё попробовал. Хорошо, спасибо.
Так, ну что, ещё вопросы? Напоминаю, что можете попросить э поднять руку. Вроде как все должны иметь возможность сами разчитаться. Ну что, а если вопросов нету, то могу ещё раз только порадоваться, что всё было так понятно и доступно. Час, собственно, подошёл к концу. А контакты Ивана вместе с полезными ссылками будут размещены под видео, а также в группе. Собственно, как это я думаю, что не последний раз встречаемся, поэтому, Иван, ещё раз большое спасибо. Было очень полезно. Сценарий именно бизнесового формата, это то, что наиболее интересно всей аудитории, поэтому круто, круто. Ещё раз большое спасибо. И тогда можем потихоньку расходиться. Всем хороших выходных и до встречи в следующий раз. Всё, всем пока. Пока-пока.