AI & RAG. Помощник по техническим вопросам систем управления освещением

Введение

Свою первую программу я написал в 1988 году на калькуляторе МК52. Очень хотелось программировать и даже максимально странный интерфейс не останавливал. Утекло почти 40 лет. Были Атари, Синклеры, 286 IBM, Интернет, смартофоны. Но все эти технологии входили как-то постепенно, приспосабливаясь и без шока.

AI ворвался в жизнь бывалого ИТшника как пыльным мешком по голове. После первого шока, скормленных Дипсику результатов анализов, идей подарков, профессиональная “чуйка” потребовала придумать новой чудо-технологии боевое применение в том, чем я занимаюсь каждый день на протяжении всей сознательной жизни.

Предметная область

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

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

Системы управления освещением - объекты, хоть и не очень сложные, но могут быть объемными, например, есть город, где стоит 8 000 контроллеров, и очень разноплановыми (логистические комплексы с сотнями датчиков, школы, стадионы и промышленные предприятия с цехами по полкилометра длиной).

Но все это - тема для совсем другой истории, а данная статья возникла из того, что, за годы НИОКРов и внедрений мы накопили багаж из 50 000 он-лайн железок, развешанных по всей стране от Калининграда до Владивостока, от Салехарда до Сталинграда. И в том багаже еще есть огромный технический долг, очень специфические знания как о железе с его полным жизненным циклом, так о нюансах придуманной нами технологии, информация о 1 500 цифровых проектах систем управления, примерно 300 из которых воплощены и сопровождаются. Все это с разными версиями железа, микропрограмм, слоистой Цифровой Платформой - кошмар технического директора - мой личный кошмар.

Описание проблемы

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

Бум AI - шевелит мозги и настроения. Если есть хоть малейший шанс повысить эффективность нашей компании используя AI - значит им нужно пользоваться. И вот, на входе, считай, идеальная среда: продуктовая компания с кучей рутинных, но не детерминированных задач, с одной стороны, и AI, бьющий копытом, готовый решать все эти задачи - с другой. ВПЕРЕД!

Основная проблема всех прикладных применений AI - найти это прикладное применение. CustDev показал - все мои программисты, менеджеры и проектировщики - ксенофобы. Результаты интервью, если опустить детали, были примерно такими: проблем, конечно, много, но мы справляемся и нам не нужны новые проблемы еще и с AI. Как говорил Генри Форд "Если бы я спрашивал людей, чего они хотят, они бы ответили: более быстрых лошадей”.

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

• Соберу всю документацию в векторную базу

• Дам к ней доступ проектировщикам, интеграторам и сервисным инженерам через AI

В целом, это простой план - надёжный как швейцарские часы - ПОЕХАЛИ!

Архитектура

На 2025, новый год я подарил себе игровой комп: 16Гб оперативки и GPU 6Гб. Планировал летать на дронах в симуляторах, но в реальном мире летать интереснее - комп стоял и пылился. Его было решено задействовать для нашего локального AI. Итого:

• Добавлена RAM до 32 гб

• Quadrant - как векторная БД

• FRIDA от Сбера - Эмбеддер

• Claude для разметки - слишком дорого гонять каждый запрос через API, но для предобработки документов — самое то.

• qwen/qwen3-8b-6K - LLM

• N8n - на перспективу

• Pyton и Java (наша основная среда разработки)

• Библиотека LangChain.

Все в докерах.

Сценарии

Векторизация документов:

1. Загружаем PDF документ, его же потом можно будет отдать пользователю по запросу

2. Этот же документ загружаем в Claude с промптом разбить на логические блоки длиной 400-450 слов. И выделить из документа рисунки с описанием. Этот момент важен, на нем я потом остановлюсь подробнее

3. Результат работы Claude в виде размеченного MD текста кладем рядом с загруженным документом.

4. Логические блоки чанкуем по 300 символов с перекрытием

5. Из рисунков, размеченных в MD, заполняем отдельную таблицу в БД

6. Чанки векторизуем FRIDой и добавляем в Quadrant

7. Достаем из загруженного PDF картинки и сопоставляем их с теми, что взяли из разметки документа (процесс ручной).

Итог: Документ векторизован, рисунки прикреплены к соответствующим payload

Запрос к документам:

1. Получаем запрос пользователя

2. Векторизуем FRIDой

3. Ищем близкие по score чанки в Quadrant

4. Достаем payloadы найденных чанков вместе со ссылками на рисунки

5. Отправляем в qwen/qwen3-8b-6K со специальным промптом

6. Результат показываем пользователю

Мне кажется, еще в мае 2025 эти сценарии были инновацией. Сегодня, в первых числах 2026, они - нетленная классика, которую не надо объяснять.

Payload

“Узок круг этих революционеров. Страшно далеки они от народа. Но их дело не пропало. Декабристы разбудили Герцена. Герцен развернул революционную агитацию.” (с) Ленин

По классике - чанки обломки текста, близкие по размеру к будущему вопросу пользователя. Размер имеет значение для сравнения векторов запросов и чанков. 300 символов - алхимически ОК.

В классике Payload - метаданные чанков. Но, так как, даже в чистой умозрительной теории, чанки на столько малы, что не сохраняют смысл, то мы просто дописали классику и в метаданные чанков положили смысловой блок

ИТОГО: Смысловой блок размером в 400-450 слов - ядро базы документации. В LLM отправляются именно смысловые блоки, а не осколки в виде чанков. На смысловые блоки разбивает Claude - самый неприятный рутинный процесс. Цифра в 450 символов родилась при анализе документации. Оказалось, что это тот размер, в который можно уложить почти все разделы документации, паспортов и инструкций. И, так как мы полностью владеем документацией - те разделы что не поместились можно/нужно доработать.

Потом оказалось, что вообще всю документацию надо доработать, но об этом дальше.

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

Немного о FRIDA

Существует достаточно много эмбеддеров (модели, которые преобразуют текст в вектора). Мы начали с FRIDA, так как, по слухам, лучший эмбеддер для русского языка, и ее/его можно развернуть локально. Потом пробовали другие модели. Но, в целом, эмбеддер не сильно влияет на результат. Работает классический принцип информатики GIGO (Garbage in, garbage out).

Есть только один рецепт красивых и полных ответов на вопросы пользователей: подготовить документацию так, чтобы она на них отвечала. И это стало возможным только когда появились инструменты RAG, LLM, вопросы пользователей.

Web-интерфейс для управления документацией

Есть у меня ощущение, что человечество уйдет от графических интерфейсов. Мы же ушли от лошадей и пишущих машинок. Но пока 60% интефейсов: таблички-таблички. На рисунке 1 пример документов в базе. Все очень просто: загрузили документ в PDF, его сразу можно скачать или скопировать ссылку (иконки рядом с названием). Для некоторых документов внешний доступ запрещен.

Статус векторизации, количество изображений, блоков и чанков - для информации.

Из этого интерфейса можно попасть в RAG поиск или чат (рисунок 2). В классическом чате - результат, прошедший через LLM Qwen 3, в RAG - сырые данные с инфо о SCORE. Видны все чаты и можно подправить системный промпт (для админов)

Отмечу, что, так как Qwen крутится на 6ГБ GPU, то даже с разрешением в 6 бит - он думает от 20 до 40 секунд. То есть мы не стали делать агента, который утомит в ожидании пользователя, а решаем вопрос одним нырком в LLM.

Всего на первом этапе в базе порядка 50 документов - несколько тысяч векторов. Оказалось, что паника и боль создавались не таким и большим количеством файлов.

Промпт

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

Ниже тот самый промпт. Его, в итоге, в несколько итераций доработал Claude. Это значительно быстрее чем перестроить нюансы архитектурного решения.

Рисунки

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

Были следующие стратегии как продавить через LLM рисунки:

1. Векторизовать названия рисунков и делать по ним доп запрос. Оценили - есть высокий шанс получить рисунки совсем из других документов - отказались.

2. При прикреплять рисунки, найденные в смысловом блоке - к payload этого блока. На этом остановились.

Claude при разметке на блоки форматирует названия рисунков в MD формат: ![Рисунок 2.][Кабель LAPP FLEXICORE 100] - при обработке текста -ссылки на эти рисунки выделяются и сохраняются в отдельную таблицу.

Потом, в отдельном интерфейсе (рисунок 3) ручками происходит сопоставление того, что из текста документа выделил Claude и из PDF этого документа выделил LangChain.

Инсайты

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

Нестыковки в документации

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

“Корявый” язык

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

И, самое главное, много документации написано чтобы быть написанной, а не для того, чтобы ответить на вопросы пользователей. Соответственно, FRIDA далеко не всегда находит нужные куски документации по запросу пользователя. Грубо говоря - авторы и пользователи говорят на разных языках.

Вычитка вопросов пользователей

Данный момент - самый главный. Векторизация документации - мероприятие вторичное, не смотря на то, что занимает реальные человеко-часы. Основная задача: ответить на вопросы пользователей так, чтобы они не вернулись к сервисным инженерами (или вернулись, но с разогретым мозгом). Получается, что самым ценным в этом небольшом проекте - являются вопросы пользователей. Вопросы, которые невозможно сгенерировать сервисными инженерами или LLM, тут нужны слепые эксперименты.

В результате, появилось несколько дополнительных документов, название которых начинается с “Типовые вопросы по…”

AI-first

“В прошлом веке” - еще год назад, на технические вопросы пользователей, которые пробивались через паспорта, инструкции, сервисных инженеров и проектировщиков, собирался консилиум, разрабатывался ответ, вычитывался - отправлялся чуть ли не официальным письмом.

Теперь все обращаются к SUNRiSE_AI, просят проверить ответ, если ок - то ответ летит пользователю. Если ответ не ОК, то происходит быстрая доработка документации и появляется новая, очень полезная информация для людей. Мир изменился радикально.

Постепенно, интеграторы получаются ссылку на Телеграмм бота и перестают писать по каждому поводу.

n8n

В итоге, к RAG по документации программисты прикрутили обычное REST API и я в n8n за несколько часов накидал автоматизацию (рисунок 4), аналог которой в нашей Цифровой платформе занял порядка 80 человеко-часов. Причем, тут уже действует АИ Агент, а не одноходовой запрос. То есть, агент может переформулировать вопросы пользователя, несколько раз дернуть базу. В общем - широкое поле для тюнинга и развития.

Результат за 6 месяцев

Документация приведена в порядок с помощью AI, для AI, но конечный получатель плюсов - человек.

Создана очень интересная система векторизации документов. Вероятно, существуют подобные сервисы, но тут прямо внутри цифровой платформы лежит куча информации, к которой есть доступ через API.

Попробовали локальную LLM. Qwen очень хорош, хоть пока и медленный на маленькой карточке. Однозначно у маленьких локальных моделей - большое будущее.

Модное, стильное, молодежное направление AI в продуктовой компании в простой реализации - поднимает доверие клиентов.

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

Ну а лично я испытываю неимоверную радость, когда в логах ботов появляются вопросы и ответы. Видно как нудную работу делают роботы, делают хорошо, комплексно, а мне остается только чуть редактировать их поведение.

Следующий шаг - сделать кнопку Где я в Цифровой Платформе.