Кейсы

Задача. Специалисты по закупкам по 44-ФЗ и 223-ФЗ тратят часы на поиск норм, расчёт НМЦК и подготовку документов. Нужен был ассистент, который отвечает по законодательству, работает с данными платформы и не ошибается в расчётах.

Архитектура. Мультиагентный граф на LangGraph: супервизор со структурированным выводом маршрутизирует запросы между тремя специализированными агентами, режим plan-and-execute для сложных задач, 35 асинхронных инструментов, RAG-контур по нормативной базе, critic-модель, проверяющая расчёты НМЦК, память диалога с контрольными точками. Наблюдаемость: LangSmith + Sentry. Качество: ~770 автотестов на pytest.

Эволюция. Первая версия была собрана на n8n, затем перенесена в LangFlow и в итоге переписана в код на LangGraph — это позволило получить контроль над качеством, тестируемость и предсказуемую стоимость инференса.

Результат. Ассистент работает в production для пользователей платформы; ранняя версия дала около 4× рост аудитории продукта.

Стек: Python, LangGraph, OpenAI API, httpx, Qdrant, PostgreSQL, LangSmith, Sentry, pytest.

Задача. Специалист НСИ вручную переносил позиции из спецификаций, накладных и УПД в справочник: определял категорию, заполнял атрибуты, искал дубли. На одну позицию уходило 15 минут, а один товар появлялся под разными названиями и расползался в закупки, склад и учёт.

Архитектура. Отечественная LLM GigaChat встроена в рабочее место НСИ на Odoo. Модель интерпретирует свободное описание, предлагает каноническое наименование, категорию и атрибуты, участвует в семантическом поиске дублей. Детерминированные правила Odoo проверяют обязательные поля и допустимые значения до сохранения; специалист подтверждает карточку (human-in-the-loop), а его исправления становятся обратной связью для промптов и правил. Интеграция с 1С и ERP — через REST API.

Результат (по замерам на 6 категориях). 1,5 минуты на позицию вместо 15 — сокращение трудозатрат в 10 раз; дублей меньше на 60–70%; заполненность характеристик выросла на 40–60%. При потоке 50 позиций в день годовой эффект — около 3,3 млн ₽, окупаемость менее полугода.

Стек: GigaChat, Odoo, Python, PostgreSQL, REST API.

Задача. Подготовка закупки по 44-ФЗ/223-ФЗ — это десятки ручных операций: определение ОКПД и КТРУ, подбор характеристик, сбор и анализ коммерческих предложений, расчёт и обоснование НМЦК, проверка нацрежима, составление ТЗ.

Решение. Платформа с базой контрактов и цен, поиском по Elasticsearch, расчётными модулями и ИИ-контуром, который подбирает коды, характеристики и аналоги. Архитектура, команда до 12 человек и развитие продукта — моя зона ответственности. На базе платформы выполнены кастомизации и white-label внедрения для крупных корпоративных заказчиков, в том числе SRM-системы.

Результат (по тестированию заказчиками). Время на полный цикл операций сократилось со 147 до 21 минуты. Для предприятия с 1 000 номенклатур годовой эффект — около 2,1 млн ₽ при стоимости лицензий 350 тыс. ₽, окупаемость менее года.

Стек: Python, Django, DRF, Celery, PostgreSQL, Elasticsearch, LLM-модули, Docker.

Задача. Закупочному блоку нужно было заранее видеть движение цен на ключевые позиции и факторы, которые на них влияют, чтобы управлять рисками и сроками закупок.

Решение. Сервис с ML-прогнозированием цен по временным рядам, NLP-классификацией новостей, пайплайном сбора данных из нескольких источников, модулями риск-менеджмента и веб-дашбордом. Система интегрирована с корпоративной шиной данных заказчика.

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

Стек: Python, ML (временные ряды), NLP, PostgreSQL, веб-дашборд, интеграция с корпоративной шиной.

Задача. Пациент приходит к врачу с разрозненными жалобами и не всегда понимает, к какому специалисту идти. Нужен сервис, который помогает собрать жалобы, сформировать резюме обращения и подобрать врача из каталога подключённых клиник — при этом не превращаясь в «ИИ-доктора».

Как работает. Пользователь заполняет опросник (пол, возраст, жалобы и уточняющие вопросы) — за себя или за близкого: ребёнка, родителя. По желанию уточняет жалобы в беседе с ИИ-помощником, который собирает сведения и отвечает на общие вопросы о самочувствии, не ставя диагноз. Сервис формирует резюме обращения: структурированный перечень жалоб, ответов и вопросов к врачу с пометкой, к специалистам какого профиля с такими жалобами обычно обращаются. Дальше пользователь выбирает врача из каталога и оставляет заявку; врач видит её вместе с резюме в личном кабинете и подтверждает либо отклоняет.

Безопасность и данные. При признаках состояний, требующих неотложной помощи, сервис прерывает опросник и показывает контакты экстренных служб (103, 112) — заявка не оформляется. Эти правила заданы детерминированно и не зависят от ответа ИИ-модели. Резюме передаётся врачу только с отдельного согласия на каждую заявку. В модель уходят только обезличенные сведения (пол, возраст, жалобы, ответы, реплики без прямых идентификаторов); персональные данные аккаунтов, врачей и клиник модели не передаются.

Принципы. Это пример ИИ-продукта в регулируемой сфере: границы того, что делает модель, заданы архитектурой, а не промптом; критичные решения детерминированы; персональные данные не покидают контур сервиса. Сам сервис — информационный: он не является медицинским изделием, не ставит диагнозов, не назначает лечение и не заменяет приём врача. Резюме обращения — изложение слов пользователя, а медицинские выводы остаются за врачом.

Компоненты: Python, LLM-помощник с обезличиванием данных, опросник с детерминированными правилами, личные кабинеты пациента и врача, каталог клиник с интеграцией по API.

Задача. Локальные документы компании — регламенты, положения, инструкции — зависят от федеральных, региональных, отраслевых и внутренних нормативных актов. Специалисты не всегда успевают отслеживать изменения и вовремя актуализировать свои документы, а цена пропущенной поправки — финансовые, временные и репутационные потери.

Решение. Система отслеживает изменения во внешних и внутренних нормативных актах, сопоставляет их с локальной документацией и показывает, какие положения устарели и как их нужно переформулировать. Специалист согласовывает правки — после этого система вносит их в документ сама. Мониторинг и рутина — на системе, решение — за человеком.

Контекст. Проект прорабатывался для банковской среды: анализ продуктовой линейки банка показал, что решение не пересекается с существующими продуктами, а закрывает отдельную нишу — работу с нормативными документами.

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

Стек: Python, LLM-анализ и сопоставление текстов, RAG по нормативной базе, мониторинг источников, согласование изменений с участием человека.