• Масштаб базы: упоминается около 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 от локального железа: при времени ответа в десятки секунд выбран одноходовый сценарий, а не длинные цепочки обращений. Отдельный слой работы связан с рисунками и интерфейсами: их привязка к тексту требует аккуратной подготовки и местами ручного сопоставления.