AVZ Selector

Команда YYTECH разработала AVZ Selector для вентиляторного завода АВЗ через партнёра в Казахстане. Завод получал проектные PDF от проектировщиков и дилеров. Инженеры вручную искали нужные разделы, переносили характеристики в таблицы, выбирали модели по каталогу и собирали спецификацию. При росте потока заявок такая последовательная работа требовала увеличивать команду производственно-технического отдела (ПТО).

AVZ Selector объединяет чтение проектного документа, отбор номенклатуры завода, подбор моделей, проверку результата и выпуск XLSX. ИИ извлекает из документа таблицы и параметры позиций, а модель по каталогу выбирают правила системы. Инженер разбирает предупреждения и уточняет спорные позиции.

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

Система определяет серию оборудования по наименованию и обозначению в проекте. Например, ВР 80-75 переводится в серию RAD 100, а ВР 300-45 — в RAD 300. Если проектировщик уже указал модель АВЗ, система оставляет её и сверяет с каталогом. Готовая приточная установка выводится одной строкой AHU, её внутренние элементы отдельно не подбираются.

Для поддерживаемых серий система проверяет расход и давление по каталожным характеристикам, учитывает исполнение и необходимые размеры. При выборе допустимого варианта применяются правила конкретной серии. Например, внутри RAD учитываются мощность и типоразмер. Противодымное назначение установки влияет на маршрут подбора и исполнение оборудования. Характеристики любой модели инженер может посмотреть во встроенном каталоге.

Подбор охватывает связанные комплектующие. Гибкие вставки, монтажный стакан и шкаф управления согласуются с выбранным вентилятором, если для этого типа есть правило. Для канального вентилятора K при необходимости добавляются два быстросъёмных хомута. Инженеру не нужно отдельно подбирать вставки, стаканы и хомуты к уже выбранному вентилятору.

Для поддерживаемых клапанов правила учитывают форму и размер, исполнение и напряжение привода. Для противопожарных клапанов предусмотрены секционирование и расчёт количества приводов. В итоговой таблице инженер получает выбранную номенклатуру и примечания к позиции.

Рабочая таблица показывает исходные позиции, подобранные модели АВЗ, количества и замечания. При сохранённом ходе выбора инженер может открыть пояснение: какие параметры учитывались и почему выбран каталожный вариант. По этому пояснению инженер проверяет, почему выбрана модель, а не только какая.

Если обязательных данных не хватает или вариант не поддерживается, система оставляет позицию в таблице с предупреждением. Инженер может открыть исходный PDF, исправить ячейки, добавить или удалить строки. Система также использует документированные значения по умолчанию: например, длину 1000 мм для KSG/KSP, если она не указана.

Кейс показывает результат обработки того же проекта отопления и вентиляции (ОВ), листы которого приведены как входные примеры: PDF на 66 листов, спецификация оборудования на 23 листах. В прогоне 07.07.2026 система сформировала 75 позиций. Из них 58 подобраны автоматически без предупреждений, 9 строк — готовые приточные установки, каждая выведена одной строкой AHU, ещё 8 отмечены для проверки инженером с причиной в примечании. Например, крышный вентилятор дымоудаления ВКРС-12.5Ду-22 на 63 000 м³/ч и 900 Па подобран как RFS-1120-SE400-30.0/6-GP, а клапан дымоудаления ДКС-1600×400 — как КПЖ-ДУ 1600x400 из двух секций с приводом 4 Н·м на каждую. Прогон выполнен в локальной копии приложения; это иллюстрация работы, а не статистика промышленной эксплуатации.

Замечание можно оставить прямо в строке результата. Обсуждение связано с проектом и запуском подбора, поддерживает ответы и статус «Решено». Команда видит обращения в общем реестре с фильтрами и переходом к нужной позиции. Разработчики видят исходные данные и результат подбора, по которым возникло замечание, и по ним уточняют правила.

В веб-интерфейсе инженер переключает проекты, ищет, проверяет и правит позиции, смотрит историю. В Telegram пользователь отправляет PDF боту, получает уведомление о готовности и файл XLSX. Оба сценария дают доступ к результату обработки без ручного переноса строк.

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

Стандартный релиз проходит проверку на эталонном наборе с вручную проверенным ожидаемым результатом: четыре реальных проекта ОВ и две синтетические проверки на «шумных» спецификациях клапанов. Оценивается этап извлечения позиций: полнота найденных позиций (80% оценки) и точность их параметров (20%); сейчас учитываются вентиляторы, клапаны и AHU. Для каждого набора задан свой порог — от 90 до 97%. В прогоне 28.09.2026 все шесть наборов прошли его с оценками от 92,7 до 100%. Если порог не пройден, стандартный релиз останавливается. Прошедший проверку релиз выходит в эксплуатацию, а заметки о нём появляются в разделе «История обновлений». Действующие правила подбора описаны в разделе «Справочник».

В XLSX сохраняются позиции, модели, количества и автоматические примечания. Цвета статусов переходят в выходной файл: у строки с предупреждением выделена ячейка модели, а причина записана в примечании. Отдел продаж и инженеры работают дальше с готовой таблицей и не набирают данные из PDF заново.

По опубликованному кейсу YYTECH пропускная способность отдела ПТО выросла в 10 раз, а время обработки одного проекта сократилось на 90%. Методика и выборка в источнике не раскрыты. Разбор документа и сборку таблицы выполняет система, а спорные позиции по-прежнему проверяет инженер. Замечания из повседневной работы остаются связанными с конкретными позициями и доступны команде развития продукта.