deploy-cutover.py — это наш внутренний деплой-скрипт. Настроить Git с CI/CD локально ничто не мешало, вопрос в том, что логика агента живет в платформе и обновляется через API. У нас это схожая идея под специфику, она отличается только целью деплоя. В статье дополнили, спасибо, что отметили
Вообще поднятие самой модели - это самая скучная часть как раз. Запуск Квена, или Гермеса, или чего угодно, через ollama/lm studio — это как раз «школьные» 20%, про которые прямым текстом написано. Мы хотели рассказать о нюансах, которые остаются, когда модель уже работает:
— перенос продуктовых модулей в закрытый контур без интернета и без Git-based CI/CD (manifest-driven деплой через deploy-cutover.py); — замена облачной векторизации на собственный zvec-search с локальным BGE-m3 и ранжированием; — деградация по latency в 3–10× и что с этим делать на уровне UX (стриминг), а не «подождём»; — что делать с инструментами, которые в air-gapped просто отваливаются (проверка контрагентов, веб-поиск, браузерная автоматизация).
«Положить Гермеса в докер и сделать пару навыков» — это ровно тот demo-уровень, который у клиента в проде живёт примерно неделю. Мы хотели рассказать про разницу между «пара навыков на ноутбуке» и продуктом, который интегрирован в рабочие процессы предприятия и работает в изолированном контуре под нагрузкой. В этом был смысл, и для потенциальных клиентов это было бы важно знать.
Про скорость. Точечный поиск по индексу и аналитическая агрегация — это разные классы операций. Когда система отвечает на «сколько мы должны контрагентам по категории "электроэнергия" за квартал в разрезе ЦФО», она не ищет одну строку, а делает GROUP BY с join по нескольким таблицам реквизитов, фильтрами по статусам и валютной нормализацией. В OLTP-базе на живых данных это честные 2–4 секунды, и мы считаем, это нормальная цифра.
Сотни миллисекунд по миллиону записей — это про columnar storage и pre-aggregated кубы (ClickHouse, Druid, Vertica). Они работают, но требуют отдельного ETL-контура и теряют свежесть данных. Для ad-hoc аналитики в ERP, где директор хочет ответ по состоянию «сейчас», цена такого контура не оправдана.
Отдельно про модель данных: реквизиты заявок у нас гибкие — клиент сам определяет, какие поля и категории ему нужны, без релиза бэкенда. За эту гибкость платим join-ами. Это сознательный архитектурный выбор, а не недонастроенная база. Кэш в такой схеме — стандартная практика BI: один и тот же дашборд открывают десятки раз в день, пересчитывать одно и то же бессмысленно.
Про «зачем тут LLM». Тут важная развилка: LLM в нашей схеме ничего не считает. Считает строгий SQL-инструмент с фиксированной семантикой, чтобы исключить галлюцинации в цифрах. LLM тут маршрутизатор, она помогает перевести «сколько мы должны за свет за прошлый месяц» в вызов нужного инструмента с правильными ID категорий, статусов и периода.
Тезис про «ограниченное количество вариантов» — здесь как раз обратное. В реальном контуре 40+ категорий заявок × 15+ статусов × произвольные контрагенты × любой временной срез × агрегация по любому из десятков реквизитов, десятки тысяч осмысленных комбинаций, сколько точно сказать не можем, NDA. Конструктор фильтров такое тянет, но директору придется потратить на фильтр много времени, а у агента на естественном языке порог входа нулевой.
Вообще модель «LLM с доступом к высокоуровневому бэкенду, пользователь либо сам фильтрует, либо спрашивает на естественном языке» — это как раз то, что у нас построено. Конструктор отчётов для аналитиков остался, агент добавлен сверху для тех, кому быстрее спросить. Со старым добрым программированием тоже сложно, тогда каждый новый отчёт нужно запрашивать через тикет на разработку, а LLM-это закрывает одной интеграцией. У нас система катится в десятки разных клиентов с разными процессами, так что тут ещё момент оптимизации ресурсов.
Расширили с командой пример в статье, чтобы было более понятно. Глобально ИИ здесь выступает как бизнес-аналитик: если деталей мало или описание не очень понятно, он предполагает и отправляет варианты РП, а РП уже уточняет.
Отвечаем) Используется и Рутокен. КЭДО внедрено. Срок действия ключей зафиксирован сроком сертификата вендора, 12 месяцев. Формат подписи — открепляемая. Сертификаты хранятся в локальных УЦ.
Голосование доступно зарегистрированным ИТ-руководителям. Авторизуйтесь на сайте Global CIO, чтобы проголосовать и задать вопросы руководителю проекта.
При значительном росте нагрузки можно разделить потоки событий на несколько токенов Билайна. Точки входа в систему тоже можно разделить при необходимости.
deploy-cutover.py — это наш внутренний деплой-скрипт. Настроить Git с CI/CD локально ничто не мешало, вопрос в том, что логика агента живет в платформе и обновляется через API. У нас это схожая идея под специфику, она отличается только целью деплоя. В статье дополнили, спасибо, что отметили
Вообще поднятие самой модели - это самая скучная часть как раз. Запуск Квена, или Гермеса, или чего угодно, через ollama/lm studio — это как раз «школьные» 20%, про которые прямым текстом написано. Мы хотели рассказать о нюансах, которые остаются, когда модель уже работает:
— перенос продуктовых модулей в закрытый контур без интернета и без Git-based CI/CD (manifest-driven деплой через deploy-cutover.py);
— замена облачной векторизации на собственный zvec-search с локальным BGE-m3 и ранжированием;
— деградация по latency в 3–10× и что с этим делать на уровне UX (стриминг), а не «подождём»;
— что делать с инструментами, которые в air-gapped просто отваливаются (проверка контрагентов, веб-поиск, браузерная автоматизация).
«Положить Гермеса в докер и сделать пару навыков» — это ровно тот demo-уровень, который у клиента в проде живёт примерно неделю. Мы хотели рассказать про разницу между «пара навыков на ноутбуке» и продуктом, который интегрирован в рабочие процессы предприятия и работает в изолированном контуре под нагрузкой. В этом был смысл, и для потенциальных клиентов это было бы важно знать.
Про скорость. Точечный поиск по индексу и аналитическая агрегация — это разные классы операций. Когда система отвечает на «сколько мы должны контрагентам по категории "электроэнергия" за квартал в разрезе ЦФО», она не ищет одну строку, а делает GROUP BY с join по нескольким таблицам реквизитов, фильтрами по статусам и валютной нормализацией. В OLTP-базе на живых данных это честные 2–4 секунды, и мы считаем, это нормальная цифра.
Сотни миллисекунд по миллиону записей — это про columnar storage и pre-aggregated кубы (ClickHouse, Druid, Vertica). Они работают, но требуют отдельного ETL-контура и теряют свежесть данных. Для ad-hoc аналитики в ERP, где директор хочет ответ по состоянию «сейчас», цена такого контура не оправдана.
Отдельно про модель данных: реквизиты заявок у нас гибкие — клиент сам определяет, какие поля и категории ему нужны, без релиза бэкенда. За эту гибкость платим join-ами. Это сознательный архитектурный выбор, а не недонастроенная база. Кэш в такой схеме — стандартная практика BI: один и тот же дашборд открывают десятки раз в день, пересчитывать одно и то же бессмысленно.
Про «зачем тут LLM». Тут важная развилка: LLM в нашей схеме ничего не считает. Считает строгий SQL-инструмент с фиксированной семантикой, чтобы исключить галлюцинации в цифрах. LLM тут маршрутизатор, она помогает перевести «сколько мы должны за свет за прошлый месяц» в вызов нужного инструмента с правильными ID категорий, статусов и периода.
Тезис про «ограниченное количество вариантов» — здесь как раз обратное. В реальном контуре 40+ категорий заявок × 15+ статусов × произвольные контрагенты × любой временной срез × агрегация по любому из десятков реквизитов, десятки тысяч осмысленных комбинаций, сколько точно сказать не можем, NDA. Конструктор фильтров такое тянет, но директору придется потратить на фильтр много времени, а у агента на естественном языке порог входа нулевой.
Вообще модель «LLM с доступом к высокоуровневому бэкенду, пользователь либо сам фильтрует, либо спрашивает на естественном языке» — это как раз то, что у нас построено. Конструктор отчётов для аналитиков остался, агент добавлен сверху для тех, кому быстрее спросить. Со старым добрым программированием тоже сложно, тогда каждый новый отчёт нужно запрашивать через тикет на разработку, а LLM-это закрывает одной интеграцией. У нас система катится в десятки разных клиентов с разными процессами, так что тут ещё момент оптимизации ресурсов.
Общение с клиентом на регулярных встречах никуда не уходит, конечно) Просто это немного ускоряет и упрощает процесс
Расширили с командой пример в статье, чтобы было более понятно. Глобально ИИ здесь выступает как бизнес-аналитик: если деталей мало или описание не очень понятно, он предполагает и отправляет варианты РП, а РП уже уточняет.
Статья с примерами еще будет обязательно, вот здесь на конференции показывал один: режим консилиума по клиентскому вопросу https://vkvideo.ru/video-211209965_456239088?list=ca2a16783d9e9dc0e8
Таймкод 11:09
КЭДО внедрено не на «Первой Форме»
Отвечаем) Используется и Рутокен. КЭДО внедрено. Срок действия ключей зафиксирован сроком сертификата вендора, 12 месяцев. Формат подписи — открепляемая. Сертификаты хранятся в локальных УЦ.
По поводу интеграции с 1С. Подробности есть в нашем хэлпе: https://help.1forma.ru/Admin_Manual/1c_sync.htm, https://help.1forma.ru/Maintenance/1c_admin.htm
Проект участвует в конкурсе Global CIO 🔥
Будем благодарны за каждый голос и вопрос в комментариях: https://globalcio.ru/projects/52503/
Голосование доступно зарегистрированным ИТ-руководителям. Авторизуйтесь на сайте Global CIO, чтобы проголосовать и задать вопросы руководителю проекта.
В голову к тем, кто за это был ответственный, не залезть)
Сейчас выбора у них в любом случае особо не было
При значительном росте нагрузки можно разделить потоки событий на несколько токенов Билайна. Точки входа в систему тоже можно разделить при необходимости.
Менеджеры по продажам с рабочих мобильных
Да, Шерпойнт можно заменить и с 1С интегрироваться тоже
Но что это за жизнь....