ИИ и RAG: помощник по техническим вопросам для систем управления освещением
- Масштаб базы: упоминается около 50 000 онлайн-устройств и накопленные знания по жизненному циклу железа и платформе.
- Проекты: описано примерно 1 500 цифровых проектов систем управления, около 300 из них реализованы и сопровождаются.
- Стек и локальный запуск: RAM увеличена до 32 ГБ, GPU 6 ГБ; используются Quadrant (векторная БД), эмбеддер FRIDA, LLM qwen/qwen3-8b-6K, LangChain и Docker; Claude применён для разметки документов.
- Подготовка знаний: документы режутся на смысловые блоки 400–450 слов и на чанки по 300 символов с перекрытием; в LLM отправляются смысловые блоки, а не мелкие чанки.
- Пилот и производительность: на первом этапе — порядка 50 документов и несколько тысяч векторов; ответ локальной модели занимает 20–40 секунд.
- Результат за 6 месяцев: документация дополнялась и приводилась в порядок, а в цифровую платформу добавлены интерфейсы поиска/чата и интеграции через REST API, n8n и Telegram-бота.
Почему это важно: кейс показывает, как RAG превращается из «поиска по PDF» в инструмент управления знанием и техдолгом: несостыковки между документами начинают проявляться в выдаче рядом. При этом автор подчёркивает, что ключевой ресурс — нормализация реальных вопросов пользователей, а не только векторизация. В такой логике документация переписывается под то, чтобы отвечать на вопросы, а не просто «быть написанной».
На что обратить внимание: в статье подчёркнуто, что качество ответов ограничено принципом GIGO: без доработки исходных текстов модель будет находить противоречивые или неполные фрагменты. Видна зависимость UX от локального железа: при времени ответа в десятки секунд выбран одноходовый сценарий, а не длинные цепочки обращений. Отдельный слой работы связан с рисунками и интерфейсами: их привязка к тексту требует аккуратной подготовки и местами ручного сопоставления.
Коротко
- Кейс показывает прикладной сценарий RAG в инженерном продукте: ответы на техвопросы меньше зависят от «памяти экспертов» и уходят в базу знаний.
- Если выдача начинает путаться из-за разных версий документов, это обычно означает конфликт источников: RAG подсвечивает места, где требуется согласование.
- Вопросы пользователей становятся драйвером улучшений: по ним проще находить пробелы, чем пытаться заранее угадать, какие инструкции важнее для базы.
- Отдельное внимание к схемам и интерфейсам объяснимо: в техподдержке часто важна визуальная часть, поэтому механика вывода рисунков становится критичной.
- Разделение на предобработку и локальные ответы помогает контролировать затраты: дорогая модель участвует в разметке, а ответы строятся на своей базе.
FAQ
Зачем это важно для продуктовой компании, где технические нюансы, инструкции и лайфхаки накоплены годами и живут в разрозненных документах?
В статье показано, что RAG делает пробелы и несостыковки видимыми в процессе запросов и помогает быстрее доводить документацию до ответа на вопрос.
Как в проекте организована подготовка документов, чтобы модель отвечала по смыслу разделов, а не по случайным коротким кускам текста?
Документы разбиваются на смысловые блоки 400–450 слов, а поиск ведётся по чанкам; в LLM отправляются именно смысловые блоки как payload.
Почему автор уделяет столько внимания рисункам и интерфейсам, а не только тексту, когда речь идёт о поддержке систем управления освещением?
По описанию, пользователи часто запрашивают схемы подключения и элементы интерфейса, поэтому изображения выделяются и привязываются к соответствующим блокам.
Почему на первом этапе выбран одноходовый запрос к локальной LLM вместо агентного сценария с несколькими шагами и переформулировками?
Автор пишет, что на 6 ГБ GPU модель отвечает 20–40 секунд, и длинная цепочка обращений утомляла бы пользователя; агентный режим вынесен на перспективу через n8n.
Читайте также
LLM-агент для поиска свободных доменов: автоматизация подбора- Как тимлид заменил десятки вкладок на файловую систему и Claude Code
- «ИИ, найди факты, а я подумаю»: почему гибридный подход не работает для форсайта
- Как я локально тестировал новый Qwen 3.6 и Gemma 4
- Как научить LLM исправлять код без лишних изменений
- RAG-пайплайн для PDF с разметкой на смысловые блоки и отдельным слоем изображений: Практичный способ подготовить техдокументацию для RAG: сначала разметить PDF на смысловые блоки (400–450 слов) и извлечь изображения с описаниями, затем уже делать мелкие чанки для векторного поиска. В выдачу LLM отправляются именно смысловые блоки как payload, а не сами чанки, что помогает сохранить связность ответа и не терять контекст.
[RAG / Подготовка документации]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Внутри платформы SUNRiSE автор собрал локальный RAG-помощник для ответов на технические вопросы по системам управления освещением. В процессе выяснилось, что качество ответов упирается в структуру и согласованность документации.