Мы пилим сук, на котором сидим

Не могу не поделиться. А наш материал тоже скоро выйдет.

Сделал хороший волчий мем, но не придумал куда его всунуть. Пускай будет здесь просто так. Не забудьте отдохнуть на выходных!

Недавно мы худо бедно победили DWG, но это слишком сложно чтобы этим гордиться. По сути это просто макет, хотя и рабочий, там все еще очень сложно. А если сложности непреодолимы то что надо сделать? Конечно же сдаться! 🐺 Так что я сдался и сделал то что проще - RVT и IFC. Почему проще? Да потому что BIM/ЦИМ это буквально чистые данные + 3Д графика. В ЦИМ стена буквально знает что она стена, как в известном видео. Все наши задачи по работе с бим-дата как будто решает Спекл, зачем что то городить поверх? Но Спекл начал закручивать гайки и из селфхост решений много чего пропало. То есть мы ловим зависимость от чужих умирающих решений. А мы начали нашу РАГ машину в текущем виде с того, что вырезали все тяжелые зависимости - RAGFlow, Docker и тд. Основные вопросы которые возникли - какой формат брать и в чем работать. С форматом решили дальше мучить JSON, а как движок взяли OBC. Так же сделали простые экспортеры из Revit, Navis, CAD. Пока очень нестабильные, но работают (у меня). Сама технология подробно описана.👁 А потрогать можно тут. 🚀 Исходный код 🧩 И не забудьте отдохнуть на выходных!

Недавно мы худо бедно победили DWG, но это слишком сложно чтобы этим гордиться. По сути это просто макет, хотя и рабочий, там все еще очень сложно. А если сложности непреодолимы то что надо сделать? Конечно же сдаться! 🐺 Так что я сдался и сделал то что проще - RVT и IFC. Почему проще? Да потому что BIM/ЦИМ это буквально чистые данные + 3Д графика. В ЦИМ стена буквально знает что она стена, как в известном видео. Все наши задачи по работе с бим-дата как будто решает Спекл, зачем что то городить поверх? Но Спекл начал закручивать гайки и из селфхост решений много чего пропало. То есть мы ловим зависимость от чужих умирающих решений. А мы начали нашу РАГ машину в текущем виде с того, что вырезали все тяжелые зависимости - RAGFlow, Docker и тд. Основные вопросы которые возникли - какой формат брать и в чем работать. С форматом решили дальше мучить JSON, а как движок взяли OBC. Так же сделали простые экспортеры из Revit, Navis, CAD. Пока очень нестабильные, но работают (у меня). Сама технология подробно описана.👁 А потрогать можно тут. 🚀

Недавно мы худо бедно победили DWG, но это слишком сложно чтобы этим гордиться. По сути это просто макет, хотя и рабочий, там все еще очень сложно. А если сложности непреодолимы то что надо сделать? Конечно же сдаться! 🐺 Так что я сдался и сделал то что проще - RVT и IFC. Почему проще? Да потому что BIM/ЦИМ это буквально чистые данные + 3Д графика. В ЦИМ стена буквально знает что она стена, как в известном видео. Все наши задачи по работе с бим-дата как будто решает Спекл, зачем что то городить поверх? Но Спекл начал закручивать гайки и из селфхост решений много чего пропало. То есть мы ловим зависимость от чужих умирающих решений. А мы начали нашу РАГ машину в текущем виде с того, что вырезали все тяжелые зависимости - RAGFlow, Docker и тд. Основные вопросы которые возникли - какой формат брать и в чем работать. С форматом решили дальше мучить JSON, а как движок взяли OBC. Так же сделали простые экспортеры из Revit, Navis, CAD. Пока очень нестабильные, но работают (у меня). Сама технология подробно описана.👁 А потрогать можно тут. 🚀

А можно ли тащить в RAG такой древний и страшный формат как DWG? С одной стороны там просто геометрия, с другой стороны данных там немало. А можно ли сделать так, чтобы инженерный чертеж стал не просто картинкой, а нормальными данными для ИИ? Не “распознать скриншот”, не “посмотреть глазами”, а вытащить из DWG линии, дуги, подписи, слои, координаты и превратить это в JSON. Зачем? Потому что RAG по обычному DWG почти беспомощен. Модель не может надежно ответить, что именно лежит в узле, какие там подписи, где труба, где ороситель, где размер, а где просто графика. Для нее это темный лес. А вот JSON — уже другое дело. Так появился cad_bim_graph.json. Идея простая: берем DWG, прогоняем через экспортер, и каждый объект чертежа становится записью в JSON. Линия - это LINE с координатами начала и конца. Дуга - ARC с центром и радиусом. Текст -TEXT с точкой вставки и содержимым. Плюс слой, тип, handle, цвет, связи с моделью и прочая инженерная мелочь, из которой внезапно складывается нормальный граф. А потом самое веселое: этот JSON можно нарисовать обратно. То есть мы не просто выгрузили “какие-то данные”. Мы можем открыть их в смотрелке, собрать геометрию обратно и увидеть тот же узел. Если после перевода DWG /JSON/ viewer чертеж снова похож на чертеж, значит данные не умерли по дороге. Это очень важная проверка, потому что RAG должен ссылаться не на фантазии модели, а на конкретные элементы источника. На тесте был DWG с узлами установки оросителей розеткой вниз. Из него получилось:

2534 элемента 2457 отображаемых объектов 2534 связи линии, дуги, тексты, полилинии, штриховки слои типа AR-Graphic, _TEMA-YD-FP-PIPE, Линии, Аннотация, Узлы

И это уже можно смотреть как данные, а не как “файл где-то в папке”. Что это дает RAG: Можно искать не только по тексту, но и по объектам чертежа. Можно отвечать с привязкой к конкретному элементу, слою и handle. Можно подсветить источник ответа в вивере. Можно отличать подписи, геометрию, размеры и инженерные слои. Можно грузить CAD/BIM в базу знаний без Спекла, IFC и прочих промежуточных танцев. Можно проверять, не сломался ли экспорт: если JSON рисуется обратно, значит геометрия живая. Самое забавное, что это пока еще костыльный путь. DWG сейчас вытаскивается через временный DXF/AutoCAD extractor, смотрелка только учится нормально показывать такие данные, а линии пришлось утолщать, потому что на общем виде они превращались в пыль. Но направление уже понятное: AutoCAD/Revit сами должны писать cad_bim_graph.json напрямую. А LES потом будет не просто “читать документы”, а отвечать по реальным инженерным объектам: чертежам, узлам, слоям, оборудованию и связям. И вот это уже похоже не на чат-бота по PDF, а на инженерную память проекта.

Наша «редакция» готовит большой пост про ИИ агентов, без магии и маркетинга. Только практика, какие бывают и как используют. И мы ищем практиков, тем кто готов поделиться опытом, рассказать, какими решениям вы пользуйтесь, как, зачем, что вам это дает. Пишите!

А вы любите видеоигры так, как люблю их я? В хороших играх хорошие геймдизайнеры стараются сделать такое управление, что бы игрок мог получать свой фан не думая про то где там какая кнопка на клавитуре/геймпаде. А самые лучшие дизайнеры не просто делают отзывчивое управление, а еще делают его помогающим, что бы игрок мог буквально плыть внутри игры, так сказать флоу. Есть такой Сигэру Миямото, гений видеоигр, да и не только. Вы его можете знать как того чела, который придумал Марио и Зельду. А еще он разработал одну из самых лучших и самых инновационных игр (на тот момент) The Legend of Zelda: Ocarina of Time. В ней чуть ли не в впервые появилось контекстное управление, когда одна кнопка делает примерно все, в зависимости от того что перед героем. Подробно про все это можно прочитать в огромной классной статье. А причем тут ИИ, БИМы и тд? А все к тому, что я не так давно баловался с онлайн чертилками. Я человек увлеченный и понял, что у меня начала выходить пародия на Ренгу, что явно лишнее. И тут я подумал - а давайте попробуем сделать флоу моделирование. Получилось или нет - мне сказать сложно, но стало удобнее. А еще, там есть ужасно кривой функционал создания листов и схем (вообще не похоже на ГОСТ) и экспорт в JSON, о котором будет разговор отдельно.

На случай если кто пользуется и не видел.

RAG — это не продукт, это процесс. Многие думают, что заставить ИИ отвечать строго по вашим документам легко: достаточно нарезать файлы на части, перевести в векторы и отдать языковой модели. Ну или вообще загрузить PDF на 100 мегабайт и сказать: «Генерируй!». В реальности все сильно, очень-очень-очень сильно сложнее. Качество работы RAG зависит не от веса LLM. Метод «против лома нет приема» (попытка решить проблему простым увеличением размера модели) здесь работает плохо. В работе с языком - будь то классический поисковик или современная LLM - одинаково важны и математика, и лингвистика. Попытка решить всё исключительно многомерными векторами без учета морфологии, корней слов и падежей быстро превращает поиск в хаос. Успех рождается только на стыке двух миров: когда математическая точность расстояний объединяется с лингвистической логикой языка. Именно эта гибридность спасает систему от глухоты. Мы разобрали четыре главные архитектурные ловушки на примере нашей системы Л.Е.С. v2.0: Удушение контекста (Context Starvation). Почему на пути к модели незаметно теряется до 83% найденных документов и как динамическое масштабирование возвращает системе ширину зрения. Ловушка чанковедения. Почему слепая нарезка текста рвет смысл предложений, как эвристики и связанные графы чанков заменяют нейросети, и как оцифровывать таблицы на GPU через MLX GLM-OCR. Валидатор-параноик. Почему дословное сравнение ответов ИИ всегда возвращает пустоту и как лексическое перекрытие (Lexical Overlap) с жестким контролем чисел решает проблему галлюцинаций. Раздвоение индекса. Коварный аппаратный баг сопроцессора Apple Silicon AMX, из-за которого векторная база полностью слепнет, пока текстовый поиск рапортует об успехе. Полный разбор с интерактивными схемами, формулами и кодом.

Все уже знают что Антропики выпустили супер модель Клод 4.8, который умеет все и пишет Майнкрафт за 7 минут? Вот и мне стало интересно что за чудо, тем более подписка на Клод Про у меня есть. Майнкрафт мне не нужен, но мне подкинули идею - а давай Ревит напишем! Идея огонь и безумная даже в эпоху мощных ИИ агентов. Но у меня есть старый больной технический скажем так долг - супер веб бим движок OBC, он же That Open Engine, он же гроза всех ИИ, с которыми я пытался его завести. Я решил испытать Клода максимально - не просто завести смотрелку IFC, по мне так лучше чем Спекле нет ничего, а сделать простую штуку для моделирования. Идея — пришел на стройку, накидал на планшете/ноутбуке, потом в теплом офисе сделал правильно. Так появилась "Замоделька"! Внезапно - через несколько итераций оно заработало. Вышла прикольная штука, в которой можно быстро, но очень криво нарисовать помещения, воздуховоды, расставить светильники и розетки, а так ж получить условную спецификацию. Зачем? Ну надо же понять что Клод умеет! Причем Клод, страшно ругаясь, написал только базовый код, наступил на все грабли и написал skill для всех, пойдет за ним. А фичи уже делал вполне приземленный Гемини, без малейших проблем. И даже залил на VPS, откуда можно это потрогать! И даже исходый код! Особенности и функции: 1. Рисовать стены, двери окна 2. Рисовать оконечку с привязкой к стенам (по грани) 3. Расставлять оконечку по потолку, привязка идет к уровням, которые можно задавать 4. Размещенные элементы можно удалять delete 5. Размещенные элементы можно двигать стрелками на клавитуре 6. Работает умная привязка. 7. Есть заделка под системы 8. Все элементы считаются и выгружаются. 9. Рисовать лотки, трубы, воздуховоды, пока очень неудобно и криво. 10. Ужасающее количество багов и неудобство А самое забавное что загрузку собственно IFC туда так никто и не победил. Но скоро.

Я тут занялся одной веселой авантюрой из жанра "что можно сделать если глаза не боятся, есть 20 долларов и хорошая идея", о которой расскажу через пару недель. Там все готово, осталось только долго долго тестировать, но рассказ я начну с конца. Я очень люблю что бы все было красиво, потому что если у вас красивое решение, красивая идея, то должны быть так же красивые названия, красивый внешний вид и красивая установка. Иначе зачем все это? И захотелось мне сделать установку через exe, а не через скрипты. Мне часто говорили знающие люди что это очень сложно и есть масса нюансов, я и решил разобраться. Разобрался. Оказалось не так все и страшно. Как это делать - делюсь, отдайте вашему ИИ агенту, пускай делает красиво.

Еще раз о том, что ИИ в инженерных руках творят чудеса и дают кучу возможностей.

🆕Друзья, реализовали новый калькулятор в нашем сервисе! На этот раз порадуем теплотехников: сделали удобный расчет теплопотерь в табличном виде. Расчетный модель доступен бесплатно. Юзаем и 🙃радуемся! 📎П.С: Да, в программе доступен экспорт в эксель и печать отчета в PDF. 🎯Отдельная благодарность Елене Ошиной, которая ведет у нас обучение по разделу ОВиК, за предоставленные алгоритмы.

Нам тут много раз говорили, что мы пишем очень сложно, непонятно и никому не нужно. Не могу не согласиться. А так же до сих пор очень много людей не хотят в ИИ, не могут в ИИ, не знаю как подойти к ИИ. А изначальной целью канала была популяризация ИИ решений для всех, а не только для тех, кто отличает тензор от перцептона и бинарник от свинарника. Так что встречайте руководство, в котором есть вообще все что бы просто взять и начать пользоваться достижениями информационной эпохи и делать свою жизнь веселее и продуктивнее.

Мы тут много говорим сложные слова и рассказываем сложные вещи, которые сами не понимаем. А ведь самое интересное это просто о сложном. Вот пишем мы про готовку RAGу и кажется что это все очень сложно. Да, так и есть, но ведь всегда есть уровни сложности. Написали кратко про RAG от easy до nightmare.

Л.Е.С., NPU и Core ML: как мы разгрузили Mac Mini Или как мы совершили прорыв (не отопления) Внутри Mac Mini процессор (CPU) и видеокарта (GPU) делят общую память. Они мощные, но потребляют много энергии и греются. Раньше для простых задач вроде перевода текста в векторы или базовой проверки ответа нам приходилось нагружать именно их. Но в процессорах Apple ( и не только) есть NPU (Neural Engine). Это отдельный чип, который физически спроектирован только для одной задачи: быстро и энергоэффективно перемножать матрицы, из которых состоят нейросети. Он делает это тихо, почти не греется и не отнимает ресурсы у процессора и видеокарты. Чтобы запустить модель на NPU, нужен мост в виде формата Core ML. В отличие от гибкого фреймворка MLX, модели под Core ML конвертируются заранее в жесткий формат (.mlpackage) с фиксированным размером ввода, например, ровно 512 токенов. Что мы сделали Мы убрали фоновые задачи из основной большой модели (Qwen3.5): Векторизатор (Qwen3-Embedding-0.6B) перевели на Core ML. Он оцифровывает текст десятками страниц в секунду, оставляя видеокарту свободной для генерации ответов. Валидатор Т.О.С.К.А.(MoritzLaurer MiniLM) тоже перенесли в формат Core ML. Он проверяет качество фактов на фоне, почти не расходуя энергию. Проблема стабильности и её решение У Core ML есть существенный минус: из-за жесткой структуры он не прощает ошибок. Если текст не влезает в лимиты или происходит сбой в адресации NPU, случается критическая ошибка памяти (SIGSEGV). Раньше из-за этого падал весь главный сервер управления MLX Host, и Л.Е.С. переставал работать. В версии Л.Е.С. 3.6 мы решили эту проблему. Теперь скрипты на Core ML работают не внутри общего процесса, а в изолированных фоновых задачах (coreml_embed_worker.py и coreml_validator_worker.py). Если случается сбой, он затрагивает только конкретный процесс. Основная система Л.Е.С. не падает, а мгновенно перезапускает упавший компонент, сверяет данные и продолжает выдавать проверенные ответы пользователю. Итог Мы грамотно распределили нагрузку. Тяжелая генерация текста осталась на видеокарте, а вся ежесекундная рутина по оцифровке и проверке фактов ушла на NPU. Система стала потреблять меньше ресурсов, освободила общую память и получила защиту от критических сбоев. Исходный код выложил. Удивительно, но завести его можно не только на Маке, а еще и на винде, попивая lemonade.

У Mac на Apple Silicon память устроена иначе, кто не знает. Раньше процессор пользовался одной памятью, видеокарта другой. Чтобы считать на графике, данные переносились туда и обратно. Это как склад и цех в разных зданиях: работает, но время уходит на перевозку. Кстати, а помните были еще физические карты? У Apple Silicon память общая. Процессор, графика и другие вычислительные части Mac обращаются к одному быстрому запасу. Для локальных нейросетей это хорошо: меньше перекладывания данных, меньше задержек, выше скорость. Но общая память действительно общая для всех. Если в Mac 24 ГБ, нельзя отдать все 24 ГБ языковой модели. Часть нужна системе, окнам, графике, браузеру и фоновым службам. Ещё часть используют компоненты Л.Е.С.: поиск, база смысловых отпечатков, разбор документов, проверка ответов и экран управления. Когда памяти мало, macOS включает подкачку: часть данных временно уезжает на накопитель. Система не падает, но нейросети резко замедляются. Машина тратит силы не на работу, а на перекладывание данных. Поэтому Л.Е.С. должен не просто запускать модели. Он должен управлять памятью. Представим Л.Е.С. как небольшой атомный реактор внутри Mac. У реактора есть активная зона, охлаждение, датчики, управляющие стержни и операторская. Он даёт энергию только если нагрузка и охлаждение согласованы. Если включить всё сразу, реактор не станет мощнее. Он станет нестабильным. У Л.Е.С. активная зона это общая память Mac. В неё одновременно хотят попасть языковая модель, модель смыслового поиска, база векторов, разборщик документов, проверка ответов, экран управления и сама операционная система. Каждый узел полезен, но каждый забирает память. Языковая модель это главный энергоблок. Модель поиска превращает документы в смысловые отпечатки. База векторов хранит карту, по которой Л.Е.С. находит нужные фрагменты. Разборщик читает PDF, таблицы, письма и вложения. Проверка ответов не даёт системе говорить то, чего нет в источниках. Если всё это включить одновременно, Mac быстро упрётся в память. Поэтому в Л.Е.С. появился диспетчер, то есть операторская. Он смотрит на датчики: сколько памяти свободно, сколько занято подкачкой, какие службы работают, идёт ли переиндексация, какой документ обрабатывается и сколько осталось. Если памяти хватает, работа продолжается. Если память на грани, система становится осторожнее. Если памяти мало и подкачка высокая, тяжёлую работу лучше не начинать. Нужно подождать, выгрузить лишнюю модель или закрыть тяжёлое приложение. Для этого у Л.Е.С. есть профили памяти: обычный чат, лёгкая индексация, тяжёлые документы и обслуживание. Каждый режим включает только то, что нужно сейчас. Главное правило простое: не включать все тяжёлые узлы одновременно. Если идёт индексация, ответы временно закрываются. Это защита: система занята тяжёлой работой и не подключает ещё одну большую нагрузку. Подкачка похожа на температуру активной зоны. Немного допустимо. Но если она растёт, Л.Е.С. доходит до безопасной границы, например до конца текущего документа, и ждёт. Он не портит индекс и не начинает следующую тяжёлую операцию. Это и даёт режим "нажал и ушёл". Л.Е.С. также не закрывает чужие программы сам. Он может показать, кто ест память: браузер, редактор видео, тяжёлое приложение. Но решение остаётся за человеком. Система подсказывает, а не вырывает рубильник из рук оператора. Теперь это не набор скриптов, где "запустил и надеешься". Это управляемая установка: датчики, режимы, паузы, продолжение после паузы, защита от повторного запуска и понятный экран оператора. Л.Е.С. не пытается победить ограничения Mac. Он учится жить внутри них: запускать тяжёлое по очереди, ждать охлаждения, не портить индекс и сохранять управляемость во время долгой работы.

HDMI dummy — это маленькая заглушка, которая притворяется монитором. Mac видит её как обычный экран: получает от неё список разрешений и включает нормальный рабочий стол. Зачем это нужно: Mac mini без монитора становится headless, то есть “безголовым”. Для macOS это не совсем обычный режим. Она может дать странное низкое разрешение, не включить нормальный вывод картинки, сбросить окна, плохо работать через удалённый доступ или после сна. Apple не делает из Mac mini полноценный сервер без экрана. Система всё ещё рассчитана на живой дисплей: монитор есть, пользователь рядом, окна куда-то выводятся. Если экрана нет, macOS начинает экономить и упрощать графику. Dummy это обходит грубо, но надёжно: он говорит системе “монитор подключён”. Поэтому macOS держит рабочий стол, нормальное разрешение и стабильную графику. Док M5 интересен тем, что у него есть настоящий маленький экран 1280×720. Если Mac видит M5 как дисплей, он заменяет dummy: система уже не headless, а Совушку можно вывести прямо на этот экран. Итог: dummy нужен, когда Mac mini стоит без монитора. M5 может занять его место, если определяется как отдельный дисплей.

Индексация РАГ закончилась еще в воскресенье, и в процессе всего два раза меняли на ходу двигатель. В прецессе мы узнали очень много про управление памятью и не только. Что мы сделали и куда пришли описано на сайте. Успешно погоняли несколько типов моделей для теста. Удивительно, но все работает ровно до тех пор пока память стабильна. Любые колебания грозили свалить систему и пришлось делать систему защиты раг машины, которая, в том числе, умела аварийно гасить опасные процессы. Но, если что-то может пойти не так - оно пойдет не так. Изначальная идея была максимально правильной и логичной: • Не загружать тяжелую нейросеть без предварительной проверки ресурсов • Не запускать индексацию при нехватке памяти и следить за файлом подкачки • Держать под контролем активные фоновые задачи • Честно выгружать модели после тяжелых расчетов и не давать интерфейсу врать, что «всё окей» Постепенно система обросла хорошими предохранителями: появились лимиты по свободной оперативке и файлу подкачки, строгий контроль доступа к чату, безопасное чтение строго по одному файлу, выгрузка тяжелых моделей из памяти и жесткий запрет на генерацию, если предварительная проверка провалена. Но в одном месте защита оказалась написана слишком буквально. Когда файл подкачки переполнялся и доходил до критического порога, наш алгоритм-сторож решал: «Спокуха, сейчас я всех спасу». Вот только вместо того, чтобы просто выгрузить из памяти свои же нейросети, он начинал убивать любые «необязательные» процессы вокруг себя. В расстрельном списке оказались не только наши компоненты, но и жизненно важные процессы самой операционной системы: оконный менеджер, панель управления и прочее. То есть мы строили умную автоматику пожаротушения, а на деле получили мужика с топором, который при легком задымлении врывается в серверную и начинает рубить всё, что шевелится. Как исправили: Отобрали у защиты права трогать чужие процессы. Теперь при критической нехватке памяти она имеет право выгружать только собственные модели (основную, проверяющую и кодировщик). Всё остальное — исключительно через явную команду оператора. Мораль: Система защиты должна ограничивать радиус поражения, а не становиться источником новой аварии. Предохранитель, который умеет спасать систему ценой убийства самой системы — это не предохранитель. Это инцидент из совершенно другой весовой категории.