Немного про локальные нейросети и их применимость в инженерном деле

by Опубликовано

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

Если кратко и предельно упрощённо, то большая языковая модель — это потомок обычного Т9 в вашем телефоне, «угадывающий» следующее слово в предложении, оснащённый специфическими алгоритмами, позволяющими выделять из текста ключевые слова, взвешивать их взаимосвязи, и «понимать» смысл, а затем — формировать ответ некоторым вероятностным образом, подставляя слово, которое статистически должно следовать далее в тексте. Каждая модель имеет «веса» — массив чисел, представляющий собой многомерную матрицу… Так, я начинаю умничать…

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

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

Кстати, о «раздумьях». Современные модели созданы по нескольким достаточно различающимся архитектурам, и часть из них предполагает наличие у модели подобия внутреннего диалога человека, или мыслительного процесса, формирующего ответ. Это улучшает качество ответов, но делает языковую модель достаточно медленной, а так же может приводить к её зацикливанию, когда она начинает «гонять по кругу» одну мысль, уходя в бесконечный цикл размышлений. «Думающие» (Thinking-модели) модели хороши для работы с литературными текстами, но в инженерном деле, на мой взгляд, их следует избегать, отдавая предпочтения моделям, строго исполняющим инструкции (Instruct-модели).

Большинство современных моделей — не чисто языковые, работающие исключительно с текстом, а мультимодальные, обрабатывающие так же как минимум изображения, а зачастую и видео и звук. В нашем случае это плюс — мы можем «показать» модели чертёж, схему, или рисунок, и «обсудить» с ней увиденное. При небольшой донастройке рабочей среды, вы можете не просто просить модель посмотреть загруженное вами изображение, но и «рассматривать» изображения в вашем архиве с документами, о котором и будет далее.

Как я уже упоминал выше, языковая модель не берёт информацию из ниоткуда — она должна или содержаться в обучающих наборах данных, или вы должны её подгружать отдельно, что требует ресурсов на обработку каждой страницы документа, и занимает оперативную память. Если документ окажется слишком большой, то к его концу языковая модель может забыть о том, что было в его начале. Поэтому для работы с большим объёмом дополнительной информации придумали «Генерацию с дополнительной выборкой» (Retrieval-Augmented Generation, RAG). Суть в том, что документы заранее обрабатываются совсем маленькой узкоспециализированной языковой моделью, и записываются в базу данных, из которой большая языковая модель берёт подсказки при ответах на вопросы, о которых она не знала на момент обучения. Это и есть основной способ, позволяющий превратить простой чат-бот в реального помощника.

За несколько недель я протестировал основные модели, доступные для запуска на локальной машине — одни из последних версий Qwen, Gemma, и Mistral. Поскольку запуск производится на Mac с процессором M4 и 24Гб общей памяти, то несмотря на то, что модели с 26-35 миллиардами весов были крайне интеллектуальны, выбор пришлось делать из менее объёмных младших моделей, с числом параметров от 8 до 13 миллиардов. Это были Qwen3.5:9B, ставший фаворитом, Gemma4:E4B, и Ministral3:14B.

Запуск производился как через Ollama, так и через llama.cpp, и через нативный для Apple Silicon MLX-VLM. Лучший баланс между интеллектом и производительностью оказался у модели Qwen, как и способности к владению разговорным русским языком. Ministral немного уступает по возможностям распознавания изображений, и находится примерно на том же уровне интеллекта, что и Qwen, но примерно в два раза медленнее него. А вот Gemma4 легко обходит их по производительности, но заметно отстаёт в качестве ответов, разумеется, только в рамках своей весовой категории.

Итак, перейдём к запуску. Для этого использовался нативный движок MLX-VLM для языковой модели, и интерфейс Open-WebUI для расширенных функций, включая RAG. Запускаем соответствующие скрипты, и видим использование ресурсов моделью…

Почти 16 гигабайт у нас сразу оказывается занято операционной системой и моделью.

А далее — тестируем. Я не буду приводить полные примеры диалогов, остановлюсь на самом интересном, а именно — «скормить» модели какую-нибудь принципиальную схему в среднем качестве, и расспросить, что модель здесь видит, как оно работает, и задавать уточняющие вопросы. Поехали…

  • Расскажи, что ты видишь на этом рисунке? Похоже, это какая-то схема?
  • Да, это электронная схема — более точно, схема усилителя мощности на ламповых (вакуумных) триодах. На рисунке изображён трёхступенчатый ламповый усилитель, построенный на основе двухтактной схемы (push-pull) на выходной стадии. Вот что можно увидеть на схеме:

Далее модель достаточно подробно описывает схему усилителя, делая небольшие ошибки в номиналах деталей. Более «умные» модели таких ошибок уже не делают, абсолютно точно «видя» и номиналы деталей, и разъясняя их назначение.

Далее модель делает заключение:

  • Это схема лампового стереоусилителя мощности, построенного на лампах 6Н3П и 6П14П, с выходом на динамик УШ-19 × 19. Вероятно, это схема из советского радиоприёмника или отдельного усилителя, например, из модели “Родина” или “Олимпус”. Если нужно — могу помочь разобрать каждый каскад подробнее, рассчитать параметры или объяснить принцип работы!

В целом — достаточно верно, на уровне троечника из ПТУ или начинающего радиолюбителя.

  • Детали с обозначением 05 — это резисторы, скорее всего сопротивлением 0,5МОм, соединяющие сетки с общим проводом, и вместе с резисторами в цепи катодов создающие автосмещение, разве не так?
  • Вы почти правы, но есть важный нюанс — в этой схеме обозначение «05» (или «0,5») не означает 0,5 МОм, а скорее всего означает 0,5 мкФ — то есть это конденсаторы, а не резисторы.

Далее следует попытка доказать мне, что резисторы это конденсаторы. Не буду приводить его полностью.

  • Правильная интерпретация:
    Элементы с обозначением «0,5» — это конденсаторы ёмкостью 0,5 мкФ, которые:
    Шунтируют катодные резисторы (480 Ω и 120 Ω) — чтобы на частотах выше среза (обычно ~100–200 Гц) катод был заземлён через конденсатор, что повышает коэффициент усиления и снижает нелинейные искажения. Соединяют сетки каскадов — для передачи переменного сигнала между каскадами (блокировка постоянного тока).
    Как работает автосмещение?
    Автосмещение создаётся за счёт падения напряжения на катодном резисторе из-за тока катодного луча. Конденсатор шунтирует этот резистор на высоких частотах, но на низких частотах он «отключается», и автосмещение работает как обычно.
    Таким образом, конденсаторы 0,5 мкФ — это часть цепи автосмещения + связи между каскадами.
    Дополнительно:
    Резисторы в цепи сеток (например, 100 — скорее всего 100 кОм) служат для защиты сетки от пробоя и установки начального смещения (вместе с катодным резистором). Значение 0,5 — это ёмкость, а не сопротивление.
    Итог:
    Нет, элементы с обозначением «05» — это не резисторы 0,5 МОм, а конденсаторы ёмкостью 0,5 мкФ. Они участвуют в создании автосмещения (шунтируя катодные резисторы) и в связи между каскадами (блокировка постоянного тока).
    Это типичная практика в ламповых схемах того времени — использовать конденсаторы с номиналами в мкФ, записанными как целые или дробные числа без единицы измерения

Но у нас же знаний побольше, чем у языковой модели, побольше ведь, да?

  • Посмотри на самую левую деталь на схеме — это ведь резистор?

И следует «прозрение»!

  • Да, вы абсолютно правы! Самая левая деталь на схеме (с обозначением 0,5) — это резистор сопротивлением 0,5 МОм (500 кОм).
  • В предыдущем сообщении я сделал ошибку в интерпретации схемы. Я предположил, что все элементы с обозначением «0,5» — это конденсаторы, потому что в других местах схемы (например, рядом с катодными резисторами) есть элементы с таким же обозначением, но другой формой.
    Однако, если посмотреть внимательнее на саму схему:
    Слева внизу есть два элемента, соединённых параллельно: Один — это резистор (прямоугольник или линия с полосками), обозначенный как 0,5. Другой — это конденсатор (две параллельные линии, иногда с плюсом), обозначенный как 0,5 (но с полярностью — значит, электролитический).
    То есть, два разных элемента, оба с номиналом 0,5, но разного типа.

Ну то есть это как разговор с типичным троечником на экзамене, понимающим только часть материала. Давайте зададим ещё парочку вопросов:

  • Кроме того, ты уверен, что это двухтактный усилитель? У нас ведь только одна лампа 6П14П.
  • Вы абсолютно правы — и спасибо за внимательность! Это НЕ двухтактный усилитель. Это однотактный ламповый усилитель мощности на одной лампе 6П14П, работающий в режиме триода (а не пентода), с выходным трансформатором.

Не успел исправиться, как тут же сморозил следующую глупость, начав дальше заливать о том, почему это именно триодное включение лампы (хотя на схеме, конечно, это пентодное включение). Далее я попросил модель рассказать об отличии триодного и пентодного включения, что она сделала вполне корректно, а затем предложила:

  • Хотите, я покажу, как бы выглядела схема в пентодном включении? Или помогу рассчитать параметры для триодного режима?
  • Да, покажи.
  • Отлично! Давайте разберём, как бы выглядела схема в пентодном включении для лампы 6П14П, и что нужно изменить.

Далее модель даёт достаточно здравое описание схемы пентодного включения, а затем — пытается изобразить её в псевдографике, и…. уходит в упомянутое выше зацикливание, в результате чего её работу приходится прекратить принудительно. Скорее всего, Open-WebUI не совсем корректно передаёт модели специальные символы разметки, и она не знает, когда остановиться…

Примерно так выглядит потребление ресурсов при работе модели:

Сама модель использует GPU-ядро процессора, и совсем немного E-CPU-ядер. А по графику справа внизу отлично видно, как меняется энергопотребление при «думании» (в левой части), и при генерации ответа (в правой части).

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

Громаднейшим плюсом является то, что модели являются многоязычными, и могут отвечать вам на русском языке на основании исходных документов, например, на английском или китайском. Я пробовал загрузить datasheet на китайском на контроллер заряда SW6205, и модель полностью адекватно описывала его параметры на русском, а я проверял описание в аналогичном datasheet на английском. Это очень удобно, особенно учитывая, что у вас может быть пара десятков даташитов на разных языках, и нужно оперативно сравнивать параметры описываемых в них деталей, выбирая оптимально подходящие для задачи.

Точно так же, использование языковой модели как ассистента, позволяет ориентироваться в содержимом разнообразных справочников и учебников. При работе с RAG модель честно отвечает, приводя интересующую информацию со ссылками на документы, и не придумывая ничего, если информации в документах нет. Фактически, вам больше не надо от корки до корки прочитывать КАЖДЫЙ справочник, или искать нужное в КАЖДОМ из них по оглавлению — как минимум, языковая модель предоставит вам возможность быстрого поиска нужного материала.

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

Подводя краткий итог, можно резюмировать следующее:

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

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

Опубликовано Дмитрий Андреевич