🔥 Вместе с Selectel собрали коллег на встречу «ИИ-шашлыки: Well done. Доводим AI до окупаемости»
Своим опытом поделились Александр Опрышко, управляющий партнёр KTS, и Владислав Кирпинский, директор направлений облачной интеграции Selectel. Вместе обсудили:
💬 сценарии автоматизации поверх базы знаний
💬 выбор инфраструктуры для AI-решения: облако, изоляция или on-prem
💬 переход от RAG к фабрике агентов и окупаемость ИИ на масштабе
Было много инсайтов, интересных знакомств и жарких дискуссий. А атмосферу встречи лучше покажут фотографии — листайте, чтобы узнать, как это было 👀
Своим опытом поделились Александр Опрышко, управляющий партнёр KTS, и Владислав Кирпинский, директор направлений облачной интеграции Selectel. Вместе обсудили:
Было много инсайтов, интересных знакомств и жарких дискуссий. А атмосферу встречи лучше покажут фотографии — листайте, чтобы узнать, как это было 👀
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18❤1
Агенты и агентские автоматизации
В прошлом посте писал про Spec-Driven Development, который даёт новый уровень абстракции в nocode-разработке. Теперь сузим скоуп и посмотрим на агентские автоматизации.
Классический сценарий AI-агента — это чат для взаимодействия с пользователем. Сначала такие чатики практически ничего не умели и выступали в роли поисковиков и собеседников. Потом появились инструменты (MCP), которые подключают агента к внешним системам и позволяют выполнять действия. Но принцип оставался тем же: пользователь что-то попросил — ИИ сделал.
Агентская автоматизация работает иначе. Она даёт возможность автономного запуска агентов и делает их полноценными участниками бизнес-процессов.
По сути, это набор детерминированных шагов, внутри которого агенты выполняют действия и при необходимости обращаются к человеку за согласованием плана или подтверждением. Так называемый human in the loop.
Простой пример: есть Excel-таблица, каждую строку которой нужно проскорить по определённым критериям. Процесс можно собрать так:
▫️ сценарий получает строки из таблицы;
▫️ запускает агента и последовательно скорит строки;
▫️ передаёт результат обратно в таблицу или отправляет во внешнюю систему.
Это сочетание жёсткой логики и нейросетевой гибкости даёт два важных плюса.
Предсказуемость. Агент не выдумывает процесс, а идёт по заранее определённым этапам. При необходимости инженеры могут собрать датасеты и улучшить качество агентских шагов.
Экономика. Для подобных задач агент может использовать быстрые и дешёвые модели, что увеличивает его ценовую эффективность.
Конечно, сценарии могут быть гораздо сложнее: один агент вызывает другого, отдельные шаги запускают дополнительные сценарии. Но в основе остаётся детерминированный цикл.
Именно в этой парадигме мы развиваем новый продукт — Agent Platform. Он позволит предметным специалистам самостоятельно создавать агентов и объединять их в цепочки для автоматизации своих процессов без разработчиков.
Сейчас проводим закрытые пилоты. Скоро расскажем подробнее про работу продукта и откроем запись на демо.
#александр_опрышко
В прошлом посте писал про Spec-Driven Development, который даёт новый уровень абстракции в nocode-разработке. Теперь сузим скоуп и посмотрим на агентские автоматизации.
Классический сценарий AI-агента — это чат для взаимодействия с пользователем. Сначала такие чатики практически ничего не умели и выступали в роли поисковиков и собеседников. Потом появились инструменты (MCP), которые подключают агента к внешним системам и позволяют выполнять действия. Но принцип оставался тем же: пользователь что-то попросил — ИИ сделал.
Агентская автоматизация работает иначе. Она даёт возможность автономного запуска агентов и делает их полноценными участниками бизнес-процессов.
По сути, это набор детерминированных шагов, внутри которого агенты выполняют действия и при необходимости обращаются к человеку за согласованием плана или подтверждением. Так называемый human in the loop.
Простой пример: есть Excel-таблица, каждую строку которой нужно проскорить по определённым критериям. Процесс можно собрать так:
▫️ сценарий получает строки из таблицы;
▫️ запускает агента и последовательно скорит строки;
▫️ передаёт результат обратно в таблицу или отправляет во внешнюю систему.
Это сочетание жёсткой логики и нейросетевой гибкости даёт два важных плюса.
Предсказуемость. Агент не выдумывает процесс, а идёт по заранее определённым этапам. При необходимости инженеры могут собрать датасеты и улучшить качество агентских шагов.
Экономика. Для подобных задач агент может использовать быстрые и дешёвые модели, что увеличивает его ценовую эффективность.
Конечно, сценарии могут быть гораздо сложнее: один агент вызывает другого, отдельные шаги запускают дополнительные сценарии. Но в основе остаётся детерминированный цикл.
Именно в этой парадигме мы развиваем новый продукт — Agent Platform. Он позволит предметным специалистам самостоятельно создавать агентов и объединять их в цепочки для автоматизации своих процессов без разработчиков.
Сейчас проводим закрытые пилоты. Скоро расскажем подробнее про работу продукта и откроем запись на демо.
#александр_опрышко
👍7❤4
Разработали AI-поиск по сотням документов Level Group и получили точность ответов выше 90%
В базе знаний девелопера хранится множество регламентов и инструкции по разным направлениям. При этом данные для ответа на один вопрос могут быть разбросаны сразу по нескольким источникам, объём информации растёт, появляются дубли и устаревшие документы. Всё это замедляет работу с базой знаний и отнимает время сотрудников.
Чтобы инженеры и менеджеры быстрее получали точные ответы, мы вместе с командой Level Group запустили ИИ-ассистента. Обычно для ускорения поиска используют классический RAG, где система ищет фрагменты по семантической близости. Но для процессов в девелопменте у такого подхода есть ограничения: модель не видит связей между разрозненными чанками и теряет общий контекст.
Для ИИ-ассистента Level Group мы спроектировали архитектуру на базе KTS AI Platform и подключили к ней корпоративную wiki. При разработке решения использовали фреймворк LightRAG, который объединяет векторный и графовый поиск. Такой подход позволяет связывать разрозненные документы в единые смысловые кластеры.
Например, сотрудник спрашивает о порядке действий при обнаружении дефекта. Векторный поиск найдёт шаблон акта осмотра. Графовый свяжет его с регламентами по расчётам с подрядчиками, строительными ГОСТами и сроками устранения. LLM получит полный контекст и сможет точнее сформулировать ответ.
Чтобы быстрее получить измеримый результат и подтвердить эффективность решения перед масштабированием, мы сначала запустили пилот на одном источнике. На подготовленном массиве данных точность ответов превысила 90%.
Подробнее о том, как подготовили базу данных к подключению LLM и объединили два подхода к поиску, читайте в статье.
В базе знаний девелопера хранится множество регламентов и инструкции по разным направлениям. При этом данные для ответа на один вопрос могут быть разбросаны сразу по нескольким источникам, объём информации растёт, появляются дубли и устаревшие документы. Всё это замедляет работу с базой знаний и отнимает время сотрудников.
Чтобы инженеры и менеджеры быстрее получали точные ответы, мы вместе с командой Level Group запустили ИИ-ассистента. Обычно для ускорения поиска используют классический RAG, где система ищет фрагменты по семантической близости. Но для процессов в девелопменте у такого подхода есть ограничения: модель не видит связей между разрозненными чанками и теряет общий контекст.
Для ИИ-ассистента Level Group мы спроектировали архитектуру на базе KTS AI Platform и подключили к ней корпоративную wiki. При разработке решения использовали фреймворк LightRAG, который объединяет векторный и графовый поиск. Такой подход позволяет связывать разрозненные документы в единые смысловые кластеры.
Например, сотрудник спрашивает о порядке действий при обнаружении дефекта. Векторный поиск найдёт шаблон акта осмотра. Графовый свяжет его с регламентами по расчётам с подрядчиками, строительными ГОСТами и сроками устранения. LLM получит полный контекст и сможет точнее сформулировать ответ.
Чтобы быстрее получить измеримый результат и подтвердить эффективность решения перед масштабированием, мы сначала запустили пилот на одном источнике. На подготовленном массиве данных точность ответов превысила 90%.
Подробнее о том, как подготовили базу данных к подключению LLM и объединили два подхода к поиску, читайте в статье.
🔥11👍4
Эпоха жирного SaaS заканчивается
Ещё лет пять назад мы жили так: нужна функциональность — ищешь подходящий инструмент, смотришь его возможности и решаешь, что в своих процессах переделать, с чем смириться, а что донаращивать надстройками и плагинами. И только после этого начинается работа.
Классический пример — JIRA. Инструмент с кучей ограничений, вокруг которого вырос целый рынок плагинов, пытавшихся донастроить отсутствующую функциональность. В итоге получалось дорогое решение, прикрученное скотчем и верёвочкой: вроде работает, но каждая смена процесса — риск, что что-то отвалится или придётся докупать очередную надстройку.
С приходом AI-инструментов для разработки скорость поставки решений выросла, а трудозатраты сократились. Появился ряд продуктов — в их числе моя OKRsana, — которые можно гибко настраивать под себя и запрашивать у поставщика кастомизации, если это по карману (а по карману это обычно только энтерпрайзу).
Но часть лидов, приходивших ко мне, вообще не хотели внедрять систему целиком и перекраивать процессы под неё. Им были нужны точечные автоматизации. Например, быстрые проверки OKR перед тем, как драфт уйдёт на встречу, или на выравнивание целей по горизонтали и вертикали. И тогда, и сейчас это были кастомные задачи — «возьмётесь ли сделать».
Сегодня мы можем предложить доменным специалистам самим создавать таких агентов без разработки. И дело здесь не только в стоимости — решение у опытной команды дешёвым не бывает.
Суть в том, что кастомных агентов нужно поддерживать и развивать: процессы меняются, появляются новые вводные, всегда хочется что-то докрутить. Если агента настраивает и обновляет сам специалист, цикл «есть идея — реализовали — проверили» сокращается в разы. Про этот сдвиг отдельно писали в постах о Spec-Driven Development как новом уровне no-code и агентских автоматизациях.
Долгое время это была задача из элитарных. В больших компаниях сложность создавали согласования: почему разработка должна ставить в приоритет внутренние проекты с трудносчитаемой экономикой, а не задачи внешнего контура. В маленьких своих разработчиков нет, поэтому делать просто некому. Сейчас мы в эпохе новых возможностей ИИ, и вопрос в другом: как сделать среду для создания, проверки и мониторинга агентов настолько простой и дружелюбной, чтобы желание автоматизировать не гасло через пять минут после входа.
KTS разрабатывает продукт — Agent Platform, который закрывает эту потребность. Он даёт доменным специалистам создавать агентов и объединять их в цепочки для автоматизации своих процессов без разработчиков.
В основе — три принципа:
Простой интерфейс. Как сборка шведской мебели: в комплекте все детали и инструкции, идёшь по шагам, и решение собирается.
Надёжность. Перед выходом в прод агент проходит эвал-, юнит- и интеграционные тесты. Получается решение для промышленного использования, где исключена случайность в качестве ответов.
Дешёвый и простой вход. Можно начать в облаке, а при необходимости (масштаб, требования безопасности) перейти в закрытый контур, сохранив всех агентов и их работу.
Если вам нужно автоматизировать через ИИ часть бизнес-процессов до конца года, пишите, попробуем помочь. Мы предлагаем удочку, а не подсаживаем на постоянные походы в рыбный магазин.
#иван_лавров
Ещё лет пять назад мы жили так: нужна функциональность — ищешь подходящий инструмент, смотришь его возможности и решаешь, что в своих процессах переделать, с чем смириться, а что донаращивать надстройками и плагинами. И только после этого начинается работа.
Классический пример — JIRA. Инструмент с кучей ограничений, вокруг которого вырос целый рынок плагинов, пытавшихся донастроить отсутствующую функциональность. В итоге получалось дорогое решение, прикрученное скотчем и верёвочкой: вроде работает, но каждая смена процесса — риск, что что-то отвалится или придётся докупать очередную надстройку.
С приходом AI-инструментов для разработки скорость поставки решений выросла, а трудозатраты сократились. Появился ряд продуктов — в их числе моя OKRsana, — которые можно гибко настраивать под себя и запрашивать у поставщика кастомизации, если это по карману (а по карману это обычно только энтерпрайзу).
Но часть лидов, приходивших ко мне, вообще не хотели внедрять систему целиком и перекраивать процессы под неё. Им были нужны точечные автоматизации. Например, быстрые проверки OKR перед тем, как драфт уйдёт на встречу, или на выравнивание целей по горизонтали и вертикали. И тогда, и сейчас это были кастомные задачи — «возьмётесь ли сделать».
Сегодня мы можем предложить доменным специалистам самим создавать таких агентов без разработки. И дело здесь не только в стоимости — решение у опытной команды дешёвым не бывает.
Суть в том, что кастомных агентов нужно поддерживать и развивать: процессы меняются, появляются новые вводные, всегда хочется что-то докрутить. Если агента настраивает и обновляет сам специалист, цикл «есть идея — реализовали — проверили» сокращается в разы. Про этот сдвиг отдельно писали в постах о Spec-Driven Development как новом уровне no-code и агентских автоматизациях.
Долгое время это была задача из элитарных. В больших компаниях сложность создавали согласования: почему разработка должна ставить в приоритет внутренние проекты с трудносчитаемой экономикой, а не задачи внешнего контура. В маленьких своих разработчиков нет, поэтому делать просто некому. Сейчас мы в эпохе новых возможностей ИИ, и вопрос в другом: как сделать среду для создания, проверки и мониторинга агентов настолько простой и дружелюбной, чтобы желание автоматизировать не гасло через пять минут после входа.
KTS разрабатывает продукт — Agent Platform, который закрывает эту потребность. Он даёт доменным специалистам создавать агентов и объединять их в цепочки для автоматизации своих процессов без разработчиков.
В основе — три принципа:
Простой интерфейс. Как сборка шведской мебели: в комплекте все детали и инструкции, идёшь по шагам, и решение собирается.
Надёжность. Перед выходом в прод агент проходит эвал-, юнит- и интеграционные тесты. Получается решение для промышленного использования, где исключена случайность в качестве ответов.
Дешёвый и простой вход. Можно начать в облаке, а при необходимости (масштаб, требования безопасности) перейти в закрытый контур, сохранив всех агентов и их работу.
Если вам нужно автоматизировать через ИИ часть бизнес-процессов до конца года, пишите, попробуем помочь. Мы предлагаем удочку, а не подсаживаем на постоянные походы в рыбный магазин.
#иван_лавров
🔥6❤2👍2🎉1
Больше возможностей для работы с изображениями в Agent Platform
▪️ Добавили топовые графические модели от ведущих провайдеров:
— Google, Nano Banana 2: отличается высоким уровнем детализации, может создавать изображения в разрешении до 4K и точнее понимает контекст сложных запросов
— OpenAI, GPT Image 2: корректно добавляет текст на изображения, стабильнее работает в сериях и генерирует реалистичный UI и скриншоты
— Black Forest Labs, Flux.2: умеет делать фотореалистичные кадры и учитывает данные из открытых источников в реальном времени
Полный список моделей смотрите в комментариях.
▪️ Расширили функциональность для работы с изображениями. Теперь кроме анализа с помощью модели и генерации, доступно редактирование уже созданных иллюстраций через текстовое описание.
Тестируйте обновления в Agent Platform и делитесь впечатлениями
▪️ Добавили топовые графические модели от ведущих провайдеров:
— Google, Nano Banana 2: отличается высоким уровнем детализации, может создавать изображения в разрешении до 4K и точнее понимает контекст сложных запросов
— OpenAI, GPT Image 2: корректно добавляет текст на изображения, стабильнее работает в сериях и генерирует реалистичный UI и скриншоты
— Black Forest Labs, Flux.2: умеет делать фотореалистичные кадры и учитывает данные из открытых источников в реальном времени
Полный список моделей смотрите в комментариях.
▪️ Расширили функциональность для работы с изображениями. Теперь кроме анализа с помощью модели и генерации, доступно редактирование уже созданных иллюстраций через текстовое описание.
Тестируйте обновления в Agent Platform и делитесь впечатлениями
❤5👍2
Моя работа плохо ложится в трекеры. Поэтому её забрал AI-ассистент
У нашего Head of QA, Романа Авдонина, много задач, которые не оставляют следов в привычных трекерах. За день он может обновить матрицу грейдов, согласовать новый процесс, что-то доработать во внутреннем инструменте, провести несколько встреч. А раз в полгода проходит перформанс-ревью — и приходится по чатам, календарю и заметкам восстанавливать контекст. Раньше на такой квест уходило до двух дней.
Вести рабочий журнал руками Роме не хотелось, поэтому он собрал под свою задачу AI-ассистента из Claude Code, Obsidian и markdown-файлов.
Роман общается с Claude обычным текстом и рассказывает ему, чем занимался, а ещё закидывает транскрипты созвонов. Вся память хранится в markdown-файлах, Obsidian служит интерфейсом к ним, а привязки к конкретной модели нет.
Ассистент раскладывает информацию по нужным разделам и запускает часть автоматизаций по расписанию. Контур состоит из нескольких частей:
Журнал. Каждый день ассистент заводит отдельную запись и фиксирует новости, решения и прогресс. Он сам определяет, что оставить в журнале, превратить в задачу или добавить в заметку о человеке.
Канбан-доска. Сюда переехала вся мелкая работа, которую раньше приходилось держать в голове. Ассистент создаёт и двигает карточки между статусами, фиксирует историю изменений и вносит пометки.
Встречи и люди. Из транскрибации созвонов ассистент вытаскивает договорённости, экшн-айтемы и обновляет заметки о людях. Перед следующей встречей может собрать план разговора.
Автоматизации. Сейчас их две: вечером ассистент синхронизирует цели между Google-таблицей и журналом, а к утру понедельника готовит дайджест для 1:1 с руководителем. Раньше такую картину приходилось собирать по чатам час-полтора.
Копилка достижений. Заметные результаты параллельно складываются в отдельную папку. Перед следующим перформанс-ревью ассистент составит черновик селф-ревью с датами и ссылками на журнал.
В статье Роман подробно показал, как устроен контур, описал правила безопасности и оставил готовый промпт, который можно вставить в Claude Code, Cursor или другой инструмент. Агент проведёт небольшое интервью и соберёт похожее решение уже под вас.
Почитать статью и забрать промпт себе
У нашего Head of QA, Романа Авдонина, много задач, которые не оставляют следов в привычных трекерах. За день он может обновить матрицу грейдов, согласовать новый процесс, что-то доработать во внутреннем инструменте, провести несколько встреч. А раз в полгода проходит перформанс-ревью — и приходится по чатам, календарю и заметкам восстанавливать контекст. Раньше на такой квест уходило до двух дней.
Вести рабочий журнал руками Роме не хотелось, поэтому он собрал под свою задачу AI-ассистента из Claude Code, Obsidian и markdown-файлов.
Роман общается с Claude обычным текстом и рассказывает ему, чем занимался, а ещё закидывает транскрипты созвонов. Вся память хранится в markdown-файлах, Obsidian служит интерфейсом к ним, а привязки к конкретной модели нет.
Ассистент раскладывает информацию по нужным разделам и запускает часть автоматизаций по расписанию. Контур состоит из нескольких частей:
Журнал. Каждый день ассистент заводит отдельную запись и фиксирует новости, решения и прогресс. Он сам определяет, что оставить в журнале, превратить в задачу или добавить в заметку о человеке.
Канбан-доска. Сюда переехала вся мелкая работа, которую раньше приходилось держать в голове. Ассистент создаёт и двигает карточки между статусами, фиксирует историю изменений и вносит пометки.
Встречи и люди. Из транскрибации созвонов ассистент вытаскивает договорённости, экшн-айтемы и обновляет заметки о людях. Перед следующей встречей может собрать план разговора.
Автоматизации. Сейчас их две: вечером ассистент синхронизирует цели между Google-таблицей и журналом, а к утру понедельника готовит дайджест для 1:1 с руководителем. Раньше такую картину приходилось собирать по чатам час-полтора.
Копилка достижений. Заметные результаты параллельно складываются в отдельную папку. Перед следующим перформанс-ревью ассистент составит черновик селф-ревью с датами и ссылками на журнал.
В статье Роман подробно показал, как устроен контур, описал правила безопасности и оставил готовый промпт, который можно вставить в Claude Code, Cursor или другой инструмент. Агент проведёт небольшое интервью и соберёт похожее решение уже под вас.
Почитать статью и забрать промпт себе
👍7✍6🔥1
В Agent Platform появились новые языковые модели
Недавно мы обновили работу с изображениями, а теперь добавили Claude Opus 5.5 от Anthropic и шесть моделей OpenAI: GPT-6 Astra, Astra Pro, Luna, Luna Pro, Sol и Sol Pro.
Выбирайте модель и пробуйте её в Agent Platform.
Недавно мы обновили работу с изображениями, а теперь добавили Claude Opus 5.5 от Anthropic и шесть моделей OpenAI: GPT-6 Astra, Astra Pro, Luna, Luna Pro, Sol и Sol Pro.
Выбирайте модель и пробуйте её в Agent Platform.
👍6🔥4
Forwarded from Код в каске — герои цифровизации девелопмента
Мы объединили опыт девелопера FORMA, практику KTS и мнения экспертов рынка, чтобы разобраться, как девелоперы внедряют искусственный интеллект в агентские продажи.
В отчёте:
🟢 Какие функции в кабинете брокера окупаются, а на какие гипотезы лучше не тратить бюджет
🟢 Какие инструменты ставят сделки под угрозу
🟢 Будущее агентского канала и заменит ли ИИ брокеров
😎 Скачать бесплатно
В отчёте:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥3❤2
Переосмысление ценности MCP
На всякий случай, MCP — это стандартный протокол подключения тулов к агентам.
Идея достаточно очевидна: унифицировать интеграции с LLM, чтобы можно было подключать знания из разных систем. Но на практике возникают проблемы:
1) Если API возвращает большой ответ, то нужно как-то предобрабатывать запрос. Следовательно, интерфейс уже не такой универсальный, и на практике он порождает слой проксей, которые подготавливают данные для конкретной задачи.
2) Возникает дополнительное препятствие для внедрения агентов, так как нужно строить платформу для MCP и продумывать им ролевые модели. Из-за этого приходится делать ооочень много технических приседаний и проходить не меньше согласований, а по итогу выхлоп может быть нулевым.
До недавнего времени я был убежден в том, что для этой вашей «ИИ-трансформации» компаниям нужно в обязательном порядке строить MCP-хабы, но переосмыслил эту гипотезу из-за одного практического примера.
Мы занимались автоматизацией тестирования приложения на Dev-среде, а для этого нужно было научить агента катить на Dev. У нас настроены динамические окружения, так что каждая ветка может существовать изолированно. Мы подключили GitLab MCP к агенту с выделенным пользователем с ролью developer на проекте. Вот только в MCP не оказалось возможности запускать пайплайны, и сам агент в процессе размышления попытался найти GitLab-токен с правами запуска пайпов. И это натолкнуло меня на мысль: а что, если агенту просто дать GitLab-токен пользователя с ограниченными правами и вызвать API напрямую из агента? Очевидно, это решение сработало.
В этот момент и произошло переосмысление: а зачем нам вообще нужен MCP? Почему мы не можем использовать текущие API для интеграции с уже продуманной (и, главное, принятой) ролевой моделью? Агенты поумнее вообще могут в реальном времени писать скрипты интеграции и сразу готовить формат, как себе нужно, а для агентов потупее можно заранее писать набор тулов для интеграции. С помощью агентов поумнее, само собой.
В итоге MCP-хаб (маркетплейс интеграций) превращается в набор скиллов (.md-файликов), который описывает, каким образом и с какой системой интегрироваться. Так в итоге еще и появляется самоактуализирующаяся документация. Актуализация происходит в момент, когда агент пытается написать интеграцию: если API не работает как описано, то он может сделать PR на обновление скилла, а овнеры уже могут принять или отклонить этот запрос.
#александр_опрышко
На всякий случай, MCP — это стандартный протокол подключения тулов к агентам.
Идея достаточно очевидна: унифицировать интеграции с LLM, чтобы можно было подключать знания из разных систем. Но на практике возникают проблемы:
1) Если API возвращает большой ответ, то нужно как-то предобрабатывать запрос. Следовательно, интерфейс уже не такой универсальный, и на практике он порождает слой проксей, которые подготавливают данные для конкретной задачи.
2) Возникает дополнительное препятствие для внедрения агентов, так как нужно строить платформу для MCP и продумывать им ролевые модели. Из-за этого приходится делать ооочень много технических приседаний и проходить не меньше согласований, а по итогу выхлоп может быть нулевым.
До недавнего времени я был убежден в том, что для этой вашей «ИИ-трансформации» компаниям нужно в обязательном порядке строить MCP-хабы, но переосмыслил эту гипотезу из-за одного практического примера.
Мы занимались автоматизацией тестирования приложения на Dev-среде, а для этого нужно было научить агента катить на Dev. У нас настроены динамические окружения, так что каждая ветка может существовать изолированно. Мы подключили GitLab MCP к агенту с выделенным пользователем с ролью developer на проекте. Вот только в MCP не оказалось возможности запускать пайплайны, и сам агент в процессе размышления попытался найти GitLab-токен с правами запуска пайпов. И это натолкнуло меня на мысль: а что, если агенту просто дать GitLab-токен пользователя с ограниченными правами и вызвать API напрямую из агента? Очевидно, это решение сработало.
В этот момент и произошло переосмысление: а зачем нам вообще нужен MCP? Почему мы не можем использовать текущие API для интеграции с уже продуманной (и, главное, принятой) ролевой моделью? Агенты поумнее вообще могут в реальном времени писать скрипты интеграции и сразу готовить формат, как себе нужно, а для агентов потупее можно заранее писать набор тулов для интеграции. С помощью агентов поумнее, само собой.
В итоге MCP-хаб (маркетплейс интеграций) превращается в набор скиллов (.md-файликов), который описывает, каким образом и с какой системой интегрироваться. Так в итоге еще и появляется самоактуализирующаяся документация. Актуализация происходит в момент, когда агент пытается написать интеграцию: если API не работает как описано, то он может сделать PR на обновление скилла, а овнеры уже могут принять или отклонить этот запрос.
#александр_опрышко
❤12👍9
Переосмысление агентов
Предыдущие выводы про MCP натолкнули на совсем крамольные мысли.
Обычно агенты в проде работают по фиксированной схеме: вот набор тулов (RAG, вызов оператора и прочие), вот промпт. На этом всё. Агент собирает контекст, как-то переваривает данные и выдаёт результат. Если данные представляют собой структурированную информацию (таблицы, числа), то вероятность ошибки очень высокая: агент может неправильно что-то просуммировать, агрегировать и т.д.
Локальные агенты решают это с помощью скриптов. Они обрабатывают данные не напрямую, а пишут скрипт с нужным представлением. В итоге задача «определи выручку за сентябрь» превращается в «напиши скрипт, который просуммирует все транзакции за заданный период, запусти его и выведи результат пользователю».
А что, если дать агенту возможность в рантайме писать код и подтягивать нужные зависимости? Сразу же возникают вопросы. А как же изоляция? А как запускать их? Придётся под каждую сессию поднимать отдельный контейнер? Это же сколько ресурсов нужно...
Но такой подход обеспечивает гибкость работы агентов. Сильно снижается объём внедрения, так как агент может в рантайме работать с интеграциями. По сути, мы получаем полноценный облачный агент, который может работать без инициативы пользователя. Полноценная агентность, a.k.a. нейросотрудник.
Большой вопрос только в безопасности и эксплуатации. Когда я начал копаться в этом глубже, я нашёл проекты, которые идут в ту же сторону:
1) https://github.com/google/ax
2) https://github.com/agent-substrate/substrate
Мы сейчас у себя их тестируем, скоро расскажем подробности.
#александр_опрышко
Предыдущие выводы про MCP натолкнули на совсем крамольные мысли.
Обычно агенты в проде работают по фиксированной схеме: вот набор тулов (RAG, вызов оператора и прочие), вот промпт. На этом всё. Агент собирает контекст, как-то переваривает данные и выдаёт результат. Если данные представляют собой структурированную информацию (таблицы, числа), то вероятность ошибки очень высокая: агент может неправильно что-то просуммировать, агрегировать и т.д.
Локальные агенты решают это с помощью скриптов. Они обрабатывают данные не напрямую, а пишут скрипт с нужным представлением. В итоге задача «определи выручку за сентябрь» превращается в «напиши скрипт, который просуммирует все транзакции за заданный период, запусти его и выведи результат пользователю».
А что, если дать агенту возможность в рантайме писать код и подтягивать нужные зависимости? Сразу же возникают вопросы. А как же изоляция? А как запускать их? Придётся под каждую сессию поднимать отдельный контейнер? Это же сколько ресурсов нужно...
Но такой подход обеспечивает гибкость работы агентов. Сильно снижается объём внедрения, так как агент может в рантайме работать с интеграциями. По сути, мы получаем полноценный облачный агент, который может работать без инициативы пользователя. Полноценная агентность, a.k.a. нейросотрудник.
Большой вопрос только в безопасности и эксплуатации. Когда я начал копаться в этом глубже, я нашёл проекты, которые идут в ту же сторону:
1) https://github.com/google/ax
2) https://github.com/agent-substrate/substrate
Мы сейчас у себя их тестируем, скоро расскажем подробности.
#александр_опрышко
👍9❤7
ИИ-базу знаний купили, никто не пользуется. Что делать?
Представьте, в компании внедрили ИИ-ассистента по внутренним документам. Провели демо, разослали ссылку, написали в общий чат. Через 2 месяца посмотрели статистику: десяток заходов в неделю, из них половина — это те, кто помогал внедрять базу знаний.
При этом ChatGPT или его корпоративная обёртка у людей открыты в соседней вкладке весь день. Первое объяснение, которое приходит руководителю в голову: сотрудники сопротивляются новому. Но те же самые люди сидят в «чатике» весь день, добровольно и без обучения. Причина не в сопротивлении, это отказ от одной конкретной системы.
С чем её сравнивают
MIT в прошлом году посчитал разрыв: официальную подписку на LLM купили около 40% компаний, а личными инструментами на работе пользуются больше 90% сотрудников. Отсюда важный вывод: люди уже знают, каким бывает нормальный ИИ, и к статичным корпоративным системам относятся гораздо жёстче.
То есть вашу базу знаний сравнивают не с поиском по Confluence, где десять нерелевантных ссылок — норма. Её сравнивают с ChatGPT. И достаточно одного случая, когда она уверенно назвала отменённый год назад регламент, чтобы сотрудник больше туда не вернулся. Второго шанса у таких систем обычно нет: люди не проверяют, «может, поправили».
Четыре причины, из-за которых система ломается чаще всего:
1) Контент. Модель не знает, какой из двух документов главнее. Действующий приказ и черновик двухлетней давности для неё просто два текста, и она аккуратно и уверенно процитирует оба. Дальше сотрудник один раз получает отменённый регламент, и система для него закрыта.
Поэтому основная часть внедрения — это разбор документов, а не настройка модели. Обычно это закладывают в план, но не уделяют должного времени (а работа с информацией — это отдельная практика, или даже культура).
2) Система не исправляется. Сотрудник нажал «плохой ответ». Через неделю задал тот же вопрос и получил то же самое. Всё, обратная связь больше не придёт: люди отказываются от инструментов, которые не запоминают и не меняются. И здесь речь не про дообучение модели, а про банальное: жалоба должна превращаться в задачу владельцу документа, а исправление — возвращаться пользователю.
3) Никто не знает, о чем её спрашивать. Часть сотрудников не понимает, где ИИ может улучшить их работу. Остальные видят пустое поле ввода и закрывают вкладку. «Спросите что угодно» — худший онбординг из возможных. Работает обратное: вот пять вопросов, которые вы задаёте коллегам каждую неделю, пишите их сюда.
4) Нет ранних последователей и лидерства на примере. Менее очевидная причина. Часть сотрудников не применяют доступный ИИ просто потому, что им не пользуются коллеги. Массовая рассылка эту стену не пробивает, нужны живые люди в командах, которые показывают инструмент на своих задачах.
Что делать:
▪️ Начать с 2-3 сценариев, а не с «единой базы знаний компании». Онбординг новичков, ответы по тарифам для продаж, регламенты первой линии. Узкая зона с ощутимой болью, где ответы можно проверить руками.
▪️ Дать каждому разделу владельца и срок годности. Устаревшее в архив, а не «пусть лежит». Триста проверенных документов лучше тридцати тысяч непроверенных.
▪️ Показывать источник и дату под каждым ответом, что, кстати, умеет наша AI-база знаний. И научить систему говорить «не знаю, спросите такого-то».
▪️ Встроить в мессенджер и рабочие системы. Отдельный портал, до которого надо дойти, проигрывает по умолчанию.
▪️ Посмотреть, зачем сотрудники ходят в ChatGPT, и не запрещать, а забрать эти сценарии себе. Это готовый бэклог, составленный без вас и бесплатно.
#иван_лавров
Представьте, в компании внедрили ИИ-ассистента по внутренним документам. Провели демо, разослали ссылку, написали в общий чат. Через 2 месяца посмотрели статистику: десяток заходов в неделю, из них половина — это те, кто помогал внедрять базу знаний.
При этом ChatGPT или его корпоративная обёртка у людей открыты в соседней вкладке весь день. Первое объяснение, которое приходит руководителю в голову: сотрудники сопротивляются новому. Но те же самые люди сидят в «чатике» весь день, добровольно и без обучения. Причина не в сопротивлении, это отказ от одной конкретной системы.
С чем её сравнивают
MIT в прошлом году посчитал разрыв: официальную подписку на LLM купили около 40% компаний, а личными инструментами на работе пользуются больше 90% сотрудников. Отсюда важный вывод: люди уже знают, каким бывает нормальный ИИ, и к статичным корпоративным системам относятся гораздо жёстче.
То есть вашу базу знаний сравнивают не с поиском по Confluence, где десять нерелевантных ссылок — норма. Её сравнивают с ChatGPT. И достаточно одного случая, когда она уверенно назвала отменённый год назад регламент, чтобы сотрудник больше туда не вернулся. Второго шанса у таких систем обычно нет: люди не проверяют, «может, поправили».
Четыре причины, из-за которых система ломается чаще всего:
1) Контент. Модель не знает, какой из двух документов главнее. Действующий приказ и черновик двухлетней давности для неё просто два текста, и она аккуратно и уверенно процитирует оба. Дальше сотрудник один раз получает отменённый регламент, и система для него закрыта.
Поэтому основная часть внедрения — это разбор документов, а не настройка модели. Обычно это закладывают в план, но не уделяют должного времени (а работа с информацией — это отдельная практика, или даже культура).
2) Система не исправляется. Сотрудник нажал «плохой ответ». Через неделю задал тот же вопрос и получил то же самое. Всё, обратная связь больше не придёт: люди отказываются от инструментов, которые не запоминают и не меняются. И здесь речь не про дообучение модели, а про банальное: жалоба должна превращаться в задачу владельцу документа, а исправление — возвращаться пользователю.
3) Никто не знает, о чем её спрашивать. Часть сотрудников не понимает, где ИИ может улучшить их работу. Остальные видят пустое поле ввода и закрывают вкладку. «Спросите что угодно» — худший онбординг из возможных. Работает обратное: вот пять вопросов, которые вы задаёте коллегам каждую неделю, пишите их сюда.
4) Нет ранних последователей и лидерства на примере. Менее очевидная причина. Часть сотрудников не применяют доступный ИИ просто потому, что им не пользуются коллеги. Массовая рассылка эту стену не пробивает, нужны живые люди в командах, которые показывают инструмент на своих задачах.
Что делать:
▪️ Начать с 2-3 сценариев, а не с «единой базы знаний компании». Онбординг новичков, ответы по тарифам для продаж, регламенты первой линии. Узкая зона с ощутимой болью, где ответы можно проверить руками.
▪️ Дать каждому разделу владельца и срок годности. Устаревшее в архив, а не «пусть лежит». Триста проверенных документов лучше тридцати тысяч непроверенных.
▪️ Показывать источник и дату под каждым ответом, что, кстати, умеет наша AI-база знаний. И научить систему говорить «не знаю, спросите такого-то».
▪️ Встроить в мессенджер и рабочие системы. Отдельный портал, до которого надо дойти, проигрывает по умолчанию.
▪️ Посмотреть, зачем сотрудники ходят в ChatGPT, и не запрещать, а забрать эти сценарии себе. Это готовый бэклог, составленный без вас и бесплатно.
#иван_лавров
👍6🔥4❤1
Восстановление agentplatform.ru
Уведомляем о прогрессе восстановлении работы agentplatform.ru после длительного даунтайма.
Наша команда была занята восстановлением доступности сервиса после нескольких проблем, возникших у провайдеров инфрастуктуры. Сейчас системы должны работать относительно стабильно. Работают текстовые модели, image-модели восстановим к завтра.
Данные восстановлены на приблизительно 10 октября 6:00.
Мы знаем о проблемах, что некоторые оплаты сейчас не видны в кабинете, в течение недели мы восстановим все балансы и оплаты, которые были совершены в период с 10 октября по 13 октября и сейчас не отображаются.
На этой неделе будут планироваться дополнительные технические работы.
Спасибо большое за понимание 💚
Уведомляем о прогрессе восстановлении работы agentplatform.ru после длительного даунтайма.
Наша команда была занята восстановлением доступности сервиса после нескольких проблем, возникших у провайдеров инфрастуктуры. Сейчас системы должны работать относительно стабильно. Работают текстовые модели, image-модели восстановим к завтра.
Данные восстановлены на приблизительно 10 октября 6:00.
Мы знаем о проблемах, что некоторые оплаты сейчас не видны в кабинете, в течение недели мы восстановим все балансы и оплаты, которые были совершены в период с 10 октября по 13 октября и сейчас не отображаются.
На этой неделе будут планироваться дополнительные технические работы.
Спасибо большое за понимание 💚
❤14
У провайдера хорошо, но свой инференс дешевле
На старте для AI-продуктов удобно пользоваться облачным провайдером: не нужно покупать серверы, настраивать видеокарты и заниматься эксплуатацией. Но платить приходится за каждый запуск модели. Поэтому с ростом аудитории увеличивается и счёт.
Мы не только разрабатываем AI-сервисы, но и обеспечиваем для них инфраструктуру. Поэтому к нам обратилась команда проекта «Фотобудка» — сервиса персонализированной генерации фото.
Они хотели узнать: будет ли дешевле генерировать на своих видеокартах? При этом важно было сделать совместимый API и сохранить надёжность продукта.
Полностью отказываться от провайдера оказалось невыгодно. Если купить GPU под пиковую нагрузку, придётся платить за простой. Взять меньше машин — в часы пик будет очередь на генерацию.
Поэтому мы реализовали гибридный подход. Постоянный пул выделенных GPU закрывает базовую нагрузку, а всё, что в него не помещается, уходит прежнему провайдеру. Отдел спецпроектов KTS спроектировал API, очередь и обработчик задач, а DevOps-юнит развернул кластер, серверы и мониторинг.
Система сама оценивает пропускную способность. Если время ожидания выходит за лимит или в одной из машин происходит сбой, запрос уходит провайдеру. В результате при полной загрузке GPU одна генерация обходится на 80% дешевле, чем у провайдера с оплатой за запуск.
⏺ Подробнее о том, как спроектировали контур и почему отказались от автоматической покупки машин, читайте в кейсе
На старте для AI-продуктов удобно пользоваться облачным провайдером: не нужно покупать серверы, настраивать видеокарты и заниматься эксплуатацией. Но платить приходится за каждый запуск модели. Поэтому с ростом аудитории увеличивается и счёт.
Мы не только разрабатываем AI-сервисы, но и обеспечиваем для них инфраструктуру. Поэтому к нам обратилась команда проекта «Фотобудка» — сервиса персонализированной генерации фото.
Они хотели узнать: будет ли дешевле генерировать на своих видеокартах? При этом важно было сделать совместимый API и сохранить надёжность продукта.
Полностью отказываться от провайдера оказалось невыгодно. Если купить GPU под пиковую нагрузку, придётся платить за простой. Взять меньше машин — в часы пик будет очередь на генерацию.
Поэтому мы реализовали гибридный подход. Постоянный пул выделенных GPU закрывает базовую нагрузку, а всё, что в него не помещается, уходит прежнему провайдеру. Отдел спецпроектов KTS спроектировал API, очередь и обработчик задач, а DevOps-юнит развернул кластер, серверы и мониторинг.
Система сама оценивает пропускную способность. Если время ожидания выходит за лимит или в одной из машин происходит сбой, запрос уходит провайдеру. В результате при полной загрузке GPU одна генерация обходится на 80% дешевле, чем у провайдера с оплатой за запуск.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤3
Внутри AI | Кейсы ИИ Агентов в бизнесе
Восстановление agentplatform.ru Уведомляем о прогрессе восстановлении работы agentplatform.ru после длительного даунтайма. Наша команда была занята восстановлением доступности сервиса после нескольких проблем, возникших у провайдеров инфрастуктуры. Сейчас…
Восстановление agentplatform.ru
На данный момент:
• восстановили работу практически всех текстовых моделей из каталога
• восстановили работу image моделей
• восстановили оплаты которые были совершены через Yookassa в период с 10 по 13 октября
Если вы проводили оплату и вы не видите в личном кабинете проведенную оплату - напишите, пожалуйста, нам на почту agentplatform@kts.tech с email-адреса, на который зарегистрирован кабинет.
Спасибо, что вы с нами 💚
На данный момент:
• восстановили работу практически всех текстовых моделей из каталога
• восстановили работу image моделей
• восстановили оплаты которые были совершены через Yookassa в период с 10 по 13 октября
Если вы проводили оплату и вы не видите в личном кабинете проведенную оплату - напишите, пожалуйста, нам на почту agentplatform@kts.tech с email-адреса, на который зарегистрирован кабинет.
Спасибо, что вы с нами 💚
❤7
🔥 Открыли доступ к Agent Builder — платформе для массовой автоматизации процессов
Компании запускают всё больше AI-инициатив, но точечные решения сложно масштабировать и поддерживать, и на каждый новый сценарий нужны ресурсы IT. При этом мы видим рост запросов не на разовые внедрения агентов, а на массовую автоматизацию. Поэтому разработали Agent Builder — платформу, на которой предметные специалисты могут самостоятельно создавать два типа сценариев автоматизации с AI-агентами:
1) Полное замещение процесса. Сценарий выполняет работу целиком, а человек видит только результат и подключается в критичных вопросах, если нужно. Например, агент сверяет заявку на закупку с бюджетом и отправляет на согласование.
2) Ассистенты для специалистов. Сотрудник по-прежнему ведёт процесс сам, а система помогает ему. Агенты ищут данные, готовят черновики, подсказывают следующий шаг.
Как это работает:
▫️ специалист описывает ТЗ или спецификацию с помощью AI-аналитика
▫️ AI-разработчик пишет код, человек подключается только, если нужно ответить на вопросы
▫️ проект выкладывается в тестовую среду
▫️ после подтверждения специалистом автоматизация выходит в общую эксплуатацию
В одном сценарии можно сочетать алгоритмические шаги и AI-агентов, подключать интеграции с корпоративными сервисами, ЛК, базами знаний.
Все созданные автоматизации работают в едином хранилище и становятся описанием рабочего процесса — так автоматически строится карта. Можно анализировать эти сценарии и масштабировать эффективные решения на другие команды.
В результате вы забываете про вечные AI-пилоты и автоматизируете целые цепочки процессов. Проверяете гипотезы за считаные дни, сокращаете рутину без привлечения разработки и экономите на поддержке решений за счёт переиспользования.
Опишите вашу задачу, и мы покажем, как Agent Builder автоматизирует её
⌛️ Получить демо-доступ
Компании запускают всё больше AI-инициатив, но точечные решения сложно масштабировать и поддерживать, и на каждый новый сценарий нужны ресурсы IT. При этом мы видим рост запросов не на разовые внедрения агентов, а на массовую автоматизацию. Поэтому разработали Agent Builder — платформу, на которой предметные специалисты могут самостоятельно создавать два типа сценариев автоматизации с AI-агентами:
1) Полное замещение процесса. Сценарий выполняет работу целиком, а человек видит только результат и подключается в критичных вопросах, если нужно. Например, агент сверяет заявку на закупку с бюджетом и отправляет на согласование.
2) Ассистенты для специалистов. Сотрудник по-прежнему ведёт процесс сам, а система помогает ему. Агенты ищут данные, готовят черновики, подсказывают следующий шаг.
Как это работает:
▫️ специалист описывает ТЗ или спецификацию с помощью AI-аналитика
▫️ AI-разработчик пишет код, человек подключается только, если нужно ответить на вопросы
▫️ проект выкладывается в тестовую среду
▫️ после подтверждения специалистом автоматизация выходит в общую эксплуатацию
В одном сценарии можно сочетать алгоритмические шаги и AI-агентов, подключать интеграции с корпоративными сервисами, ЛК, базами знаний.
Все созданные автоматизации работают в едином хранилище и становятся описанием рабочего процесса — так автоматически строится карта. Можно анализировать эти сценарии и масштабировать эффективные решения на другие команды.
В результате вы забываете про вечные AI-пилоты и автоматизируете целые цепочки процессов. Проверяете гипотезы за считаные дни, сокращаете рутину без привлечения разработки и экономите на поддержке решений за счёт переиспользования.
Опишите вашу задачу, и мы покажем, как Agent Builder автоматизирует её
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍3🔥3
Не каждой базе знаний нужен RAG
Сегодня RAG стал основой LLM-агентов, которые работают с корпоративными данными. Но не всегда этот подход экономически оправдан. Архитектуру AI-поиска стоит выбирать по типам запросов, которые будут приходить в систему.
🟢 Типовые вопросы с устойчивыми ответами. Если сотрудники спрашивают одно и то же, как в FAQ, полноценный RAG может только увеличить стоимость и время обработки. Для такой задачи достаточно классификатора интентов и шаблонов ответов.
🟢 Простые вопросы по документам. Если ответ находится в одном-двух фрагментах, подходит классический RAG: запрос → поиск → ответ. Он проще, быстрее и дешевле в разработке и эксплуатации.
🟢 Сложные аналитические запросы. Когда для ответа нужно собрать несколько фактов из разрозненных документов, можно использовать агентский RAG.
В нём поиском управляет LLM: выбирает источник и инструмент, определяет количество итераций и при необходимости корректирует запрос.
На практике чаще всего выгоднее идти от простого к сложному: начать с классического RAG и добавлять агентский, если не устраивает уровень качества ответов.
В новой статье подробно разбираем, как работают индексация, поиск и генерация в RAG-системах. Объясняем, как оценивать качество ответов и сокращать затраты на разработку и масштабирование.
Заходите в блог
Сегодня RAG стал основой LLM-агентов, которые работают с корпоративными данными. Но не всегда этот подход экономически оправдан. Архитектуру AI-поиска стоит выбирать по типам запросов, которые будут приходить в систему.
В нём поиском управляет LLM: выбирает источник и инструмент, определяет количество итераций и при необходимости корректирует запрос.
На практике чаще всего выгоднее идти от простого к сложному: начать с классического RAG и добавлять агентский, если не устраивает уровень качества ответов.
«Обычно используют такую SOTA-стратегию: в систему добавляют маршрутизатор, который распределяет запросы. Чаще всего 80% вопросов идёт в классический RAG, а 20% сложных — в агентский. Это позволяет не запускать более дорогой цикл без необходимости», — Екатерина Пославская, ML-разработчик KTS
В новой статье подробно разбираем, как работают индексация, поиск и генерация в RAG-системах. Объясняем, как оценивать качество ответов и сокращать затраты на разработку и масштабирование.
Заходите в блог
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6