Comments 61
Кроме того, был создан протокол проверки ошибок с дополнительными скриптами для проверки, который сводит их количество к нулю, достигая идеального результата переноса данных, который не был достижим при ручной обработке. Заказчик был доволен.
Великолепно :)
А метрики вы снимали? Как анализировалось качество, и в течение какого времени? Остался ли нужен человек в этом процессе, или все полностью автоматизировано?
Статья идеальный пример наверное всех практик применения ЛЛМ, которые я считаю крайне порочными и даже местами опасными.
Грубо говоря «мы непонятно как сделали что-то (шайтан-машина!), что работает непонятно как, непонятно как расширяется, и с непонятно каким результатом, но главное — мы довольны».
Как будто требуемый результат — это исключительно довольство заказчика, а не что нибудь типо надежно (желательно — плюс-минус измеримо) работающей системы, которую можно просто (дешево) обслуживать и расширять.
Я не хочу писать шайтан-машины (мне бы, наверное, даже было бы стыдно назвать результат своей работы таким образом), и тем более их поддерживать, но может я просто луддит-извращенец, конечно.
Человек нужен в этом процессе, просто всё происходит теперь значительно быстрее. Нужен всего лишь один человек (вместо двух), и делается за минуты времени этого человека вместо часов.
Измерялся процент ошибок и возможность их автоматизированного определения и исправления.
А можете, пожалуйста, поделиться метриками? Какой там процент ошибок при каком количестве обработанных документов?
Честно, без цифр это все выглядит не очень убедительно и сухо.
В большинстве документов ошибок нет вообще. В среднем заполняется правильно около 99 % ячеек. Это при первом запуске, без проверок и повторных запусков.
А цифры, цифры у вас есть? Что такое «большинство документов»? Это сильно, прям сильно широкая категория, от 50% + 1, до 100% - 1 от всей выборки.
Большинство тут - больше половины. С каждого нужно 78 ячеек.
Человек также нужен в процессе исправления, который происходит быстро.
Ключевая метрика была - процент правильно заполненных ячеек.
То есть, теперь один человек вместо двух исправляет меньше половины ошибочно заполненных ячеек, а для того, чтобы оценить, правильно ли заполнены все ячейки, ему все равно нужно проверить их все (а потом еще и исправить)?
А точно общая производительность такой системы стала выше? Вы измеряли количество обработанных за день документов, оно выросло?
Т.е. смотрите.
Измеряли метрику - процент ячеек с ошибками. Там около 1 процента.
При этом строк полностью правильных больше половины, но точно не измеряли. В каждой строке 78 ячеек.
Ошибок при извлечении данных промптом не было, если использовать Gemini. Все ошибки были связаны с несовершенством правил кода.
Следующий этап — разработка системы управления АЭС. Её разработает один человек за месяц вместо 500 за три года. Круто же, какая экономия. После тестирования сразу в прод?
На АЭС много дублирующих протоколов безопасности, при этом часть из них не слишком надежные. Главное там, чтобы их много было и как минимум некоторые очень надежные.
Зато какой годный человеческий промпт был на Фак-ю-шиме, взяли и построили главный кабельный узел в доступном подземелье и пожлобились вынести аварийные дизель-генераторы от причальной стенки на холмик. Это ж Япония, тут землетрясений и цунами не бывает, а те, что и бывают, строго по распоряжению самого императора! (сарказм выкл).
Выдающаяся глупость может испортить всё, да.
По японцам с Фукушимой Асмолов основательно оттоптался. Култура там у них, пилят, такая.
Чел (автор) про себя пишет Data Scientist :)
там "я не понимаю" совсем не тоже самое, что "я не понимаю" от домохозяйки :)
(хотя я не понимаю, с таким профилем у автора, можно было попросить нейронку "причесать" код, чтобы он был понятнее, но видимо надо было "быстро и вчера")
Там проблема в очень запутанных и многочисленных правилах определения, какие данные считывать из таблиц и в какие ячейки вставлять. Ведь при распознавании, хотя и удалось добиться безошибочного извлечения всех данных без пропусков, полученные таблицы могут выглядеть сильно по-разному.
Так то функции обработки разных ячеек были разделены, но это не сильно помогает понять полностью, почему это должно так работать.
Как будто требуемый результат — это исключительно довольство заказчика
Да, именно так. А заказчику нужно максимально быстро и дёшево решить свою конкретную проблему, а не масштабировать, расширять или делать тому подобное.
А заказчику нужно максимально быстро и дёшево решить свою конкретную проблему
Быстро и дёшево в 95% случаев означает ещё и низкокачественно (хотя, честно говоря, быстро и дёшево нужно всем, я не встречал заказчика, кому было нужно медленно и дорого :) ). И как раз в таких задачах, где качество не особо важно, LLM действительно хороши -> написал одноразовый скрипт -> запустил -> перепроверил -> выкинул и забыл.
Но таких задач в айти, где качество не особо важно, довольно мало, и особых секретов в плане применения LLM для их решения, нет.
а не масштабировать, расширять или делать тому подобное.
ну_это_пока.jpg
Всяких задач по перекладыванию бумажек и заполнению документов, переписыванию чисел из таблицы в таблицу - полным полно.
И LLM в них позволяют и снизить количество требуемого человеческого труда, и даже повысить качество обработки.
Да много таких задач, где текст и цифры один человек перебивает из файла в программу, или из одной программы в другую.
Просто тратить время дорогих программистов, чтобы автоматизировать работу одного человека - это очень не рационально. Вообще конечно правильнее было бы перестроить архитектору и избавиться в целом от необходимости что-то куда-то копировать в принципе, но вот такие накопленные пласты данных ведь всё равно надо обработать и внести а общую систему.
Вообще в автоматизации рутины очень много таких задач, которые решить программой довольно сложно, так как нет четко поставленных условий и ясного алгоритма.
Задачи попроще такого рода часто решаются просто прямыми вопросами к LLM, что облегчает людям жизнь. Иногда для этого полезно написать промпт.
А тут пример задачи. где может помочь целая шайтан-машина.
Я думаю, что нужно разработать какой-то подход, например эволюционное программирование + LLM (на эту тему как раз статьи из тех, на какие ссылки в конце текста оставил), который позволит решать подобные задачи.
Вы противоречите себе: пишите, что задачу сложно решить программой, и при этом предлагаете решать её программой.
А как еще решать?
В том то и дело, что сложно придумать алгоритм, но решать как-то надо. LLM может написать такой вот "шайтан-код", на принципе обратной связи, который как-то задачу решает.
Я бы предложил просто не решать и всё. Всё равно ценность вашего решения нулевая (если не отрицательная) ибо код получился предельно некрасивый и некорректный (работает с ошибками).
Ценность решения измеряется не красотой кода и безошибочностью, а количеством экономии человеко-часов специалистов в год.
Это не ценность, это польза. Польза от вашего решения есть, но это важно только для заказчика, всем остальным включая вас должно быть на неё плевать.
А вот ценность которую код несёт в этот мир — это совсем другое дело. Ценность напрямую связана с его красотой, с корректностью, с приближением к идеалу.
Мы как ответственные разработчики должны стремиться писать код, имеющий ценность. А работает он или нет, решает какую-либо задачу или нет — это глубоко побочные вопросы.
Если рассматривать решение как программу, то выглядит плохо, но если рассматривать как обучение модели - просто мы пишем не в веса, а в промпт и питоний скрипт -, то это типичный ML
Честно говоря, на сложном, но полустраничном тестовом промпте, модели ошибаются, теряют контекст и задание... Ваш вариант на текущий момент кажется нереальным.
Это какие модели? У Gemini такой проблемы нет.
Но вообще, видимо, LLM нужен как раз такой запутанный промпт для правильного извлечения данных именно потому, что он инструкции не идеально выполнять может.
Там же куча уточняющих правил, получается даже если часть инструкций не выполнилась, за счет избыточности всё работает.
Это интересный вопрос, за счет чего именно удалось сделать так, чтобы LLM перестал забывать те или иные данные с pdf документа.
Но в процессе удлинения промпта самой нейронкой становилось всё лучше, до тех пока не возникла ситуация, в которой все таблицы извлекались без потерь.
Если дать ему промпт короткий, он обязательно что-нибудь не перенесет.
А вот DeepSeek, к примеру, даже с этим промптом извлекал с ошибками, например букву О и цифру 0 путал друг с другом или даже с буквой D. У Gemini таких проблем не было.
заклинатели, работа которых заключалась в том, чтобы придумывать максимально точные инструкции для джиннов, исключающие возможности неправильного исполнения.
Но и тут есть нюанс....
LLM сильнее всего там, где для человека слишком много взаимосвязей.
Соглашусь и подтверждаю практическую применимость данного тезиса.
У меня задача сильно проще - есть очень много таблиц и временных рядов , задача найти корреляции и взаимосвязи между данными . Нейросеть , даже в самом простом бесплатном варианте - отлично справляется , дает практически применимый результат и экономит очень много времени на анализ данных.
LLM нормальный и полезный инструмент , если использовать для задач для которых LLM предназначены.
P.S. Например , для прогнозирования нейросети очень плохо приспособлены.
Еще LLM может быстро написать код для расчета всяких корреляций и поиска сложных взаимосвязей. Но на самом деле лучше иметь готовый блокнот, где уже это всё нормально написано. Еще есть визуализаторы разные.
А как это работает? Вы даете какой-то ЛЛМ-ки доступ (куда-то? в папку?) где лежат эти самые данные? (и промт, найди мне инсайты, взаимосвязи, спроси меня о том, что не знаешь)
Мне все хочется "дать этой шайтан-машине" все что можно, пусть найдет инсайты :)
но пока слабо понимаю как это собственно сделать
Нет. Просто промпты пишу. Там 78 ячеек надо заполнить, а я за раз прошу от 1 до 4-5 дописать алгоритм заполнения и меняю строго этот участок кода.
Сначала сгружаю всю доступную информацию про эти ячейки и примеры таблиц, и что надо было заполнить и куда с них. Ллм присылает функцию. Затем тестирую, вижу в части случаев заполняет не то. Присылаю ему скрины из ворд файла и прошу переделать функцию, но так, чтобы больше ничего не сломалось (прикрепляю также примеры правильной работы). Он тогда дописывает дополнительных правил в функцию.
И так до тех пор, пока эти от 1 до 4-5 ячеек не станут правильно работать на всех моих примерах. Затем следующие. Так все 78 ячеек правильно заполняет.
А потом ещё от заказчика приходят ещё примеры, на которых не работает что-то. Снова дорабатываем. Если на каких-то прошлых примерах работать перестало как надо - тоже сообщаю в LLM, он переделывает код функции.
А как это работает?
Схема очень простая:
1) Инструмент готовит текстовый файл содержащий результаты статистического анализа (корреляции, регрессии , максимальные минимальные значения и т.п. ) и временные ряды метрик производительности СУБД и инфраструктуры
2) текстовые файлы загружаются в нейросеть, главное не превысить ограничение бесплатной версии (128K токенов). Если данных много , придётся анализировать производительность СУБД и инфраструктуры - отдельно.
3) Дальше есть варианты - либо использовать промпты из библиотеки использованных промптов , либо еще проще использовать базовый промпт - "используя входные данные , подготовь промпты для сводного анализа производительности СУБД и инфраструктуры по результатам эксперимента ".
4) Дальше используя уже загруженные данные и промты - дело техники - готовим сводный отчет.
Доступ нейросети никуда давать не нужно, главное - подготовить достаточный набор данных для анализа.
Примеры обработки нейросетью результатов нагрузочного тестирования и инцидентов производительности СУБД, если интересно - на дзен канале(ссылка в профиле) .
Ну а если сильно интересно - пишите в личку. Отвечать на комментарии хоть как-то оперативно - нет возможности, согласно политике Хабра.
Спасибо, стало чуть понятней
Я пробовал решать схожую задачу (разобраться, а чего у меня сервер падает (точнее проц выжирается из-за MariaDB при небольшом DDOS), но нейронкам для советов не хватает (очень не хватает) контекста
А мне надо выгрузить данные именно в период нагрузки. А логи сами по себе здоровенные
То есть идея, кинуть нейронки все конфиги (пхп, mysql, апач, нжинс), логи за период и пусть она думает :)
Но пока проблемы (я плепсити использовал) она начитается стековерфлоу, а у меня панель ISP и многое иначе реализуется - по итогу советы по оптимизации работают 50х50 :)
Как заработать на LLM, перестав писать «правильные промпты»
так а в чем заключается заработок? И длинные запутанные промпты - не обязательно неправильные
. Представьте себе, что вам поступает много технических паспортов оборудования, которые не оформлены по единым правилам.
Может упростить задачу и заставить тех, кто делает паспорта загонять их в формат?
Ваши примеры уже кто-то загонял в стандарт, но не закончил...
Не получится, единых стандартов нет, а заказчики все очень разные.
При извлечении таблиц куча сложностей: нужное число может быть под нужным описанием, справа или даже в той же клетке. А в таблице посреди всего этого может стоять логотип, график или рисунок, что тоже затрудняет.
Промпт по извлечению таблиц добился того. чтобы разные данные, написанной в одной и той же клетке таблицы pdf (то есть число и его описание, как правило), попадали все-таки в разные клетки таблицы.
Далее сложности: как правильно во всех случаях считывать именно нужное число, ведь там могут быть другие числа рядом, а еще может перенести в соседнюю таблицу. И для этого как раз LLM придумывает огромную кучу эмпирических правил, опираясь на обратную связь и примеры того, как его правила работают в конкретных случаях.
В этих правилах также используются известные данные о том, в каком диапазоне могут быть числа, какие бывают марки того или иного оборудования и т.п., это всё скармливалось в LLM.
Или, например, оказалось, что во всех образцах паспортов данные не разрываются на странице, то есть если есть данные для чего-то (например, вентилятора), то они все на одной странице находятся, исключений из этого не было. Это позволило использовать информацию о том, с какой страницы извлечена таблица, в этих правилах.
Я про себя. Я всегда пытаюсь изучить надсистему.
Из текста не понял зачем вам нужны данные. Как они используются.
Для продажников 78 параметров - излишни. На складе - тоже не понятно. Для производства - в вентиляции нюансов намного больше и приписка словами "загнуть по месту" приносит больше проблем, чем остальные данные.
По опыту - вреде все прописал как надо, а потом манагер привез то, что смогли сделать. Случаев немного, но бывают. В общем работа творческая.
Они нужны для начального этапа подбора оборудования.
Больших подробностей я не знаю, так как я не работаю в этой фирме, меня просто наняли, чтобы я помог автоматизировать ручной труд. И все параметры задачи мне объяснили в объеме, достаточном для выполнения задания, а не больше.
Мне за эту шайтан-машину заплатили 100к рублей, а у них за полгода человеко-часы, требуемые для обработки подобных паспортов, ощутимо дороже обходятся. Благодаря Gemini я ее довольно быстро сделал, так что это и мне было весьма выгодно.
А сейчас наняли делать еще один комплекс программ автоматизации их рутины, но там нужны нормальные скрипты, а не шайтан машина: у них просто множество вычислений и обработки данных с датчиков делается в эксель-файлах вручную, нужно сделать несколько скриптов, которые весь этот ручной труд автоматизируют.
Я могу делать и то, и другое, если будет что-то такое нужно - можете обращаться.
На pdf один из возможных вариантов, как они делают эти паспорта. Таблицы могут быть по-другому устроены и иначе расположены. Но, конечно, сильно помогает, что надписи одни и те же используются, технические термины, обозначения.
Разрешите поинтересоваться:
Модель была онлайновая или оффлайновая?
Какая именно?
Если оффлайновая, то какого размера?
Сколько суммарно времени вы потратили на изготовление конечного продукта?
Если понадобится внести изменения - по вашим оценкам, сколько времени это может занять? Например, если надо будет учесть какие-то новые параметры или проигнорировать старые?
Какие дополнительные телодвижения потребовалось сделать заказчику? Например: установить такую-то библиотеку, такую-то версию какого-нибудь языка, установить новую версию ОС, купить новый компьютер (ТТХ?), вложиться в инфраструктуру, обучить людей использовать ваше творение, оплатить абонемент(ы) и тому подобное.
Нужен выход в интернет с ВПН, чтобы запускать Gemini для первичного распознавания с промптом.
Скрипты собираются в готовое приложение, инструкция была
Есть инструкция, один человек всему научился, который со мной взаимодействовал. Можно легко быстро научить другого, но вроде как у них больше нет в этом потребности (достаточно одного). Все дополнительные вложения - затраты времени этого человека ( он собирал файлы, оформлял договоры, объяснял что и как нужно заполнять, контролировал качество работы) . Никаких подписок и дополнительных устройств не нужно.
Могу больше подробностей в личку. Напишите личное сообщение.
Хороший пример правильного приложения нейросети. Действительно сила в оперировании множеством параметров, а не в точном выполнении написанных инструкций (промтов)
Джинны очень опасны своим буквальным исполнением и разрушительным потенциалом, который можно обуздать, только создавая для них максимально точные инструкции и требования.
Прелесть в том что пока джинны сидят в бутылках - т.е. им не выдали ни рук ни ног. А ведь к тому все идет - роботизация следующий этап. Вот там будет веселуха. Там действительно цена неверного заклинания будет страшной.
Святые отцы давно об этом предупреждали.
Собрался заминусовать - открой SICP.
Ну наконец-то LLMы приняли Ислам и указано шайтанское происхождение процесса. Тема джинов раскрыта полностью.
Спасибо)
Сам работаю и с LLM, и с техпаспортами, и с конструкторской документацией, которая точно так, как у вас выглядит. На ваши шайтан-промты могу одним словом ответить: аузубиЛлях! Ну а если серьезно, есть что раскритиковать. Надеюсь в споре родится истина)
То, что вы называете мышлением, я таковым назвать никак не могу. Потому что мне, переводчику, приходится выбивать это хвалёное "мышление" нейросети калёным железом. Но это лирика - тут у нас будет очень большая разница определений.
LLM для вашей задачи - компьютер, которым забивают гвозди. Здесь, по хорошему, нужен некий OCR, способный восстановить структуру табличного формата, после чего задача уходит в табличный процессор, способные считать данные из ячеек непосредственно. Такой OCR может на данный момент не существовать, допускаю, но сам факт - LLM применяется, что называется, off label. Вы же знаете, какие 78 ячеек необходимо заполнить. Так зачем тут LLM? Мне представляется, что из этих 1% ошибок (уверен, что их больше), о которых вы говорите, львиная доля порождается фундаментальной рандомностью нейросети и влиянием контекста на вывод. Это "шум", с которым надо бороться.
Если техпаспорта - это результат работы другого отдела внутри одной компании, или если их отправляет изготовитель, тесно связаный с компанией серьезными деньгами, то эта задача решается организационно: мы формулируем банальное требование к документации - никаких сканов распечаток, никакого текста как изображение, передавайте документы в их исходном векторном виде. Я уверен, что все эти документы аккуратно лежат в папочке у метролога именно в таком формате, а ваша LLM (и два с половиной сотрудника до этого) просто делает чужую и никому не нужную работу. Получив нужные документы, вы сможете автоматизировать задачу, отказавшись от LLM, либо применяя её только там, где классические методы работы с данными не сработают.
Всякую нечитаемую инструкцию можно выразить как читаемую. Я не вижу причин, по которым "шайтан-промты" могут быть лучше понятных инструкций на естественном языке, кроме тонкой подстройки промта под особенности весов конкретной версии LLM. Но такая подстройка неизбежно приведёт к поломке вашей автоматизации в момент любого существенного изменения самой нейросети. В лучшем случае, ваша нейросеть локальная, тогда вы просто отказываетесь от модернизации. В худшем, у вас облако, и значит ваша автоматизация может сломаться в любой момент, когда поставщик услуг зафайнтюнит модель, а вам не скажет, или вообще выведет её из эксплуатации. И то, и другое нередко случается. В любом случае, такой подход не выдержит проверки временем. Я ещё мог бы понять, если бы у вас была некая Source-инструкция, которая "компилировалась" бы самой нейросетью под саму себя. Но вы об этом не говорите, из чего делаю вывод - этого нет. А тому же, она все равно потребует тщательной доводки и отладки. Это все равно, что намеренное написание нечитаемого кода - хороший способ сделать себя незаменимым, но плохой способ выполнения поставленной задачи.
Фундаментально, категорически не согласен с тем, что противоречивые инструкции для нейросети - это нормально! Вы сами говорите, что у LLM проблемы с структурированием и построением иерархий, но тут же на чистом глазу заставляете нейросеть построить сложную, внутренне-противоречивую иерархию из ваших инструкций, а затем применить эту запутанную конструкцию к данным. Где логика? Если вы когда-либо работали с маленькими open-weight LLM, то вы должны понимать, как именно нейросеть поступает в таких случаях. Вы просто полагаетесь на то, что произвольный вывод LLM окажется верным. Скажете, ну произвольный ответ, и ладно - у меня нейронка большая и умная, выдаст наиболее правдоподобное значение и угадает? А проблема в том, что правдоподобное значение совсем не обязательно правильное, причем правдоподобную ошибку человек с большой вероятностью не заметит. Человеку свойственно ошибаться, и зачастую именно исключение человеческого фактора - основная причина автоматизации, а повышение производительности труда - это просто приятный бонус. Но в вашем случае эта цель не достигается, потому что вы нейросетью автоматизировали сам человеческий фактор, да ещё и провоцируете ошибки в нейросети малопонятными и противоречивыми инструкциями.
"Мне представляется, что из этих 1% ошибок (уверен, что их больше), о которых вы говорите, львиная доля порождается фундаментальной рандомностью нейросети и влиянием контекста на вывод. "
Как ни странно, вообще 0. То есть не было ни разу ошибок извлечения табличных данных из pdf. Все ошибки порождены неидеальностью скрипта.
Вы написали длинное сообщение об ошибках, которые у меня не появляются вообще. Промпт идеально работает. Я думаю, причина в многократной избыточности инструкций этого промпта.
Главная проблема не в распознавании. Она в другом - так как таблицы разные все, сделаны по разным форматам, а еще при извлечении данных таблица может превратиться в две, или наоборот, две в одну, то непонятно, как сделать единое правило, которое позволяет определить, как именно заполнить ту или иную ячейку.
Человеку это понятно по пониманию контекста, а машина его не понимает.
Если бы документы были все +- одинаковые, то правила были бы достаточно простые и ошибок бы вообще не возникало.
И последнее, насчет OCR. На данный момент любые OCR работают гораздо хуже, чем Gemini 3.0, в задаче распознавания изображений, и чем другие современные LLM.
Это касается даже очень узкоспециализированных задач. Например, есть Mathpix, специализированный инструмент для обработки текста (превращает текст и формулы с изображений в LaTeX и ворд). Если сравнить качество его работы с Gemini 3.0, оно намного хуже. В случаях написания текста плохим почерком, или сканов старых книг, Mathpix допускает очень много ошибок, а Gemini 3.0 работает практически идеально.
Вот где полезны LLM:
изучи эти документы, и расскажи, что здесь изображено, для чего оно и с какими основными характеристиками?
На основании предоставленных документов, это техническая документация (паспорт) на приточную вентиляционную установку (кондиционер) модели YMA(R)1370H-1350W.
Вот подробное описание:
Что это такое?
Это центральная приточная установка (Supply Fan Unit). Она предназначена для забора наружного воздуха, его очистки, подогрева и подачи в вентилируемые помещения. Установка является частью системы общеобменной или комфортной вентиляции здания.
Для чего она предназначена?
Основные функции:
· Забор и подача воздуха: Обеспечение заданного объема свежего наружного воздуха.
· Фильтрация: Многоступенчатая очистка воздуха от пыли и загрязнений (фильтры классов G4 и F7).
· Подогрев: Нагрев приточного воздуха до требуемой температуры с помощью водяного калорифера для предотвращения подачи холодного воздуха в помещение.
· Преодоление сопротивления сети: Создание достаточного давления для подачи воздуха через воздуховоды, фильтры и другие элементы системы.
Основные характеристики и компоненты
Общие параметры установки:
· Модель: YMA(R)1370H-1350W
· Производительность (поток воздуха): 3.47 м³/с или 12,500 м³/ч.
· Полное внешнее статическое давление (вентилятора): 500 Па (номинальная рабочая точка).
· Максимальное статическое давление (вентилятора): 865 Па.
· Суммарное статическое давление (установки): 1223 Па.
· Скорость вращения вентилятора: ~2807 об/мин.
· Габаритные размеры: Существует две модификации:
· -000: L=2750 мм, W=1350 мм, H=1520 мм (вес 576 кг)
· -001: L=1650 мм, W=1350 мм, H=1520 мм (вес 398 кг)
Ключевые компоненты (по разделам документации):
· Вентиляторный сектор (Supply Fan):
· Тип вентилятора: ECF (видимо, центробежный).
· Двигатели: 2 электродвигателя с электронно-коммутируемой (EC) технологией.
· Мощность двигателей: 2 x 3.90 кВт (номинальная), 2 x 3.28 кВт (потребляемая при рабочих условиях).
· Уровень звуковой мощности: Приведены октавные спектры для входа (IN) и выхода (OUT) ~92 дБ.
· Фильтровальный сектор:
· Фильтр грубой очистки (Stage 1): Класс G4, тип мешочный (BAG), 4 полноразмерных фильтра.
· Фильтр тонкой очистки (Stage 2): Класс F7, тип мешочный (BAG), 4 полноразмерных фильтра.
· Сопротивление фильтров: Указано начальное и конечное для расчета потерь давления.
· Сектор нагрева (BATTERIA DI RISCALDAMENTO):
· Тип: Водяной калорифер (теплообменник медно-алюмиминиевый).
· Расход воздуха через него: 3.47 м³/с.
· Температурные параметры:
· Воздух на входе: -30°C / на выходе: +18°C.
· Вода на входе: +90°C / на выходе: +70°C.
· Расход воды: 2.40 л/с.
· Аэродинамическое сопротивление: 56 Па.
· Воздушная заслонка (DAMPER):
· Размеры: 1260 x 1240 мм.
· Предназначена для регулирования или перекрытия потока наружного воздуха.
· Двери для обслуживания:
· В разных секциях предусмотрены сервисные двери размером 1250x782 мм, 1260x556 мм и др.
· Расчет энергетического класса (ENERGY CLASS CALCULATION):
· Документ содержит подробный расчет потерь давления, эффективности и удельного энергопотребления в соответствии с европейским регламентом (EU) 1253/2014.
· Удельное энергопотребление вентилятора (SFP) при номинальных условиях составляет 1.93 Вт/(м³/ч).
· Установка классифицируется по скорости воздуха в фильтрующем сечении и другим параметрам.
Вывод:
Данный комплект документов представляет собой полный технический паспорт на мощную приточную вентиляционную установку с водяным подогревом. Она рассчитана на работу в условиях холодного климата (нагрев с -30°C) и обладает высокой производительностью, что характерно для систем вентиляции крупных коммерческих, промышленных или общественных зданий. В документации уделено особое внимание энергоэффективности и соответствию европейским стандартам.
Как заработать на LLM, перестав писать «правильные промпты»