🏆 Ворвались в Рейтинг Рунета 2026
В этом году KTS впервые участвовал в AI-направлении Рейтинга Рунета 2026 — и сразу попал в топ-20, заняв 12 место в номинации «Разработка и внедрение искусственного интеллекта».
Участников рейтинга оценивали по проектам, услугам, отраслевой экспертизе и достижениям за 2025–2026 годы.
Попадание в топ-20 — подтверждение, что наш опыт в AI уже заметен на рынке.
Для нас это важный результат: AI-направление в KTS быстро растёт, а проекты становятся все более прикладными — от внедрения LLM и RAG до AI-агентов и внутренних инструментов для бизнеса.
Благодарим ключевых партнеров: Альфа-Банк, Гигачат, Столото и других лидеров рынка за доверие!
Работаем дальше: усиливаем экспертизу, развиваем AI-решения и двигаемся выше.
В этом году KTS впервые участвовал в AI-направлении Рейтинга Рунета 2026 — и сразу попал в топ-20, заняв 12 место в номинации «Разработка и внедрение искусственного интеллекта».
Участников рейтинга оценивали по проектам, услугам, отраслевой экспертизе и достижениям за 2025–2026 годы.
Попадание в топ-20 — подтверждение, что наш опыт в AI уже заметен на рынке.
Для нас это важный результат: AI-направление в KTS быстро растёт, а проекты становятся все более прикладными — от внедрения LLM и RAG до AI-агентов и внутренних инструментов для бизнеса.
Благодарим ключевых партнеров: Альфа-Банк, Гигачат, Столото и других лидеров рынка за доверие!
Работаем дальше: усиливаем экспертизу, развиваем AI-решения и двигаемся выше.
🔥25
Сегодня студенты живут свою лучшую жизнь…
... потому что им помогают AI-агенты
Обычно подготовка научной или дипломной работы начинается с попыток сформулировать тему и часов поиска подходящей литературы. Для ДВФУ и РАНХиГС мы разработали AI-агента, который выдаёт готовую основу для исследования за минуты.
Вместе с командой ГигаЧат реализовали проект за 3 недели: спроектировали инфраструктуру, настроили RAG и векторизовали 200 000 книг из библиотечных фондов.
По запросу пользователя агент подбирает источники из базы знаний и передаёт их в LLM. Модель ГигаЧата суммаризирует данные и генерирует ответ с формулировками темы, структурой научной работы и списком литературы.
Так за один короткий запрос студент получает всё необходимое для начала исследования без привлечения научного руководителя.
🤨 Этот проект показывает, как AI-решения на основе RAG помогают структурировать разрозненные источники данных, упрощают работу с базами знаний и экономят часы на поиске информации.
Подробности — в кейсе
... потому что им помогают AI-агенты
Обычно подготовка научной или дипломной работы начинается с попыток сформулировать тему и часов поиска подходящей литературы. Для ДВФУ и РАНХиГС мы разработали AI-агента, который выдаёт готовую основу для исследования за минуты.
Вместе с командой ГигаЧат реализовали проект за 3 недели: спроектировали инфраструктуру, настроили RAG и векторизовали 200 000 книг из библиотечных фондов.
По запросу пользователя агент подбирает источники из базы знаний и передаёт их в LLM. Модель ГигаЧата суммаризирует данные и генерирует ответ с формулировками темы, структурой научной работы и списком литературы.
Так за один короткий запрос студент получает всё необходимое для начала исследования без привлечения научного руководителя.
Подробности — в кейсе
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9
👀 Новые модели в Agent Platform
Хорошая новость для тех, кто тестирует разные LLM под агентские сценарии, внутренние ассистенты, работу с текстом и изображениями. Недавно добавили несколько новых моделей:
Новые модели Anthropic:
—
—
Новые опенсорсные модели, которые показывают хорошие результаты в кодировании, с хостингом в РФ у нашего партнера Cloud.ru:
—
—
Новая модель для работы с изображениями:
—
Заходите в Agent Platform протестировать
Хорошая новость для тех, кто тестирует разные LLM под агентские сценарии, внутренние ассистенты, работу с текстом и изображениями. Недавно добавили несколько новых моделей:
Новые модели Anthropic:
—
anthropic/claude-fable-5 нашумевшая fable-5—
anthropic/claude-sonnet-5 для задач, где важны качество ответа, работа с контекстом и сложными инструкциями.Новые опенсорсные модели, которые показывают хорошие результаты в кодировании, с хостингом в РФ у нашего партнера Cloud.ru:
—
cloudru/MiniMaxAI/MiniMax-M3—
cloudru/zai-org/GLM-5.2Новая модель для работы с изображениями:
—
google/gemini-3.1-flash-lite-image Заходите в Agent Platform протестировать
🔥5👍2
Безопасно ли запускать AI-агента на корпоративных данных?
Продолжаем разбирать AI Platform для закрытого контура. В прошлый раз рассказали, как агентская платформа ускоряет создание агентов в десятки раз. Сегодня поговорим о работе с базами знаний.
Корпоративные данные — один из основных барьеров внедрения AI в enterprise. Компании хотят их контролировать, поэтому требуют создавать контуры индексации на базе собственной инфраструктуры. Для этого нужны готовые решения по работе с структурированными (базами, таблицами) и неструктурированными данными (PDF-документами).
Платформа данных устраняет этот барьер. Мы встроили в неё 6 инструментов для разных типов запросов с проверкой на качество и безопасность данных:
▪️ Парсинг PDF с таблицами, схемами и сложными структурами, поддержка работы с DOCX, PPTX, XLS.
▪️ Классический RAG — гибридный поиск: BM25 + векторный. Подходит для быстрого семантического поиска по большим массивам информации.
▪️ Графовый RAG — поиск по многосвязанным данным, где важны связи между фактами, а не отдельные фрагменты.
▪️ Табличный доступ — SQL, API, CSV, DWH подключаются как инструменты через MCP.
▪️ Валидация данных — подсветка конфликтов и дублей в документах. Позволяет найти конфликты, устранить их и таким образом значительно снизить галлюцинации решений.
▪️ Сквозной RBAC — ролевая модель из корпоративной AD/Keycloak на каждом запросе. Агент видит только ту информацию, которая доступна конкретному пользователю.
Чувствительные данные не попадают в LLM и внешние контуры. Запрос проходит через маскировку и гардрейлы по правилам безопасности.
В наших проектах запуск AI-агентов на корпоративных данных даёт измеримый результат: поиск информации ускоряется на 50-80%, а обработка документов — на 70-90%. Как это работает, показали в кейсе с Альфа-Банком.
Продолжаем разбирать AI Platform для закрытого контура. В прошлый раз рассказали, как агентская платформа ускоряет создание агентов в десятки раз. Сегодня поговорим о работе с базами знаний.
Корпоративные данные — один из основных барьеров внедрения AI в enterprise. Компании хотят их контролировать, поэтому требуют создавать контуры индексации на базе собственной инфраструктуры. Для этого нужны готовые решения по работе с структурированными (базами, таблицами) и неструктурированными данными (PDF-документами).
Платформа данных устраняет этот барьер. Мы встроили в неё 6 инструментов для разных типов запросов с проверкой на качество и безопасность данных:
▪️ Парсинг PDF с таблицами, схемами и сложными структурами, поддержка работы с DOCX, PPTX, XLS.
▪️ Классический RAG — гибридный поиск: BM25 + векторный. Подходит для быстрого семантического поиска по большим массивам информации.
▪️ Графовый RAG — поиск по многосвязанным данным, где важны связи между фактами, а не отдельные фрагменты.
▪️ Табличный доступ — SQL, API, CSV, DWH подключаются как инструменты через MCP.
▪️ Валидация данных — подсветка конфликтов и дублей в документах. Позволяет найти конфликты, устранить их и таким образом значительно снизить галлюцинации решений.
▪️ Сквозной RBAC — ролевая модель из корпоративной AD/Keycloak на каждом запросе. Агент видит только ту информацию, которая доступна конкретному пользователю.
Чувствительные данные не попадают в LLM и внешние контуры. Запрос проходит через маскировку и гардрейлы по правилам безопасности.
В наших проектах запуск AI-агентов на корпоративных данных даёт измеримый результат: поиск информации ускоряется на 50-80%, а обработка документов — на 70-90%. Как это работает, показали в кейсе с Альфа-Банком.
🔥6❤4
Монорепы на пути к AI SDLC
В прошлом посте рассказывал про то, как мы перенесли документацию в гит и сделали удобный инструмент согласования бизнес-требований с заказчиками.
Следующий шаг «сближения» данных и сбора общего контекста для разработчиков и агентов — создание монорепы / общего воркспейса с несколькими репозиториями у проекта.
Классическая картинка выглядит так: есть репа с бекендом, есть с фронтендом, и еще несколько вспомогательных реп на какие-то смежные сервисы.
Сама структура репозиториев не позволяет одним коммитом добавить функционал: нужно, например, сделать бек, потом фронт, а часто это еще и разные специалисты и разные задачи в трекере, за синхронизацией которых между собой следят менеджеры и тимлиды.
Это очевидная точка оптимизации на пути к AI SDLC. Если я могу (утрированно) сгенерить код фронта за час, но мне нужно ждать целый день, чтобы его передать следующему спецу, который сделает бек, а потом это все сливать в стейдж, чтобы отдельно интеграционно потестит, то я теряю уйму времени на передаче контекста и отслеживание статусов атомарных задачек и контроля их синхронизации. Никаким кратным ускорением не пахнет.
Соответственно, возможность, которую хочется использовать в AI SDLC — атомарной задачей должна стать сама фича, а не ее кусочки. А для этого мне нужно в одном месте собирать все артефакты: от бизнес-требований (см предыдущий пост) до автотестов. Это место — в идеале монорепа. Тогда я смогу одним коммитом вмержить целый блок функционала: и актуальные бизнес-требования, и техническую спецификацию, и реализацию, и автотесты.
Это гарантирует синхронизацию артефактов между собой, сократит время на менеджмент подзадач, позволит агентам точнее выполнять задачу.
Идеальный процесс тогда может выглядеть так:
– Аналитик собирает требования, кладет расшифровки звонков в репу, любые другие артефакты в процессе анализа, и генерит документацию по бизнес требованиям. Все это в ветке монорепы.
– Опционально аналитик может даже сгенерировать прототип в реальном коде на основе своих же бизнес-требований и показать клиенту (автоматический деплой из фича-ветки, такая вот нативная интеграция наших услуг)
– Менеджер / тимлид в этой же ветке может загрумить задачки, поразгоняв с агентом. И сразу же завести их в трекере по mcp, если нужно. Автоматически приложив в задачу ссылку на документацию в нашем же сервисе.
– Разработчик вместе с агентом реализует фичу в этой же ветке, глядя на согласованные бизнес-требования и прототип (который он потом просто выкинет) прямо в этой же ветке. Обновляет автоматически документацию, если есть изменения в процессе.
– Ветка проходит ревью у тимлида целиком.
– Тестировщик тестит эту же ветку (снова нативная интеграция фича-стендов) в изолированном окружении и дописывает автотесты.
Фича стала набором связанных артефактов и они все одной транзакцией попали в основную ветку при мерже.
Я специально на каждом шаге в примере приводил разных специалистов, хотя уже видно, что следующие шаги на пути к AI SDLC — это скиллы, которые позволяют с должным уровнем качества делать эти шаги с помощью агентов. А потом какие-то шаги делать автономно. Про это буду писать в следующих постах по мере реализации на практике.
#сергей_чернобровкин
В прошлом посте рассказывал про то, как мы перенесли документацию в гит и сделали удобный инструмент согласования бизнес-требований с заказчиками.
Следующий шаг «сближения» данных и сбора общего контекста для разработчиков и агентов — создание монорепы / общего воркспейса с несколькими репозиториями у проекта.
Классическая картинка выглядит так: есть репа с бекендом, есть с фронтендом, и еще несколько вспомогательных реп на какие-то смежные сервисы.
Сама структура репозиториев не позволяет одним коммитом добавить функционал: нужно, например, сделать бек, потом фронт, а часто это еще и разные специалисты и разные задачи в трекере, за синхронизацией которых между собой следят менеджеры и тимлиды.
Это очевидная точка оптимизации на пути к AI SDLC. Если я могу (утрированно) сгенерить код фронта за час, но мне нужно ждать целый день, чтобы его передать следующему спецу, который сделает бек, а потом это все сливать в стейдж, чтобы отдельно интеграционно потестит, то я теряю уйму времени на передаче контекста и отслеживание статусов атомарных задачек и контроля их синхронизации. Никаким кратным ускорением не пахнет.
Соответственно, возможность, которую хочется использовать в AI SDLC — атомарной задачей должна стать сама фича, а не ее кусочки. А для этого мне нужно в одном месте собирать все артефакты: от бизнес-требований (см предыдущий пост) до автотестов. Это место — в идеале монорепа. Тогда я смогу одним коммитом вмержить целый блок функционала: и актуальные бизнес-требования, и техническую спецификацию, и реализацию, и автотесты.
Это гарантирует синхронизацию артефактов между собой, сократит время на менеджмент подзадач, позволит агентам точнее выполнять задачу.
Идеальный процесс тогда может выглядеть так:
– Аналитик собирает требования, кладет расшифровки звонков в репу, любые другие артефакты в процессе анализа, и генерит документацию по бизнес требованиям. Все это в ветке монорепы.
– Опционально аналитик может даже сгенерировать прототип в реальном коде на основе своих же бизнес-требований и показать клиенту (автоматический деплой из фича-ветки, такая вот нативная интеграция наших услуг)
– Менеджер / тимлид в этой же ветке может загрумить задачки, поразгоняв с агентом. И сразу же завести их в трекере по mcp, если нужно. Автоматически приложив в задачу ссылку на документацию в нашем же сервисе.
– Разработчик вместе с агентом реализует фичу в этой же ветке, глядя на согласованные бизнес-требования и прототип (который он потом просто выкинет) прямо в этой же ветке. Обновляет автоматически документацию, если есть изменения в процессе.
– Ветка проходит ревью у тимлида целиком.
– Тестировщик тестит эту же ветку (снова нативная интеграция фича-стендов) в изолированном окружении и дописывает автотесты.
Фича стала набором связанных артефактов и они все одной транзакцией попали в основную ветку при мерже.
Я специально на каждом шаге в примере приводил разных специалистов, хотя уже видно, что следующие шаги на пути к AI SDLC — это скиллы, которые позволяют с должным уровнем качества делать эти шаги с помощью агентов. А потом какие-то шаги делать автономно. Про это буду писать в следующих постах по мере реализации на практике.
#сергей_чернобровкин
🔥8❤3
Как управлять LLM в закрытом контуре и не потерять контроль над безопасностью и бюджетом
Завершаем обзор AI Platform. Сегодня разберём фундамент всего стека — LLM-платформу.
Обычно для решения разных задач одной модели недостаточно. Для части запросов нужен уровень качества мировых SOTA. В других задачах критически важно обрабатывать чувствительную информацию локально. В промышленной эксплуатации используются десятки LLM. У них могут быть разные размеры, расположение в контурах и типы обрабатываемых данных.
LLM-платформа позволяет контролировать безопасность и бюджет на уровне инфраструктуры. Это единый OpenAI-совместимый шлюз, который входит в реестр российского ПО.
Встроенный ПДн-роутер распределяет запросы на основании содержимого и политик безопасности заказчика:
▪️ локальная инфраструктура — персональные и конфиденциальные данные, чувствительные задачи
▪️ в российские облака — YandexGPT, GigaChat, Cloud.ru — если важна юрисдикция и нужно масштабирование без собственных GPU
▪️ к мировым SOTA-моделям — OpenAI, Anthropic, Google, DeepSeek — только запросы без ПДн, где критично качество ответа
Функциональность платформы позволяет отслеживать токены, стоимость, латентность по каждому запросу и контролировать лимиты и расходы в реальном времени.
Локальные модели разворачивается по запросу из админки, поддерживается разделение GPU для эффективной утилизации ресурсов.
Платформы агентов, данных и LLM образуют единый стек для внедрения AI в закрытом контуре. Компании получают готовую инфраструктуру с контролем безопасности, качества и бюджета, что позволяет быстрее переходить от пилотов к промышленной эксплуатации и масштабировать AI-сценарии без пересборки архитектуры.
Проверьте, как AI Platform работает на ваших данных. Запишитесь на демо
Завершаем обзор AI Platform. Сегодня разберём фундамент всего стека — LLM-платформу.
Обычно для решения разных задач одной модели недостаточно. Для части запросов нужен уровень качества мировых SOTA. В других задачах критически важно обрабатывать чувствительную информацию локально. В промышленной эксплуатации используются десятки LLM. У них могут быть разные размеры, расположение в контурах и типы обрабатываемых данных.
LLM-платформа позволяет контролировать безопасность и бюджет на уровне инфраструктуры. Это единый OpenAI-совместимый шлюз, который входит в реестр российского ПО.
Встроенный ПДн-роутер распределяет запросы на основании содержимого и политик безопасности заказчика:
▪️ локальная инфраструктура — персональные и конфиденциальные данные, чувствительные задачи
▪️ в российские облака — YandexGPT, GigaChat, Cloud.ru — если важна юрисдикция и нужно масштабирование без собственных GPU
▪️ к мировым SOTA-моделям — OpenAI, Anthropic, Google, DeepSeek — только запросы без ПДн, где критично качество ответа
Функциональность платформы позволяет отслеживать токены, стоимость, латентность по каждому запросу и контролировать лимиты и расходы в реальном времени.
Локальные модели разворачивается по запросу из админки, поддерживается разделение GPU для эффективной утилизации ресурсов.
Платформы агентов, данных и LLM образуют единый стек для внедрения AI в закрытом контуре. Компании получают готовую инфраструктуру с контролем безопасности, качества и бюджета, что позволяет быстрее переходить от пилотов к промышленной эксплуатации и масштабировать AI-сценарии без пересборки архитектуры.
Проверьте, как AI Platform работает на ваших данных. Запишитесь на демо
❤6🔥6
ИИ вне разработки
В прошлых постах много писал про разработку. А что поменялось в процессах других команд?
Сегодня поговорим про эволюцию отдела продаж. За последние несколько месяцев попробовали много инструментов.
Начиналось всё, думаю, как и у всех, с того, что сейлзы начали использовать нейро-инструменты. Например, пробовали обсуждать с ChatGPT свои сделки.
Сами лиды при этом лежат в CRM, сметы считаются в таблицах, КП готовится в Фигме, а процесс выработки решения довольно сложный и состоит из встреч с партнёрами, клиентом, технической командой и т. д.
Когда сейлзы начали использовать ИИ-инструменты, это, как и в случае с разработкой, ускорило работу и сделало её местами более качественной за единицу времени. Но это всё ещё не кратное ускорение / улучшение.
Мы смогли продвинуться чуть дальше. Но сначала нужно понять классические проблемы отдела продаж (не только наших). Изучение кейсов и продуктов компании обычно занимает пару месяцев, адаптация сейлза к процессу сбора КП, синхронизация с командой — всё это приводит к продолжительному онбордингу, на который накладывается ещё и длинный цикл сделки. В итоге сейлз может начать что-то приносить через полгода. При этом капитализация отдела продаж в основном в:
▫️ контактах в CRM
▫️ отработанных лидах и кейсах (которые часто неструктурированы и разбросаны по системам)
▫️ всяческих шаблонах и готовых упаковках
▫️ опыте конкретных людей
Соответственно, чтобы выходить на новый уровень качества и скорости, нужно усиливать эту капитализацию с ИИ.
Все перечисленные пункты на самом деле раскладываются на 2 задачи:
— накопление знаний: чёткая структура, быстрый и простой доступ
— типовые кросс-командные решения
Поэтому первое, что мы сделали — ИИ-агента с поиском по нашим решениям. Он позволяет быстрее ориентироваться в продуктах и кейсах (которых, на минуточку, несколько сотен, и никто не знает про все). А второе — агент, который помогает оценивать уровень качества КП по оформлению и принятым практикам. Таким образом регламенты и подходы становятся не просто рекомендациями (которые на практике быстро деградируют), а правилами, заложенными в систему.
Но этого было недостаточно. Во-первых, оба инструмента находятся в нашей внутренней системе. Получается, сейлз работает в CRM, сидит в чатах и почте, звонит по телефону, готовит КП вместе с GPT и ещё кучу всего делает. И тут ему ещё одну вспомогательную систему дали. Мотивации туда заходить не так много. Новые инструменты добавляются централизованно, а значит долго, и не извлекают экспертизу и знания конкретного сейлза в общие практики. Артефакты подготовки конкретного КП всё также передаются в гугл-папках, CRM, чатах и т. д.
И тут становится понятно, что эти проблемы давно решены в разработке:
▫️ экспертиза, знания и правила — это скиллы для ИИ-агентов
▫️ общее хранилище данных — репозитории, где работают все инженеры (вместе с ИИ-агентами) в одном контексте
▫️ генерация артефактов с кодинговыми агентами работает лучше всяких чатов с GPT
Поэтому решение стало очевидным: сейлзы должны начать накапливать знания о своих пресейлах и генерить решения вместе с техническими командами так же, как это делают разработчики. Мы сделали один общий git-репозиторий для продаж. Он содержит: схему данных о клиентах и их заявках для накопления всех артефактов, MCP CRM, набор скиллов для работы с кодинговыми агентами.
Процесс выглядит так: когда поступает новая заявка, сейлз получает данные о ней из CRM с помощью скилла. Другой скилл делает предварительный анализ клиента и заявки. Сейлз может поразгонять его в глубину вместе с агентом. Дальше первичный созвон с клиентом. Запись попадает в папку лида в репозитории, и агент может использовать её для помощи в генерации первичного решения. Аналогично с записью брейншторма команды. На основе собранных артефактов сейлз составляет план КП. А партнёр или архитектор решения сразу получает весь набор артефактов, просто спуллив апдейт репозитория.
В прошлых постах много писал про разработку. А что поменялось в процессах других команд?
Сегодня поговорим про эволюцию отдела продаж. За последние несколько месяцев попробовали много инструментов.
Начиналось всё, думаю, как и у всех, с того, что сейлзы начали использовать нейро-инструменты. Например, пробовали обсуждать с ChatGPT свои сделки.
Сами лиды при этом лежат в CRM, сметы считаются в таблицах, КП готовится в Фигме, а процесс выработки решения довольно сложный и состоит из встреч с партнёрами, клиентом, технической командой и т. д.
Когда сейлзы начали использовать ИИ-инструменты, это, как и в случае с разработкой, ускорило работу и сделало её местами более качественной за единицу времени. Но это всё ещё не кратное ускорение / улучшение.
Мы смогли продвинуться чуть дальше. Но сначала нужно понять классические проблемы отдела продаж (не только наших). Изучение кейсов и продуктов компании обычно занимает пару месяцев, адаптация сейлза к процессу сбора КП, синхронизация с командой — всё это приводит к продолжительному онбордингу, на который накладывается ещё и длинный цикл сделки. В итоге сейлз может начать что-то приносить через полгода. При этом капитализация отдела продаж в основном в:
▫️ контактах в CRM
▫️ отработанных лидах и кейсах (которые часто неструктурированы и разбросаны по системам)
▫️ всяческих шаблонах и готовых упаковках
▫️ опыте конкретных людей
Соответственно, чтобы выходить на новый уровень качества и скорости, нужно усиливать эту капитализацию с ИИ.
Все перечисленные пункты на самом деле раскладываются на 2 задачи:
— накопление знаний: чёткая структура, быстрый и простой доступ
— типовые кросс-командные решения
Поэтому первое, что мы сделали — ИИ-агента с поиском по нашим решениям. Он позволяет быстрее ориентироваться в продуктах и кейсах (которых, на минуточку, несколько сотен, и никто не знает про все). А второе — агент, который помогает оценивать уровень качества КП по оформлению и принятым практикам. Таким образом регламенты и подходы становятся не просто рекомендациями (которые на практике быстро деградируют), а правилами, заложенными в систему.
Но этого было недостаточно. Во-первых, оба инструмента находятся в нашей внутренней системе. Получается, сейлз работает в CRM, сидит в чатах и почте, звонит по телефону, готовит КП вместе с GPT и ещё кучу всего делает. И тут ему ещё одну вспомогательную систему дали. Мотивации туда заходить не так много. Новые инструменты добавляются централизованно, а значит долго, и не извлекают экспертизу и знания конкретного сейлза в общие практики. Артефакты подготовки конкретного КП всё также передаются в гугл-папках, CRM, чатах и т. д.
И тут становится понятно, что эти проблемы давно решены в разработке:
▫️ экспертиза, знания и правила — это скиллы для ИИ-агентов
▫️ общее хранилище данных — репозитории, где работают все инженеры (вместе с ИИ-агентами) в одном контексте
▫️ генерация артефактов с кодинговыми агентами работает лучше всяких чатов с GPT
Поэтому решение стало очевидным: сейлзы должны начать накапливать знания о своих пресейлах и генерить решения вместе с техническими командами так же, как это делают разработчики. Мы сделали один общий git-репозиторий для продаж. Он содержит: схему данных о клиентах и их заявках для накопления всех артефактов, MCP CRM, набор скиллов для работы с кодинговыми агентами.
Процесс выглядит так: когда поступает новая заявка, сейлз получает данные о ней из CRM с помощью скилла. Другой скилл делает предварительный анализ клиента и заявки. Сейлз может поразгонять его в глубину вместе с агентом. Дальше первичный созвон с клиентом. Запись попадает в папку лида в репозитории, и агент может использовать её для помощи в генерации первичного решения. Аналогично с записью брейншторма команды. На основе собранных артефактов сейлз составляет план КП. А партнёр или архитектор решения сразу получает весь набор артефактов, просто спуллив апдейт репозитория.
🔥9❤7
Forwarded from Код в каске — герои цифровизации девелопмента
Про ИИ говорят много. Про то, где он реально помогает девелоперам — значительно меньше.
На карточках собрали конкретные сценарии, которые уже используют наши клиенты: с форматом и ожидаемым эффектом. Большинство из них запускается на базе того, что у девелопера уже есть: внутренние документы, регламенты, данные из CRM.
💬 Листайте и оставляйте заявку, чтобы связаться с нашим экспертом и обсудить внедрение ИИ в вашей компании
На карточках собрали конкретные сценарии, которые уже используют наши клиенты: с форматом и ожидаемым эффектом. Большинство из них запускается на базе того, что у девелопера уже есть: внутренние документы, регламенты, данные из CRM.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6
Nocode умер, да здравствует nocode
Всю дорогу разработчики пытались упрощать создание программ. Начинали с Assembler, с каждым новым языком программирования повышали уровень абстракции, создавали библиотеки / фреймворки для упрощения и ускорения разработки.
В итоге мы дошли от Assembler до Python, Go, TypeScript и других языков. Попытались пойти дальше и сделать инструменты nocode — ещё одну абстракцию, которая позволит создавать системы не программистам.
В итоге получали очень нишевый инструмент автоматизации или очередной язык программирования мышкой с проблемами версионируемости и наблюдаемости. Характерный пример — n8n. Кто на нём пытался собрать что-то больше прототипа, неизбежно сталкивался с множеством проблем, которые решались большими костылями.
С приходом кодинговых агентов целесообразность в ноукоде драматически упала: агенты кратно лучше работают с кодом, чем с платформами ноукода, е2е реализуют более сложные системы без болей ноукода, так как системы построены на коде, для которого придумали механизмы версионирования, стабильного обновления и наблюдаемости.
Но все же возникает вопрос, как построить систему с идеологией ноукода, где разрабатывают и обновляют не программисты, есть простой деплой без девопсов и наглядная визуализация. При этом без минусов ноукода, описанных выше.
Этот подход — Spec-Driven Development.
Давайте вспомним подход enterprise-компаний: есть бизнес аналитики, которые формируют требования и скоуп, есть системные аналитики и архитекторы — они придумывают, как система вписывается в текущий ландшафт и взаимодействует с другими системами. Программисту в таких компаниях остаётся транслировать проработанные требования в код, доработав детали, которые не учли на этапе проектирования.
В итоге получается, что текущие процессы компании уже заточены под формирование требований и только процесс создания кода остаётся всё ещё на людях. А что, если принять документацию как код, и на её основе генерировать код с помощью агентов.
В итоге мы получим новый уровень абстракции nocode в виде спецификации и детерминированную реализацию в формате кода и тестов, которая лишена минусов ноукод-систем. При этом полностью отходим от участия кодера (намеренно использовал эту формулировку вместо «разработчика») в создании кода.
Возникает справедливое возражение: агенты же нейрослоп кодовый генерируют. Через некоторое время это невозможно будет поддерживать.
Да, всё так. Поэтому нужно строить принципы-правила-навыки, по которым агент будет работать. То есть задача разработчика смещается от ручной трансляции требований из спецификации в код в создание конвейера для агентов, мониторинга качества «продукции» и оперативного реагирования на нарушение технологического процесса.
Как это реализовать, поделюсь в следующем посте. Чтобы сузить скоуп, расскажу про агентские автоматизации, а не системы общего назначения.
#александр_опрышко
Всю дорогу разработчики пытались упрощать создание программ. Начинали с Assembler, с каждым новым языком программирования повышали уровень абстракции, создавали библиотеки / фреймворки для упрощения и ускорения разработки.
В итоге мы дошли от Assembler до Python, Go, TypeScript и других языков. Попытались пойти дальше и сделать инструменты nocode — ещё одну абстракцию, которая позволит создавать системы не программистам.
В итоге получали очень нишевый инструмент автоматизации или очередной язык программирования мышкой с проблемами версионируемости и наблюдаемости. Характерный пример — n8n. Кто на нём пытался собрать что-то больше прототипа, неизбежно сталкивался с множеством проблем, которые решались большими костылями.
С приходом кодинговых агентов целесообразность в ноукоде драматически упала: агенты кратно лучше работают с кодом, чем с платформами ноукода, е2е реализуют более сложные системы без болей ноукода, так как системы построены на коде, для которого придумали механизмы версионирования, стабильного обновления и наблюдаемости.
Но все же возникает вопрос, как построить систему с идеологией ноукода, где разрабатывают и обновляют не программисты, есть простой деплой без девопсов и наглядная визуализация. При этом без минусов ноукода, описанных выше.
Этот подход — Spec-Driven Development.
Давайте вспомним подход enterprise-компаний: есть бизнес аналитики, которые формируют требования и скоуп, есть системные аналитики и архитекторы — они придумывают, как система вписывается в текущий ландшафт и взаимодействует с другими системами. Программисту в таких компаниях остаётся транслировать проработанные требования в код, доработав детали, которые не учли на этапе проектирования.
В итоге получается, что текущие процессы компании уже заточены под формирование требований и только процесс создания кода остаётся всё ещё на людях. А что, если принять документацию как код, и на её основе генерировать код с помощью агентов.
В итоге мы получим новый уровень абстракции nocode в виде спецификации и детерминированную реализацию в формате кода и тестов, которая лишена минусов ноукод-систем. При этом полностью отходим от участия кодера (намеренно использовал эту формулировку вместо «разработчика») в создании кода.
Возникает справедливое возражение: агенты же нейрослоп кодовый генерируют. Через некоторое время это невозможно будет поддерживать.
Да, всё так. Поэтому нужно строить принципы-правила-навыки, по которым агент будет работать. То есть задача разработчика смещается от ручной трансляции требований из спецификации в код в создание конвейера для агентов, мониторинга качества «продукции» и оперативного реагирования на нарушение технологического процесса.
Как это реализовать, поделюсь в следующем посте. Чтобы сузить скоуп, расскажу про агентские автоматизации, а не системы общего назначения.
#александр_опрышко
👍13❤8
Как ИИ работает в девелопменте: 8 практических сценариев
Девелоперы накапливают огромные объёмы информации: регламенты, проектную документацию, BIM-отчёты, записи звонков и переписки в CRM. Эти данные находятся в разрозненных источниках, поэтому ручной поиск отнимает время. Сотрудники тонут в операционке, а решения принимаются медленнее.
Ускорить работу с данными и автоматизировать частотные операции, помогают AI-решения. Наш опыт показывает, что большинство прикладных сценариев внедрения строятся на двух механиках:
▫️ анализ базы знаний и контекстный поиск по корпоративным источникам;
▫️ генерация текстовых и визуальных материалов на основе реальных данных компании.
В статье показали 8 рабочих сценариев, для трёх основных этапов: продажи и маркетинг, строительство и эксплуатация.
Например, AI-ассистент во время разговора подсказывает менеджеру ответы по ипотеке и юридическим нюансам. А помощник жителей составляет и регистрирует обращение в УК по короткому голосовому сообщению вроде: «В лифте нет света».
Для каждого решения разобрали требования к данным, сроки запуска проекта и ожидаемый бизнес-эффект.
💬 Заходите почитать
Девелоперы накапливают огромные объёмы информации: регламенты, проектную документацию, BIM-отчёты, записи звонков и переписки в CRM. Эти данные находятся в разрозненных источниках, поэтому ручной поиск отнимает время. Сотрудники тонут в операционке, а решения принимаются медленнее.
Ускорить работу с данными и автоматизировать частотные операции, помогают AI-решения. Наш опыт показывает, что большинство прикладных сценариев внедрения строятся на двух механиках:
▫️ анализ базы знаний и контекстный поиск по корпоративным источникам;
▫️ генерация текстовых и визуальных материалов на основе реальных данных компании.
В статье показали 8 рабочих сценариев, для трёх основных этапов: продажи и маркетинг, строительство и эксплуатация.
Например, AI-ассистент во время разговора подсказывает менеджеру ответы по ипотеке и юридическим нюансам. А помощник жителей составляет и регистрирует обращение в УК по короткому голосовому сообщению вроде: «В лифте нет света».
Для каждого решения разобрали требования к данным, сроки запуска проекта и ожидаемый бизнес-эффект.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8🔥5
Forwarded from Код в каске — герои цифровизации девелопмента
Покупатели часто выбирают квартиры вечером, ночью или в выходные, когда отдел продаж не на связи. Если в этот момент клиент не получает быстрый ответ на вопрос, его интерес остывает.
Мы запустили ИИ-ассистента для девелоперов, который помогает сохранить конверсию воронки продаж и разгрузить менеджеров.
🟢 Ассистент круглосуточно консультирует пользователей, подбирает подходящие лоты по свободному запросу и переводит диалог в запись на просмотр, когда клиент готов.
🟢 Покупатели, которые еще не готовы к разговору с отделом продаж, могут задать вопросы о проекте, ценах и условиях, не опасаясь навязчивых звонков.
🟢 Первичные справочные диалоги ассистент берет на себя, поэтому менеджер подключается сразу к разговору с теплым клиентом.
😎 Подключим ассистента за 2 дня, а если он не принесет больше лидов, пилот будет за наш счёт. Оставить заявку
Мы запустили ИИ-ассистента для девелоперов, который помогает сохранить конверсию воронки продаж и разгрузить менеджеров.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍2
KTS × Selectel создали ИИ-поиск для компаний, где каждый ответ нужно подтвердить документом
В строительстве, производстве, добывающей отрасли и финансах сотрудники работают с большими массивами регламентов, ГОСТов и внутренних документов. При подготовке отчёта, прохождении проверки или аудита данные приходится искать в нескольких системах и сверять с первоисточниками. На это может уходить до нескольких часов в день.
Совместное решение KTS и Selectel помогает значительно сократить время поиска информации. Сотрудник задаёт вопрос на естественном языке и получает структурированный ответ со ссылкой на документ и конкретную страницу.
Также ассистент умеет:
— подключаться к wiki, СЭД, файловым хранилищам и нормативным источникам;
— суммаризировать длинные документы;
— выделять тезисы, обязательства и риски;
— экспортировать ответы в Word и PDF;
— учитывать права пользователей через системы управления доступом (IAM и SSO).
Безопасность заложена в архитектуру решения на нескольких уровнях. Система автоматически маскирует чувствительные данные, а встроенные механизмы контроля (guardrails) проверяют запросы и ответы ИИ на соответствие заданным политикам безопасности.
ИИ-ассистент может закрывать большинство рутинных типовых запросов. Благодаря готовой инфраструктуре KTS AI Platform пилот можно запустить за две недели.
Проверьте решение на собственных документах: загрузите их в настроенную базу знаний и оцените качество ответов.
Протестировать ИИ-ассистента
В строительстве, производстве, добывающей отрасли и финансах сотрудники работают с большими массивами регламентов, ГОСТов и внутренних документов. При подготовке отчёта, прохождении проверки или аудита данные приходится искать в нескольких системах и сверять с первоисточниками. На это может уходить до нескольких часов в день.
Совместное решение KTS и Selectel помогает значительно сократить время поиска информации. Сотрудник задаёт вопрос на естественном языке и получает структурированный ответ со ссылкой на документ и конкретную страницу.
Также ассистент умеет:
— подключаться к wiki, СЭД, файловым хранилищам и нормативным источникам;
— суммаризировать длинные документы;
— выделять тезисы, обязательства и риски;
— экспортировать ответы в Word и PDF;
— учитывать права пользователей через системы управления доступом (IAM и SSO).
Безопасность заложена в архитектуру решения на нескольких уровнях. Система автоматически маскирует чувствительные данные, а встроенные механизмы контроля (guardrails) проверяют запросы и ответы ИИ на соответствие заданным политикам безопасности.
ИИ-ассистент может закрывать большинство рутинных типовых запросов. Благодаря готовой инфраструктуре KTS AI Platform пилот можно запустить за две недели.
Проверьте решение на собственных документах: загрузите их в настроенную базу знаний и оцените качество ответов.
Протестировать ИИ-ассистента
🔥12
Запустили AI-ассистента для ФК «Динамо» Москва
ФК «Динамо» Москва — один из самых известных футбольных клубов России с большой аудиторией болельщиков. У клуба много информационных поводов, а у пользователей регулярно возникают повторяющиеся вопросы: когда следующий матч, где купить билеты, что нового в команде, какие товары доступны в магазине.
Чтобы быстрее обрабатывать такие запросы и снизить нагрузку на поддержку, мы запустили для ФК «Динамо» Москва AI-ассистента. Он уже работает в онлайн-чате на сайте и во внутреннем портале для болельщиков.
Ассистент помогает подобрать товары в интернет-магазине, рассказывает новости, показывает расписание матчей, объясняет, как купить билеты, и предоставляет статистику по игрокам.
Решение разработали за несколько дней на собственной платформе AI Assistant. Агент интегрирован с внутренними системами ФК «Динамо» Москва, поэтому получает актуальные данные в реальном времени и передаёт их в LLM модели для формирования ответа.
Для команды клуба мы также сделали административную панель. В ней можно настраивать сценарии, отслеживать работу ассистента и контролировать качество ответов.
Сейчас вместе с ФК «Динамо» Москва продолжаем расширять функциональность ассистента и добавлять новые точки его присутствия.
ФК «Динамо» Москва — один из самых известных футбольных клубов России с большой аудиторией болельщиков. У клуба много информационных поводов, а у пользователей регулярно возникают повторяющиеся вопросы: когда следующий матч, где купить билеты, что нового в команде, какие товары доступны в магазине.
Чтобы быстрее обрабатывать такие запросы и снизить нагрузку на поддержку, мы запустили для ФК «Динамо» Москва AI-ассистента. Он уже работает в онлайн-чате на сайте и во внутреннем портале для болельщиков.
Ассистент помогает подобрать товары в интернет-магазине, рассказывает новости, показывает расписание матчей, объясняет, как купить билеты, и предоставляет статистику по игрокам.
Решение разработали за несколько дней на собственной платформе AI Assistant. Агент интегрирован с внутренними системами ФК «Динамо» Москва, поэтому получает актуальные данные в реальном времени и передаёт их в LLM модели для формирования ответа.
Для команды клуба мы также сделали административную панель. В ней можно настраивать сценарии, отслеживать работу ассистента и контролировать качество ответов.
Сейчас вместе с ФК «Динамо» Москва продолжаем расширять функциональность ассистента и добавлять новые точки его присутствия.
👍6🔥3❤2