LLM разработка в 2026 навыки кейсы внедрений требования

Давайте представимся. Меня зовут Кирилл Деденко. Я продюсер разнообразных бесплатных мероприятий и, в том числе, занимаюсь тем, что помогаю их вести. Поэтому сегодня буду помогать нашему спикеру, собственно, взаимодействовать с вами, передавать ваши вопросы. Ну и, конечно, расскажу немного про Кексты, про то, какие мы даём возможности в развитии, в LLM разработке, а также озвучу разнообразные интересные условия, которые мы подготовили только для зрителей этого вебинара.

Ну а спикером сегодня будет Рустам Барханов, старший инженер-программист отдела интеграции в Финаме. Но я думаю, что пусть лучше Рустам чуть подробнее расскажет про себя и про свой опыт. Рустам, привет.

Привет.

Привет. В целом про опыт можно рассказывать очень и очень долго, потому что Финам — это, к счастью или к несчастью, одна из многих компаний, в которых я работал. Также работать успел и в Ozon, и в WhatsApp, который занимается чатботами для WhatsApp и прочих подобных, а не в WhatsApp непосредственно. Люди иногда путают. В том числе и работал в Камазе, на Татнефти и так далее и тому подобное. Опыта куча. Работал вебмастером, потом frontend, backend разработчиком, fullstack разработчиком и теперь занимаюсь LLM разработкой.

Да. Про твои кейсы и про опыты мы ещё сегодня подробнее поговорим, потому что на этом, в том числе, строится то, что мы сегодня будем рассказывать. Мы, в принципе, не всегда знаем, какой условно средний уровень аудитории, кто пришёл к нам на трансляцию сегодня. Поэтому нам будет интересно узнать и про ваш опыт тоже, э, про то, являетесь ли вы разработчиком, где, в какой сфере, fullstack разработчиком, может быть, frontend-разработчиком, может быть, для вас это тоже в таком случае актуально, а может быть, вы специалист вообще из какой-то смешанной области, но также так или иначе связаны с разработкой. Может быть, вы project-менеджер, но тем не менее постоянно взаимодействуете с разработчиками. И в вашей компании тоже актуальная история про то, что прямо сейчас хотят внедрять и LLM в любые возможные процессы. Пожалуйста, напишите про себя чуть подробнее для того, чтобы мы тоже понимали, какая у вас цель для этого эфира, что вы хотите сегодня узнать в первую очередь и почему, то есть кем вы работаете прямо сейчас, если это, конечно, возможно разглашать.

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

Team Lead, CSD, Frontend, B2B, Техлит. Бизнес хочет внедрять всё и везде, поэтому задача пала на LLM. С чем идут, для чего, куда его можно пихать? Сегодня про то, куда его можно пихать, тоже будет много. Начнём мы тему обсуждать с того, как всё это появилось вообще, как появился в текущем виде. И для этого я передам, собственно, слово Рустаму.

В целом мы можем рассказывать огромное количество историй о том, как всё это зарождалось, как всё это появилось и как всё это воспринималось. Но давайте, наверное, ограничимся не зарождением информации и систематизацией информации, а про довольно недавнюю историю появления OpenAI, Anthropic с их Claude, Яндекс с их Алисой, Google с их Gemini. Обобщим всё это как можно сильнее, потому что иначе у нас просто не хватит времени. И в целом всё это началось с того, что на Западе наконец-то начали рекламировать по полной программе искусственный интеллект. Правда, не интеллект, но кого это всё волнует. И все тут же захотели использовать его в работе. Как? Не знаем. Для чего? Не знаем. Нужно, потому что это революция, Джонни. И в целом, на самом деле, революция здесь есть. Но как с любой революцией, нужно понимать, как, для чего и куда её использовать. Вам может прийти SEO и сказать: "Мы хотим везде использовать искусственный интеллект, быстро в разработку, в CI/CD, в оценку, в кодревью, в постановку задач, в работу с ассистентами". Ну, как это было у нас, честно говоря. И на самом деле во всех этих историях его можно применить. И коротко можно вспомнить, что появился OpenAI, как я сказал, в том году. Ну, даже в 2022 году на Западе начали более или менее понимать, куда всё это идёт и как это можно применить. А в 2025-2026 в России очухались и тоже начали понимать: "Божечки, это можно использовать". И в целом большая часть работы строится на том, что используются основные технологии: RAG, агенты, они же MLOps нередко, и LLM для оценки. И в целом LLM потихоньку становится чем-то вроде нового слоя реальности. Когда-то мы писали сервер, писали фронт, всё делали исключительно руками и всё это запускали под Systemd на каком-нибудь Ubuntu 16, 18 и 20. Не так важно, потому что всё это запускалось в лучшем случае после хорошей настроечки и проверочки со стороны QA. Потом появились всякие истории с PM2 ближе к 2010-м годам. Тогда же начал появляться и Docker, и повсеместная контейнеризация с Kubernetes. И в какой-то момент это всё стало просто нашей новой реальностью. И боюсь, что с LLMками будет примерно то же самое, потому что они уже начинают появляться примерно под любые задачи. Большие LLM для разработки, оценки, внедрения и прочего со стороны тех же OpenAI, со стороны Google, Anthropic, от Яндекса. И вспомните ещё десяток вариантов китайцев, которые вам, конечно же, наверное, уже слышались, но не всем и понемножку. И, как я сказал, весь этот стек будет постепенно проникать в нашу работу. RAG уже используется для того, чтобы систематизировать информацию, искать более удобным, более контекстуально направленным вариантом. Агенты постепенно внедряются в нашу жизнь для того, чтобы быстренько создавать задачки из чата, быстренько ставить ээ созвоны нашим коллегам, быстренько систематизировать информацию после последнего колла где-нибудь в Яндексе или в Контуре. И что постепенно происходит? Компании начинают понимать, как я сказал, что, зачем и почему нужно, где они могут применить для ускорения, для замены иногда каких-то сотрудников, что, как я вам скажу, плохая идея. Но самое главное, начинает пробуждаться какой-то функционал. Общая история, она на самом деле довольно похожа. У нас появляется общая информация, которую мы хотим использовать и дать доступ к нужным людям к этой информации. Возьмём для примера, наверное, чатбот поддержки. И в него, как можно понять, можно вливать довольно большое количество денег, заказывать миллионами индусов, чтобы максимально быстро отвечать пользователям на примерно одни и те же истории. А можно подключить LLMку, большую, маленькую, среднюю в зависимости от вашего контекста. И в целом таких типов сценариев довольно много. У нас есть AI-ассистенты, продажники, помощники, просто подсказать где-нибудь что-нибудь из рабочих. У нас есть надстройки над системами. Мы можем внедрять специальные LLMки в MS Word. Может быть, я чуть позже расскажу об этом, если мы успеем. Интегрировать CRM для того, чтобы проверять контрагентов, для того, чтобы проверять какую-то информацию по правильности её введения. Может, ваш сотрудник неправильно ввёл адрес и автоматизировать некоторые процессы. Процессы автоматизировать, наверное, пока самое сложное, что можно сделать, потому что для этого нужно правильно [откашливается] полностью понимать имеющийся процесс. И во всех этих ситуациях у нас будет повторяться это. И дальше используются LLMки, используются RAG как источник информации и используются агенты для того, чтобы взаимодействовать с внешним миром. MLOps, если что, иногда будет использоваться как синоним агентов. Так вот, мы можем заниматься аналитикой и прототипированием при помощи. Многие, наверное, уже пишут код при помощи Claude или Codex или Gemini или Kami или Minimax. Целая плеяда возможных вариантов. Многие уже внедряют кодревью как раз-таки в тот самый CI/CD со стороны CI. У меня тоже была такая история. Пришлось неплохо попотеть, чтобы заставить всё это чудо нормально работать с GitLab, а не просто выдавать тонну текста обычным комментариям. И, естественно, самое частое и самое нужное — это RAG [фыркает] для с агентами. Ох, это очень обширная история, потому что RAG — это не просто база данных. Это база данных, которая пытается понять суть сказанного и делает это, естественно, при помощи небольших LLMок, эмбеддеров. Как бы я хотел сегодня рассказать об этом всём больше, но боюсь, в этом случае мне придётся держать вас здесь до послезавтра. Поэтому постараюсь как можно сильнее ужаться и привести опять же тот же пример с техподдержкой. Допустим, у вас есть основные истории вашей техподдержки: "Не тот товар привезли", "Не получается подключить к сети", "Не получается сдать товар по гарантии" или что-нибудь в этом духе. Все эти намерения пользователей можно читать при помощи искусственного интеллекта и выдавать ему соответствующие рекомендации. Плюс, конечно, можно их немножечко разнообразить при помощи ответа LLMки, но об этом пока не будем сильно глубоко закапываться. Однако же, в чём же суть? Это же только RAG, то бишь наша база данных с учётом некоторой контекстуальной информации, по которой мы будем искать нужные блоки данных в базе данных по запросу пользователя. Причём тут тогда агенты? А агенты как раз тут очень часто нужны на, скажем так, втором этапе, когда у вас уже просят не просто выдавать готовые ответы пользователям, а как-то обрабатывать их реакцию. Например, пользователь всё-таки хочет сдать товар по гарантии, и, соответственно, он хочет в этом же чате написать об этом. Но сам чат не может ничего сделать без агента, без MLOps. Но с агентом MLOps он может создать заявку в Jira или в вашей CRM-системе или написать вам банально на почту о том, что есть какая-то проблема. И, соответственно, мы можем дать пользователю через LLM возможность умно с нами взаимодействовать. Человеку больше не нужно искать какую-то вашу почту, номер телефона, пытаться понять, что здесь происходит, зачем и почему. Он может в привычном для себя варианте написать любыми словами то, чего он хочет, а иногда люди ещё и потеряются, [тяжело вздыхает] и ваши сотрудники не будут вынуждены взаимодействовать с этим не самым приятным образом, если им не придётся с этим человеком совершенно общаться. И опять вернёмся к RAG. На самом деле очень много моментов, где они используются. Всё-таки по сути своей это база данных, база данных будущего, могли бы сказать мы, но по сути просто нового введения не больше и не меньше. Так же, как и раньше появились объектные и более направленные SQL базы данных, а не просто MM Cache. Так и появляются постепенно векторные базы данных, ну или просто PGVector, небольшой плагин для PostgreSQL, который сильно облегчает работу и позволяет в довольно удобном виде работать со всем, что касается RAG. Не идеальное решение, но очень хорошее. И на самом деле это очень часто используется. Вы можете прочитать статью от МТС о том, как они внедряли всю эту историю и со стороны клиентов, и со стороны своих непосредственных э работников, которые уже являются операторами чатов. При помощи эмбеддинга и при помощи RAG они со спокойной душой предлагали своим операторам готовое решение того или иного вопроса просто для того, чтобы ускорить возможный ответ. Кто-то скажет: "Эти бездушные машины уже заколебали. По 200 раз пишу: чат, чат оператора, оператора, оператора". Потому что с этими машинами работать невозможно. Именно за этим мы здесь сейчас, чтобы это по возможности исправить. И поэтому будем постепенно углубляться. Но один маленький важный момент. Для того, чтобы делать это действительно хорошо, нужно собирать метрики качества. К сожалению, про них тоже много сказать сегодня не успеем, но во многом это будут метрики, которые показывают довольность ваших клиентов, качество ответа и в целом проверяют. На самом деле тут целая плеяда всего, что хотелось бы рассказать: и про ошибки, и про аналитику ввода-вывода, и про то, на какой стадии человек может отвалиться, и когда он рад, но об этом вам ничем не отвечает, потому что, ну, не каждый же человек пять ставит пять звёздочек в чате, когда он получил ответ на свой вопрос. Вот. [вздыхает] Но надеюсь, будет возможность рассказать и про LLM-оценки, и про то, как можно выявить аналитику этих интеграций. Ну а пока что перейдём к небольшому другому примеру. Я же как раз говорил про то, что мы можем вспомнить Word. Так вот, была такая история. Мне приходилось работать с созданием юридического анализа договоров. И в этой задаче у нас было два варианта. Первый — это монолитный анализ. Мы брали большой договор, обычно 15-20 страниц А4, целую плеяду терминов. И здесь приходилось, как бы это сказать, подбирать договоры, целую кучу промтов, пытаться многоуровнево проверять договор на предмет всех возможных ошибок и проблем, которые могут быть с ним. И я вас уверяю, там их целая куча, потому что все пытаются сделать свою оферту на своей стороне, максимально на своей стороне. Даже если они пишут о том, что этот документ не противоречит законам, например, Российской Федерации, это далеко не так и очень часто. И нам нужно было сделать ускоренный анализ этой работы. В компании и так уже есть юристы, и они и так каждый день проверяют договор за договором. И, как я сказал, мы сделали два варианта: систему, которая анализировала договор полностью, и систему, которая помогала юристам, скажем так, анализировать и обсуждать возможные проблемные места с чатботом. Как работало первое, я только что рассказал: полный анализ, куча вариантов промтов, куча проверок, полностью загружены статьи и не только статьи наших законов, но и с уточнениями по ним. Долго, дорого и на самом деле не очень большая эффективность. Она была примерно 20% сверху. Проще, удобней, но наши юристы всё равно всё перепроверяли руками. Просто им не приходилось проверять те места, которые уже явно были выделены. Но как только мы добавили агента в Word, который позволял им с примерно теми же механиками взаимодействовать с кусками чата, с кусками текста через чат, скорость выросла неимоверно. Люди, во-первых, поняли, что их не заменят, из-за чего начали работать несколько эффективнее и быстрее. А во-вторых, получили настоящий инструмент, который помог им ускорить работу. Это своего рода применение Claude в нашей разработке, которая не заменяет, а ускоряет, если использовать правильно. И здесь, как я сказал, почти в два раза. Не у всех, не всегда спорные моменты всё равно остаются, но это просто банально удобней. И тут, на самом деле, довольно много всего опять можно сказать. Мы будем много раз возвращаться к RAG и агентам. И, как я говорил, была история с тем, что мы делали свою полную систему полного цикла [вздыхает] для анализа документов. И, естественно, для того, чтобы понять, какой кусок ээ текста относится к какому-нибудь договору или какому-то нашему правилу или что-нибудь в этом духе, мы использовали векторные базы. Опять же, большей части это будет PostgreSQL. Я вам подскажу, это удобней. И как бы это сказать коротко, дополнительные системы для того, чтобы перепроверять текст. Сейчас я сильно не буду углубляться, потому что, опять же, это займёт крайне много времени. Но суть как раз-таки в том, что при помощи RAG можно решать не только вопросы какого-нибудь чатбота поддержки, но и вопросы работы с любыми документами. В RAG вы можете загрузить и вашу базу знаний, и части вашего кода. Ну, [откашливается] на самом деле, код постоянно загружать не стоит, потому что он изменяется слишком часто, но всё же. И можете загружать туда документы ваших поставщиков, ваших клиентов и прочего подобного. Только учтите, законы иногда не позволяют отправлять данные третьим лицам. Поэтому советую вам использовать эмбеддеры на своей стороне. Тем более, что сейчас есть очень быстрые и очень маленькие эмбеддеры.

Объясните вкратце. Понятно, хотелось бы до конкретики дойти, непонятно. Ну, в общем, я думаю, что как минимум про какие-то базовые термины, которые ты использовал, стоит сделать хотя бы короткие сноски, потому что дальше мы будем подробнее говорить про условный RAG. Я просто не знаю, можно ли это уже назвать технологиями или это концепции даже. Вот. Чтобы потом понятнее было.

Скорее, скорее уже можно назвать это технологиями, потому что мы прошли этап концепции как раз вот примерно год-два тому назад, когда уже сложилась история с MLOps и RAG как основными такими направлениями, через которые мы все работаем. Но сложилось это среди тех, кто этим пользуется. А сейчас мы это, грубо говоря, несём в мир. И в целом, наверное, стоит сказать про RAG, хотя бы коротко, так заголовочно. Это технология, которая комбинирует в себе поиск по релевантной информации, то есть как раз-таки по вашему намерению. И, как правило, туда же добавляется ещё полнотекстовый поиск для полного цикла поиска. Тут сразу маленькая сноска. Это такая опытная история. Если мы используем просто поиск по намерениям, иногда коротких запросов, вроде там "фура", вот в логистике есть такой момент, "фура", вроде человеку понятно, что это, но для LLMки и для эмбеддера машины это очень маленький контекст. Она может не получить достаточный вес для того, чтобы искать какую-то информацию. Поэтому используется ещё и полнотекстовый поиск для того, чтобы по конкретным словам находить что-нибудь полезное. Итак, summary. RAG — это то, что позволяет нам искать по смыслу. Сразу перейдём к эмбеддеру. Эмбеддер — это условная машинка, как правило, уже LLMка, которая преобразует наш текст, наш текст с намерениями в какой-то вектор небольшой. Сейчас будем разговаривать об этом как о чёрном ящике, чтобы упростить и ускорить работу. Но суть как раз-таки в том, что это машинка, которая выдаёт нам массив с векторами, ну, просто группу векторов, по которой мы можем проводить дальнейший поиск. Дальнейший поиск, как правило, проводится с уже имеющимися эмбеддированными данными, хранящимися в нашей векторной базе данных, по косинусной близости. То есть мы берём два массива с числами, берём их косинусы, суммы и так далее. Это всё у нас будет на уроках по возможности, хотя бы в какой-то базовой комплектации, чтобы мы могли это лучше понимать. К сожалению, времени на то, чтобы устраивать полное ML-представление, у нас не будет, поэтому, да, очень хотелось бы, но мне дали всего 4 месяца. Так вот, и последнее, что стоит упомянуть — это MLOps. MLOps и агенты как таковые. Агенты — это инструменты, которые позволяют LLMкам, ну давайте сократим до AI-шек, со спокойной душой ээ обращаться к каким-то внешним источникам. MLOps-ки, агенты могут быть абсолютно разными. Какие-то дают возможность общаться с CRM-ками, например, какие-то в целом могут попробовать дать возможность LLMке обращаться в сеть. Но почему такие два примера разные? Казалось бы, чтобы отправить данные в CRM, нужно обратиться в сеть. И почему бы просто не сделать обращение в сеть? Потому что слишком обширные, слишком ээ размытые агенты MLOps приводят к небольшим проблемам. LLM не всегда может корректно использовать имеющиеся агенты, поэтому их нужно делать максимально чёткими, понятными и с минимальным количеством параметров по возможности. Так, про RAG сказал коротко, надеюсь, ясно. Про эмбеддеры сказал, как про чёрный ящик пока что. И про агентов, да, системы, которые позволяют нам, скажем так, дать ручки нашим LLMкам и AI-шкам. Надеюсь, этого достаточно на данный момент, потому что углубляться мы в это будем чуть позже, чуть подробней, чуть правильней.

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

Хорошо. Потихоньку будем двигаться к рынку и прочим, очень, на самом деле, тоже важным вопросам. Как бы не хотелось, деньги и бизнес — это то, с чем приходится работать. И в целом, как я сейчас мониторил тоже историю, в том числе и на HeadHunter, и у своих знакомых, и о том, как это вообще всё работает, рост спроса есть по всему миру, в том числе даже уже по России. Дефицит кадров. Можно ли так сказать, учитывая, что на самом деле кадров, занимающихся непосредственно LLM разработкой, а не ML-разработчиков, которые отправились писать, скажем так, агентов для LLM-ок, не очень много. Поэтому есть кадры, которые имеют даже несколько большую компетенцию, чем на самом деле сейчас нужна была бы рынку, но нет кадров, которые бы действительно могли решать проблемы массово, быстро и хорошо. Поэтому я бы, да, сказал, что да, есть некоторый дефицит кадров. И в целом рынок, как я сказал, я уже несколько промониторил историю. К сожалению, собрать полноценный график не получилось, но суть какая? Есть довольно большой спрос. Люди ещё не очень понимают, что им конкретно нужно. Компании хотят LLM, они хотят AI, они хотят его везде, сейчас же и прочее подобное. Но я бы сказал, что, во-первых, им самим нужно определиться, что конкретно им нужно. Во-вторых, как бы это сказать, есть очень большой разброс по рынку, по зарплатам. Кто-то считает, что нужны лёгкие специалисты, которые при помощи Claude быстренько запилят нам сейчас LLM-интеграцию, и всё у всех будет хорошо. Зарплата 70 000. Кто-то понимает: "Нет, нужны нормальные рабочие разработчики, и они должны писать нормальный код, в том числе, может быть, при помощи и LLM-ок, AI-шек, но они должны написать хороший продукт", и там зарплата, соответственно, уже человеческая. 150 000 — это всё ещё история про то, что вот само начало говорил: "Непонятно зачем, непонятно кому, непонятно как. При помощи LLM-ки чего-нибудь там накатайте". У нормальных разработчиков зарплата идёт от 250 000 и вперёд до самого космоса, потому что нередко этим занимаются, как я опять же говорил, ML-разработчики с очень высоким окладом. И на самом деле, если вам интересен ML, если вам интересен интересна AI-разработка, то, на мой взгляд, начинать с LLM-интеграции, с LLM-разработки — это хорошая история. А сейчас мы поторопимся и дальше, потому что есть очень много разных направлений. Есть LLM-архитекторы, NLP-инженеры, AI LLM researchers, Fullstack AI разработчики. И всё это как раз-таки показатель того, что рынок ещё сам не очень понимает, что он хочет. Но я бы постарался выделить э-э три основные направления, которые можно, скажем так, уже прямо сейчас обрисовать. Первое — это разработчики, которые занимаются непосредственно ML. Прекрасные люди, могут заниматься всем, чем угодно. [тяжело вздыхает] Второе направление — это AI-инженеры, AI-разработчики, люди, которые занимаются файнтьюнингом, которые как-то разрабатывают или дорабатывают модели. Казалось бы, те же эмэльщики, но я бы сказал, что это как брать, скажем так, инженера-конструктора и его помощника. И третий аспект — это как раз LLM-разработчики или я бы назвал это LLM-интеграторы. Люди, которые будут заниматься в первую очередь разработкой инструментов, которые будут заниматься в первую очередь попыткой понять, что происходит в бизнесе, как он занимается своей работой, что можно интегрировать, как можно ускорить, как можно улучшить и так далее и тому подобное. И на самом деле это очень большой пласт работы, потому что здесь просто непаханное поле. И пробежимся ещё раз по общей стезе, потому что это основная канва всей истории. Это модели, RAG и агенты. Модели, [вздыхает] ну, наверное, все мы уже набили руку на OpenAI, Anthropic, Google, Minimx, Llama, Quanta, TypSeq, GLM, Kwi и прочее подобное. Большие провайдеры, большие модели, всё прекрасно, куча памяти, кучу денег на всё это тратить нужно. Но здесь я хотел бы оговориться о том, что есть не только такие большие модели, не только такие большие истории, есть ещё и малые модели. Как правило, ещё они и открыты, эти малые модели. У кого-то лицензия Apache, у кого-то лицензия MIT, у кого-то немного модифицированная лицензия MIT. И в целом эти модели можно использовать иногда даже на ноутбуке. Я даже напрямую скажу, у меня есть Gemma 3 на телефоне для того, чтобы побаловаться. У меня есть Gemma 4 на ноутбуке для того, чтобы тестировать агентов. И у меня есть Gemma и GPT-шка основная на основном компьютере для того, чтобы тестировать workflow. То есть полная, полную историю проведения, полный пайплайн. И в целом это удобно. У меня не какой-то сверхновый бук. У меня Mac M3 Pro на 18 ГБ. И на нём заводится простая Gemma 4 на примерно 8 миллиардов параметров от четырёх активных. Прекрасная история. Можно.

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

Если у вас есть что-нибудь посерьёзней, у меня на основном компьютере, не самая мощная, но весьма богатая оперативной памятью RX7900XTX с 24 ГБ и ещё 64 ГБ оперативной памяти, можете уже заниматься даже какой-то минимальной разработкой на своей личной машинке чего-то посерьёзнее, чем какого-то отдельного конкретного агента. И в целом есть ещё такая прекрасная штука, как эмбединги, чанки и прочие истории. На самом деле здесь стоило бы ещё оговориться о малых моделях для того, чтобы заниматься анонимизацией данных и для того, чтобы пытаться защитить себя каким-то образом. Но времени не так много, я просто упомянул, что они есть. И эмбедеры. Прямо сейчас в одном из своих личных проектов я использую гему на 300 млн параметров. Да, так сложилось исторически, что Google выпустил очень много хороших моделейк последнее время и много использую их.

И про чанки сразу оговорить, что это такое, зачем и почему. В контексте лмок [тяжело вздыхает] большая часть ээ возможных документов, которые вы захотите отправить к себе в рак, как правило, довольно большие. И это проблема. Проблема, потому что эмбединги, они, конечно, могут кушать довольно большое количество информации, но чем больше информации вы отправляете в бедер машинку, тем сильнее размывается общий контекст. И поэтому нужно эти контексты и эти тексты как можно сильнее сжимать. Кто-то пишет, что нужно отправлять в чанк не больше 200 слов, кто-то говорит не больше 500, не больше 500 символов даже иногда бывает. Всё сильно зависит от того, когда был сделан тот или иной пост, тот та или иная история и в целом какая модель использовалась. Как я сказал, сейчас используется мм гема на 300 млн параметров. И она довольно много может кушать. Она может даже кушать небольшие договоры на одну-две страницы и в целом выдавать ээ серьёзные, более или менее хорошие векторы, но всё равно нужно как-то хотя бы укладываться в 200-300 слов, на мой взгляд, потому что иногда контекст может сильно скакать между абзацами. И тут может быть абсолютно любая история. Вы можете делать чанки по 200 слов с перекрытием, когда у вас там, например, чанк берёт ээ треть предыдущего чанка и пытается таким образом у себя всё обработать. Можно делать чанки без перекрытий, можно делать повторяющиеся чанки с дополнительными весами по времени. Целая куча возможностей. Как бы я хотел обсудить это прямо сейчас, но всё же, как я говорил, что очень часто хватает простого ПГР, в большинстве историй вам, скорее всего, его тоже хватит. Поэтому предлагаю тем, кто хочет прямо сейчас пойти разбираться, загуглить ПГЕктор, если вы ещё не знаете, что это, и обращаться к нему в первую очередь.

А пока перейдём к агентам и оркестрации. Ох, оркестрация - это ещё чудо. Когда у вас пять агентов, никаких вопросов. Когда у вас 25 агентов, становится уже тяжеловато. Когда у вас сотня агентов, это уже личная боль. [вздыхает] Да. И поэтому придумали целую кучу всего, чтобы хоть как-то всё это укомпоновать. Мы можем использовать просто обычный тулкол и передавать всю информацию об имеющихся агентах и тулах непосредственно лмки. На начальных стадиях прекрасная история, работает идеально, никаких проблем. Мы можем использовать ещё и какие-то фреймворки над этой историей для того, чтобы упростить себе работу и позаботиться о своём будущем, что я вам очень советую. Да, и как я уже говорил, MCP, кто-то уже успел заметить, что это не просто агенты, это протокол для работы агентов, позволяют выделить агенты и их инструменты как скажем, сервисы, что тоже очень хорошая история, я вам очень советую. Очень помогает распределить имеющиеся инструменты и делегировать по разным отделам работу с ними. очень упрощает жизнь, нежели пытаться делать какой-то монолит. Но, возможно, когда вы начнёте работу, у вас будет монолит, потому что это удобнее для того, чтобы начинать. А к MCP вы придёте, когда у вас будет за спиной уже пара сотен инструментов. И это не единственное, что мы можем делать, потому что есть как кодовые решения, так и не особо кодовые решения. GMES есть, а Яндекс A Studio, есть Google A Studio, есть множество САС решений, которые позволяют заниматься оркестрацией агентов, выстраиванием workflow и прочего подобного. И в том числе, если вам нужно сделать какой-то прототип, я бы вам советовал: используйте условную II студию, неважно, чью будет это, Google, Яндекс или кто-то ещё. пожалейте свои нервы.

И да, снова вернёмся к зарплатным имкам. Мы чуть-чуть про ним пробежимся. Глубина знаний здесь очень сильно плавает, потому что рынок ещё не в полной мере сформирован. Вы можете быть LLML-разработчиком, а можете быть LLM-разработчиком, потому что на самом деле инструменты, которые вам нужны будут, известны и тем, и тем. Раги, агенты, оркестрации. ЛМки баллы большие, средние выстроение workflлоow и пайплайнов. И всё это прекрасно можно хоть грубо говоря фулстекера переучи, хоть ээ инженера, эмэльщика отправь этим заниматься. Ну, смотря сколько у вас есть денег. Языки э программирования. Естественно, большинство компаний хотят работать с тем, с чем они уже работали. И это абсолютно нормальная история, потому что, наверное, под все популярные языки уже есть. и библиотеки для работы с Open AI подобными AP и какие-то небольшие фреймворки или библиотеки для работы с MCP. И местами уже есть инструменты для выстраивания полноценного workflлоow. Языки программирования, ну, я бы, естественно, советовал Ja, Sharp, Go, просто потому, что они и так популярны в энтерпрайзе. Но я вам скажу, что на самом деле абсолютно нормально писать разные инструменты на разных языках в зависимости от того, чем конкретно должен заниматься тот или иной инструмент. Абсолютно нормально, если вы пишете один инструмент на C#P, потому что вам нужно работать с Microsoft Outlook. И другой инструмент вы пишете на Python, потому что, ну, просто вам так удобнее. А зарплаты? Ну, я сказал, от 70 туда не идите. До 250, это нормально. И до бесконечности куда-нибудь ракету можно отправить, потому что работает целый непочатый край.

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

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

Так, что у [откашливается] нас тут ещё весёлого? Я хочу упростить жизнь своим сидмином. Хорошая идея. Уже полностью уже полностью диагностируем проблемы на инфраструктуре ЦИС. Дальше хочется Windows, Linux сервера подкинуть и развивать. В целом, если у вас есть диагностика ЦИСКИ, использующий лмки, то это будет примерно та же самая история и для Windows, и для Linux. Естественно, там будут свои попытки получать логи и информацию о том, что работает, как работает, почему работает и какую конкретную информацию стоит отслеживать. например, нагрузку на на процессорные юниты и на оперативную память просто как пример. И возможно там заполнение постоянной памяти, чтобы у вас ээ коннекты всегда могли происходить с серверами. Но в целом самое главное, что вы можете сделать с лэмками - это задать правильный вопрос. То есть вы можете использовать любую малую, среднюю, большую лмку, но чем корректней и правильней будет вопрос к имеющейся информации, тем корректнее вы получите на него ответ. Для больших моделей, особенно с режимами размышления, вы можете задавать какие-то абстрактные вопросы, и она будет, в зависимости от своего поведения, ну, скажем так, попутно искать дополнительную информацию. Либо вы можете использовать какие-то малые модели, которые не занимаются размышлением, и просто задавать правильные вопросы или правильный набор вопросов для того, чтобы отслеживать какую-то действительно волнующую вас информацию. Условно, вы можете пытаться сливать ээ Journal в LLM и задавать ей вопрос: "Видишь ли ты тут ошибки?" Естественно, все ошибки и log у вас, скорее всего, и так падают всем, кому нужно и куда нужно, но это просто пример. И LLM, конечно, вам ответит: "Да, тут есть слово ошибка, вот же оно". И вот смотри, это условно система возвращает вам ошибку. И в этом плане можно интегрировать примерно всё, что угодно. Если будут уточнения по этому вопросу, можно будет по возможности потом обсудить.

У меня есть рабочий прототип рак ассистент для сайта университета Роулер. Ну, сайт mapap, индексация страниц. Ладно, дальше сам читай, потому что много сложных слов. Но, в общем, ты понял.

>> Краулер по сайтмапу. Индекс страниц в QRН. Мульти, да, вы говорите иногда проблемно. Мультитулинг мультику мультиязычное, я так понимаю, это слово. Не получается у меня сказать на английском. Бывает. Динг модель. Fast app, LLM через AP, webinfйс и логирование вопросов. Какой минимальный стеккер архитектуры вы бы посоветовали для продакт трейде, для такого проекта?

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

Да, модели, как я говорил, есть большие, малые, средние и какие угодно. Их уже просто тьма тьмущая. Большие, ну, тут они подписаны у нас как сервисные. Это Clo, GPT, Gy, Deepsek. Они решают общие задачи и их чаще всего подключают на первых этапах. когда не очень понятно, что конкретно можно сделать, для чего и почему. Маленький спойлер. Маленькие модели тоже бывают очень полезно в 90% случаев всех историй. А эти модели м используются потому, что нету конкретной ясности, что конкретно будет вводить на что конкретно будет вам говорить ваш клиент. Есть открытые модели GLM, КН, Гема, Lama, GPTOSS, чтобы они когда-нибудь его обновили, наконец-то. и прочее подобное. Эти модели можно развернуть у себя и не беспокоиться о каких-то правах, лицензиях и прочим подобных, потому что большая часть из них достаточно свободны. И, как правило, ну, не считая последних версий GLM, например, это довольно небольшие модели. Обычно не меньше не больше 100 млрд параметров. Ну, по крайней мере, из тех, что действительно используется в локальных версиях. И эти модели решают довольно много проблем, потому что на самом деле вам чаще всего нужно понять, что от вас хочет ваш клиент, понять, какая у него боль, какое у него намерение, какие данные он вам вводит и дополнительную информацию. И, как правило, этого уже достаточно, потому что не всегда вам нужно ээ генерировать абсолютно полный ответ системы при помощи лмки. Нередко вы можете вернуть просто готовый текст. И в этих случаях малые модели сэкономят вам не просто много денег, они сэкономят вам очень много денег. Это история о тысячах долларов и сотнях рублей.

И, собственно, критерии выбора. Как я сказал вам про использование моделей, мо вы должны опираться в первую очередь на то, как вы будете работать с вашим клиентом, ну, и как можно на этом сэкономить, потому что большинство историй уже умеет в тулколинг, в размышление и в работу с многими языками, в том числе и русским языком, естественно, тоже. Далее агенты и лol коллинг в целом. MCP как протокол - прекрасная история. Стандартизация любого решения позволяет использовать уже готовые решения и делать решения, которые вы сможете, над которыми вы сможете работать вместе с вашими коллегами, потому что вы можете написать агента примерно на чём угодно. Он будет отдавать данные по STD Outin, по SSЕшке, по вебсокету, по JRPCшке или по кочему угодно, после чего возвращать всё это Лэмке и ждать её ответа. Но это не очень практичная история. Да, MCP протокол позволяет взаимодействие не только по HTTP, но и по прочим вариантам. Но, как показывает практика, во-первых, очень многие используют MCP как HTTP, когда идёт работа в большой команде, а, во-вторых, это действительно стандартизирует работу. И вы можете прийти к вашему коллеге, посмотреть его агента, когда он где-нибудь, например, в отпуске, и решить проблемы с ним. Поэтому я не буду сейчас углубляться, почему MCP стал таким популярным. Я не буду рассказывать истории, но я вам скажу, стандартизация - это ваша история, это ваша жизнь, это то, что вам в любом случае нужно будет. Не повторяйте наших ошибок.

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

>> Такой был вопрос, есть ли какая-то принципиальная разница между Лколинг и MCP? Вроде как они, точнее, одни и другие служат для выполнения ранее определённых струринных запросов. Не очень понятно, какой инструмент использовать, когда пишешь своего агента и свободен в выборе способа вызова инструмента.

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

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

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

>> Ну, вообще, ну, скорее всего, это всё-таки, ну, то есть какой тут трейд идёт, то есть это, скорее всего, окажется дешевле, да, условно, чем какой-то AP Open, но потребует гораздо более какой-то кастомной настройки под себя или в чём как бы разница?

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

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

>> В целом пользоваться хантером в наше время довольно тяжело, просто потому что очень много проблем с HR-девочками, с очень плохо сделанными LLM АТС. очень много проблем с тем, что вакансии просто висят для того, чтобы висеть, особенно у крупных компаний. В целом я бы советовал, как это часто сейчас сделают, зайти на Headhunter, посмотреть, кто ищет, зайти на сайт конкретной компании, поискать там вакансии, поискать какие-то, возможны контакты и связаться напрямую. Это нередко, говорят, сейчас помогает сильнее, особенно, если у вас нет своих знакомых HR в каких-нибудь крупных компаниях. [тяжело вздыхает] А так, принципиально мы можем посмотреть Headhunter просто для того, чтобы показать, какие сейчас есть вакансии и насколько они бывают разные. Где-то конкретно ищут хороших специалистов с конкретными ожиданиями. работа с рагом, работа с конкретными лмками, работа с агентами и работа с каким-нибудь конкретным языком, в который к которому компании привыкли. Но, к сожалению, я не могу обещать, что если вы прибежите на эту вакансию, вас тут же возьмут.

Если сегодня вы уже поняли, что тема рагов внедрения разнообразных м и пайплайнов, ориентируемых на этот бизнес, вам интересно, и вы хотите вот с каждым блоком, про который мы сегодня говорили из компетенции, разобраться подробнее и на понятных практических проектах, то, возможно, вам стоит присмотреться к курсу разработчик. Этот курс будет актуален разнообразным IT-специалистам, разработчикам, тем ледам, техледам, которые хотят, э, работать сM и интегрировать, э, через апии, управлять промтами, контекстами, экономики токенов и делать полноценные, собственно, продукты, проекты, интегрированные в реальные процессы с компанией. Вот. А как вы к этому придёте, какова программа курса и какой путь, собственно, пройдёт студент? Я бы тебя уже там попросил чуть подробнее сейчас прокомментировать,

>> да? А на самом деле тут довольно много всего будет. Это базовое распределение и базовые понятия, которые будут рассматриваться на основе Яндекс Studio. Почему так? Потому что, к сожалению, не у всех есть машинки с хотя бы шестью и болею гигами оперативной памяти свободный, которые требуются для запуска каких-нибудь лмок, которые умеют работу с тулами. Но этот момент мы будем решать постепенно. И что ж, к этому тоже прийдём. А пока минимальные workflow, минимальные MCP, raги и прочее через Яндекс Studio для того, чтобы разобрать основную базу. Самое важное, самое интересное, то, с чем вы в любом случае будете. После этого можно начинать какой-то свой маленький бизнес на какой-нибудь свой маленький САС. Затем будут Гермес и прочие локальные системы, которые работают по примерно тем же принципам. С единственным исключением вы можете развернуть это у себя, а не держать в САЗ облаке какой бы то ни было компании. Здесь будет небольшое углубление во все темы, в том числе

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

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

Там же мы поговорим и про использование малых моделей чуть подробнее. и про использование моделей на сосредоточенных на эмбедингах, на защите персональных данных, на защите вас от атак злоумышленников и прочие подобные полезные милости и приятности. И в конце концов у нас будет развёртка своего корпоративного решения на каких-то мощностях, которые позволит полностью развернуть модели у себя, построить полностью свой workflлоow и выдать некоторую базу для разработчиков OML OPS. Есть базы для разработчиков Pro GitOPS, DevOps и прочее подобное. А так будет теперь ещё и ML OBS. Для этого уже придумали новое слово.

Что-нибудь [откашливается] ещё?

>> Наверное, можно вкратце про проекты, потому что, например, для меня не очевидно, почему они в таком такой последовательности идут. То есть условно почему HДESK агенты мы можем уже на первом модуле, да, на первой в первой части курса спроектировать. То есть это более это наиболее простой из проектов, условно, который есть. И как это работает?

В общем, >> как бы это выразиться, будет относительно простой вариант. Скорее даже небольшой помощник для разработчика из разряда сходи в GRO, посмотри какие задачи, сходи в Яндекстрекер там или любой другой условный источник задач. Сходи в гит, какие там есть по нему или пулреквестов. в зависимости от того, какой хаб вы используете, GitHub, GitLab, там может у кого-то отечественные решения и прочее в этой истории.

Дальше на Гермессе и прочем подобным мы будем разбирать работу с условным интернет-магазином или что-нибудь в этом духе для того, чтобы на знакомых понятиях, на знакомых историях разобрать, что с этим можно делать, как внедрять, для чего, зачем и почему. как с этим жить и почему теперь это не просто нужно, а необходимость.

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

>> О'кей. Ещё был вопрос актуальный про базовые требования для того, чтобы начать учиться. Собственно, на курсе понятно, что не нужно быть имеil-инженером, потому что, да, мы не настолько глубоко лезем в >> н модели и вот это всё, наверное, да. А, но с точки зрения разработки это самое основное. Вот что нужно точно знать, представлять, может быть, какой опыт иметь иметь, [фыркает] потому что мы же не будем, наверное, с нуля, да, учить тому, какие есть протоколы, что такое АИ и как всё это работает.

>> Да, да, да. Но я бы сказал, что в целом не нужно быть синьор разработчиком. То есть >> скорее всего, если вы человек умный, а я на это рассчитываю, вам хватит знаний Jниor П, midлle минус. То есть, если вы можете писать код, если вы можете его читать и понимать, если вы знаете какой-то один язык, там хотя бы pтон go, шарп, ноду, да-да, frontend friendendly, как говорится, и прочие подобные распространённые языки, вы сможете решать задачи и решать м примеры просто на своём языке. Конкретный язык не имеет значения. Я даже скажу, что я не буду ругаться за использование клода или кодекса в решении этих задачек. Просто я попрошу вас сделать немножечко побольше. Вы же работаете быстрее. [смех]

>> Угу.

>> Да.

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

>> Желательно, но не критично. Я скажу, что это желательно представлять, потому что хотелось бы, чтобы человек сразу понимал, что происходит. Но если не будет хватать какой-то информации из разряда, как запросики потипишечке и по ттипишечке бегают, >> э желательно будет доучить по ходу курса, потому что мы не будем, скорее всего, останавливаться на этих моментах, как и не будем останавливаться на ilвопросах. Может, там просто какую-то часть затронем. Она есть, мы её показали. Дальше вы можете идти сами в эту сторону. Вот на том же уровне и прочие элементы вроде работы с, не знаю, с базами данных. То есть, если вы совсем не знаете SQL, это, конечно, нехорошо, но научиться вы всё равно сможете.

>> Угу. О'кей. Пару слов ещё скажу про авторов. Собственно, не зря Русам рассказывает сегодня про программу, потому что он принимал непосредственно э-э отношение в её составлении, также будет активно участвовать в курсе. Но руку здесь приложил и Кирилл Макевнин, которого, наверное, сильно представлять не нужно. Но если вы не знаете Кирил, то это сооснователь Хекстата, который ээ помимо Хекстата, который и так уже сколько, 8 лет, наверное, существует, ещё до этого был и VPO офнринг, и, ээ, CTO. в отдел собственной веб-студии, если не ошибаюсь. В общем, огромное количество лет разработки. Э, но важнее, наверное, даже то, что прямо сейчас в Хекстате, на самом деле, он активно тоже и сам интегрирует разнообразные, э, элмки, строит рак вокруг нашего ээ чатбота, который работает со студентами, помогает имму проходить курсы. в общем, ведёт, да, канал и организованное программирование, активно общается, в том числе на эти темы в подкасте Организованное программирование. Поэтому Кирилл тоже заинтересованный человек, который имеет непосредственное отношение к этому курсу.

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

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

>> Я могу тебе сразу намекнуть, что там будет [смех] абсолютное непонимание рынка. поиск, кстати говоря, во многом руководящих должностей, потому что бизнес не знает, что это, почему это, но они этого хотят.

>> Угу.

>> И, [откашливается] естественно, те, кто нашли себе уже руководители отдела по лм разработке АИ интеграции, они начинают искать, собственно, рабочих по этой специальности, которых как бы ещё нет. Поэтому бедные HR-девочки бегают и спрашивают: "А у вас есть 3 года опыта по интеграции искусственного интеллекта?"

>> А как его всего 2 года интегрируют во всём мире? То есть у вас нет 3 лет [смех] по интеграции искусственного интеллекта?

>> А, да, тут, к сожалению, только сочувствовать. Так, а, да, я хотел у тебя спросить, собственно, какие ключевые слова искать. Мне пришёл к голову, собственно, основное - это LLM.

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

>> А, как я говорил, есть попытки найти специалистов ээ на 70.000 руб. Довольно забавный, на мой взгляд.

>> [тяжело вздыхает]

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

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

>> это что такое? Может быть Lмl программист. Обычно всё-таки инженер пишет. То есть это не факт, что

>> тут, да, скорее всего, имеется в виду ML-ненер, но точнее я не скажу, честно говоря, сам не сталкивался.

>> В сомах, не знаю, сколько это будет в рублях или долларах.

>> Ну, это похоже хотя бы по названию, да?

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

>> Угу. Так, разработки общения ль агентов домици создания ре которые интегрирует визуальное восприятие. Ладно, это, наверное, сложно. О'кей, давай. Я нашёл штуки четыре вакансии, которые в теории похожи. Можем в них залезть и посмотреть, что там будет внутри.

>> Э, руководитель направления обучения LLM с BII комьюнити. Что хотят? Анализ современных методов обучения. Но это нет, это, кажется, ДС больше. Да, да, это ДС.

>> Да, это >> о'кей. Идём. На самом деле у Сбербанка тоже есть вакансии на внедрение ЛМ, в том числе и юридическое. Не так давно видел, наверное, недели три-четыре тому назад они искали специалистов в команду э разработки решений по анализу и составлению юридических документов.

>> Угу.

>> И это вот как раз одна из тех историй, которые я рассказывал.

>> Это внутрей сервис история была про Сбербан.

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

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

>> Угу.

>> Вот это вот всё.

>> Ну вот, собственно, >> мы описывали пример.

>> Одно из ключевых слов - это интеграция и связь с ллэмками. Перечисляем, конечно, все возможные эллэмки, которые только они могут вспомнить. Потом пишем, с чем хотим. ЦРМки, 1С, база данных, мессенджера, пишки, все документы бухгалтерии и вся история картотеки, которая у нас сохранилась с незапамятных времён. Всё это, конечно, хочется. И это один из элементов. Кстати говоря, ещё одно ключевое слово, которое можно искать - это рак. Так как сейчас рынок ненасыщенный, для большинства компаний один только рак - это уже очень серьёзная история. И они хотят хотя бы хотя бы всю свою базу знаний запихнуть в рак, чтобы просто удобнее ей пользоваться. Ну и, соответственно, это тоже можно искать. И вот здесь же построение мультиагентных систем. Это, собственно, написание агентов, написание Аиша, МCпишек. Ну, по протоколу MCP- это просто мой постоянный совет, как лучше работать. Не пишите просто тул колы, пишите МCпишки, желательно внешними сервисами. И мультиагентность тут, скорее всего, будет выражаться в том, что нужно будет целую кучу агентов написать на все возможные случаи жизни, вплоть до того ээ Главдир мог себе заказать кофе при помощи чатбота. [смех] А так, э, тут же могут быть истории и из разряда автоматической системы продаж. В B2B это как раз появляется. Уже даже анекдот небольшой на этот повод появился. И автоматическая система закупок, которая будет пытаться вечно: "Дайте нам дешевле, дайте нам дешевле, дайте нам дешевле". [вздыхает] Вот и, собственно, оценка эффективности - это то, что мы тоже проговаривали, но очень вскольз. Это оценка внедрения по основным критериям, кто стал работать быстрее, в какой момент клиенты стали довольнее и методы внедрения этого всего и попытки понять, как с этим работать.

>> В общем, быть чуть-чуть продактом ещё над разработкой, чтобы не только внедрять, но и оценивать эффективность.

>> Да. Да.

>> И, к сожалению, это то, с чем нам придётся жить, скорее всего, в ближайшее время.

>> Кстати, вот. Да, >> я с вами говорят откры коммерческое мышление, как устроение беспроцент, воронки продаж, клиентский сервис, документ оборота. Это, кстати, перечисляет основные, собственно, истории, куда они хотят это внедрять, видимо,

>> да. А и тут сразу стоит уточниться, что бизнес всегда хочет, чтобы конечный работник был и шведцы, и жнецы, на дуде, и грейц. И там всякие непристойности, наверное, пропустим из этих шуток. А так вот, конечно же, бизнес хочет, чтобы человек был и разработчиком, и продуктом, и бизнес-аналитиком, и бизнес выстраивателем процессов, то бишь интегратором. И, конечно, можно соблюдать все эти возможные специальности в себе, но я бы сразу сказал, что желательно выявить какого-то, э, эксперта в том или ином направлении и пытаться работать вместе с ним, потому что у ЦРМки, скорее всего, есть уже какой-то свой разработчик, свой эксперт. Он может быть даже где-то на внешнем контуре в какой-то компании, занимающейся поддержкой. Он может быть просто специалистом, который сидит в ЦРМке и бегает по своим коллегам, объясняет, как им пользоваться. Вот тот самый продажник, который ещё и чуть-чуть администратор. Этот человек может иметь абсолютно любое лицо, но это именно тот человек, который позволит вам выстроить всю дальнейшую работу.

>> Сори, я там одну вакансию уже закрыл, которая не подошла. Она называлась A Solutions Engнеer. И по факту это был, знаешь, как это ээ как sales eng иногда пишут. По факту просто продажник. Это было то же самое. То там, видимо, какая-то компания, которая делают под заказ ээ компаниями, там типа лезть в процессы потенциальных заказчиков, придумывать для них решение и потом уже составлять ТЗ для разработчиков. Но типа Solutions, инженеров. Поэтому таких тоже отдельно кто-то ищет. Но это аутсорс, условно, скорее всего. что это скорее интегратор, тот самый человек, который придёт, найдёт всех подходящих специалистов и будет постепенно интегрировать. Это на самом деле не то чтобы не подходящая вакансия, потому что на этом при желани конкретно, безусловно, то есть >> в не в не в создание это руками, а в продажу всего этого и описание для клиента ценностей.

>> Хорошо, понятно. Но сразу можно сказать, что сейчас это будут расхватывать как горячие пирожки, как в своё время расхватывали интеграторов ЦРМ. Как только поняли, что такое ЦРМ, почему это нужно и как это помогает, в отличие от постоянной работы в Экселе, этих специалистов начали расхватывать просто как горячие пирожки. И там, по-моему, это было в начале десятых и примерно до середины десятых можно было искать вакансии ЦРМ Интегратор или что-нибудь в этом духе, особенно где-нибудь на фрилансе.

>> Угу.

>> Это почти такая же история, только в этот раз это не просто какие-то системы для фиксации информации, а полноценные машинки, которые могут задаваться вопросами.

>> Угу. О'кей, давай ещё одного конте посмотрим. Просто и так это время немного занимает. Не знаем, сколько это в рублях. Можете сами перевести, но это хотя бы вот прямо похоже тоже на то, о чём мы говорим. И в принципе, ну, если я нашёл даже эти несколько вакансий быстро там за 5 минут х, наверное, это не такой плохой показатель. Можно и больше по ключам самого типа рак найти. Э ту-ту-ту-ту-ту-ту-ту. Ээ ну IT-компании с десятками продукт 1.000 клиентов поддержки обслужения многорутинг процессов отписани коставления счётов инструктуру. То есть это тоже, видимо, да, какой-то интегратор, подрядчик, в общем, ээ, обслуживатель других ээ клиентов, правильно, видимо.

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

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

>> Угу. Ну, тут просто такие максимальные типы определять, что отдаём, как это будет работать, >> да, >> обеспечивать контроль этого. Вот из интересного, чего мы не обсуждали, наверное, тут только история про то, что будет плюсом работы девопсом. может быть, тоже имеет смысл перечислить какие-то штуки, которые относятся к девопсу, которые мы либо перечисляли, либо не перечисляли из навыков, которые вот такому условному [фыркает] разработчику нужны будут. Что они могут иметь в виду какими-нибудь под девопсовскими скилами?

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

>> О'кей. Ну ладно, осталось узнать только, сколько это 70-80.000 сум в рублях. Ээ и в принципе можно и можно устраиваться. Ладно, на самом деле я говорил, да, что с покатими может быть странно, поэтому мы это оставили на конец. Но тем не менее, я надеюсь, что вы хотя бы посмотрели, что они есть, что можно искать по ключом свом LMК и так далее. Ограничивается только х, наверное, ни в коем случае не имеет смысла. Опять же, туда же идут все стандартные рекомендации про сайты компаний, Telegram-каналы и рефералов, ээ, LinkedIn и любые другие возможности, просто потому что сейчас, в принципе, на эти рынке устроиться куда-то сложно. Вот. Но мы сегодня собрались не для этого, а для того, чтобы показать вам вообще, кто такой в нашем представлении ИОМ разработчик. И, конечно, рассказать про наш курс М разработчик. В остальном, как будто бы, я не вижу других вопросов, комментариев, поэтому спасибо большое, что были с нами. Русм, спасибо тебе большое, что помог нам это мероприятие подготовить и был в эфире. Вот. Если хочешь что-нибудь сказать в конце, может быть, своим будущим студентом, ээ то, пожалуйста, сидите твоя минута, не знаю, две, полторы.

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

>> Будем надеяться, что так, что действительно и прочие современные, в общем, мы мы техноптимисты и и верим, что эти возможности могут ещё и дать вам новых интересных карьерных возможностей. Поэтому спасибо, что были с нами. С кем-то увидимся уже в качестве студентов Хекстета. И до новых встреч, может быть, на других мероприятиях Хекстата. Всем пока, >> хорошего вечера. M.