
С чего всё началось (можете пропустить, тут немного жизы)
С приходом LLM у меня возникло желание использовать их с пользой для компании. Куча маркетинговых видеона ютубе — как ИИ заменил сотрудников, стал всё знать и прочий шум, который только набирает обороты, — меня очень вдохновили. И я, вооружившись LM Studio, закинув всю документацию в контекст и задав вопрос, быстро приземлился на землю.
TTFT (время до генерации первого токена) на домашней видеокарте 4070 Super, входном контексте в 120к токенов и 8B‑модели — 4 минуты. TPS (скорость генерации) — 3,5 т/с. Качество ужасное: нюансов доменной области компании ИИ не понимает. Итог: не годится.
Далее я узнал про такой подход, как RAG. Подумал: серебряная пуля. Стал изучать эту тему — и оказалось, что там настолько обширный цветник из подходов к чанкингу, парсингу, ретриву, да и в целом паттернов RAG (native, graph, CAG), куча метрик (recall, precision и ещё сотня наберётся), что я вот до сих пор, уже год с лишним, изучаю это. И могу точно сказать, что ни одна готовая система или фреймворк не закроет на 100% конкретно Ваш случай. И честно, ПростоГраф тоже. Но об этом далее.
Что такое LightRAG?
LightRAG — это open‑source RAG‑фреймворк от команды HKUDS, который отвечает на вопросы по твоим документам. Его особенность в том, что он совмещает обычный векторный поиск с графом знаний: при индексации вытаскивает из текста сущности и связи между ними. За счёт этого он лучше отвечает на вопросы, где важны отношения между объектами, а не просто похожие куски текста, где можно упустить важные тонкости.
Официальный репозиторий LightRAG
Почему LightRAG?
Причин много, основные:
Open‑source
Достаточно эффективный поисковый движок под капотом
Готовый парсер (включая мощный Docling) и чанкер
Простота в управлении системой в целом
Готовый WebUI
Я перепробовал много разных RAG‑фреймворков и систем, RAGFlow, Flowise, AutoRAG. Пробовал десктоп‑варианты — Jan, AnythingLLM, GPT4ALL и прочие. Строил с нуля свои пайплайны, но возвращался к LightRAG.
В целом у LightRAG хорошее, крепкое ядро, и дабы не раздувать статью пересказами уже существующей информации, более подробно Вы можете почитать в их официальном репо и статьях:
Как мы улучшали качество поиска с помощью графа знаний и что из этого вышло
Графы знаний в юридическом домене: эксперимент с LightRAG
Там логика и архитектура LightRAG разобрана до косточек.
ПростоГраф, что это? И зачем он вообще поя™вился?
Как я уже сказал это форк, глубокий форк, но не самого поискового движка, его я не трогал.
Работает? НЕ ТРОГАЙ!
Я оснастил его мощной обвязкой, чтобы сотрудники из разных отделов компании могли использовать его как рабочий инструмент, а не MVP. Позволяя очень тонко управлять контекстом, промптами, ролями и отделами. Что позволяет загрузить один раз документацию, немного донастроив всё через удобный WebUI, дать учетку Вашему бухгалтеру или инженеру технической поддержки и тем самым здорово упростив им жизнь. У них будет лишь простая веб страничка перед глазами, к который уже все так привыкли в обычном формате общения с LLM.


Что есть в ПростоГраф, чего нет в LightRAG?
Управление отделами, пользователями и их учетными данными.
Выбор — какие документы физически доступны разным отделам. Не нужная для отдела продаж спецификация API даже не дойдет до ретрива, не потратит токены.
Кастомизация системных промптов для каждого отдела. Стиль ответов для отдела продаж и отдела тестирования — разный.
Возможность выборочно некоторые документы целиком подавать в контекст для генерации. Важно для процедурных инструкций, где нужно строго выполнить инструкцию по пунктам, а не верить в чанки.
Возможность каждому документу добавить свою метаинформацию. Не меняет документ, но позволяет до настроить поведение LLM при ответе.
Сбор обратной связи от пользователей под каждым ответом.
Просмотр всех чатов и оценок на странице администратора, фактически в бою собираем реальный eval сет.
Передача в LLM истории сообщений, фиксированное кол‑во последних пар вопрос‑ответ, чтобы LLM видела историю и не ломалась на Multi‑Turn кейсах.
Сохранение истории чатов у пользователя (а‑ля боковое меню).
Просмотр исходных документов сразу в чате.
Управление провайдерами LLM, эмбеддингов, реранкеров — сразу в WebUI.
Настройка чанкинга (размер/перекрытие) в WebUI.
Полностью русский интерфейс, грамотно переведены десятки крупных, подкапотных промптов ядра. Переведены почти все сообщения пайплайна. Да, в LightRAG был русский, но очень в ограниченном объеме. Система заточена под реальный РУ‑сегмент.
Безопасность тоже забыта не полностью, — персистентный JWT‑секрет, защита /login от перебора, предупреждение о дефолтном пароле, отзыв доступа в реальном времени (роль/отдел перечитываются из БД на каждый запрос), ACL учитывается даже в кэше ответов.
Ну и главное(шутка:)) — кастомизация страницы входа. Подсказка гуманитарию куда он попал и что делать.

В общем
Я использовал эту систему пару месяцев, ловил и исправлял баги, добавлял функционал и по сути это сейчас готовое решение из коробки. Я выложил проект на Гитхаб.
Берите, пользуйтесь, возможно, через ИИ вы допилите что‑то под себя, а возможно и этот функционал сразу покроет все Ваши потребности. Пишите замечания, баги, предложения, — если проект Вам понравится, доделаем его вместе:)
Как установить и запустить?
git clone https://github.com/Denis-ya-32/prostograf.git
cd prostograf
cp .env.example .env # ключи можно вписать сюда или позже в веб-интерфейсе
docker compose up -d --build # первая сборка ~2-4 мин (дольше при первой загрузке базовых образов)
На самом деле — раз уж я стараюсь подавать всё максимально просто — дайте нейронке ссылку на гит и промпт «Скачай и запусти ПростоГраф», и она справится. Возможно, придётся немного посисадминить: настроить реверс‑прокси наружу, чтобы пользоваться могли люди из разных уголков необъятной, но и с этим она спокойно справится. Статья не о сетевом администрировании.
Дальше
Заходим в WebUI, на страницу авторизации:
http://localhost:9621/webui/#/loginАвторизуемся под admin/admin и нажимаем «Войти».
И всё:) Вы в админке!


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

Идем в «Настройки» > «Провайдеры LLM» и выбираем провайдера, модель и ключ для LLM и эмбеддингов.

3. Опционально можете включить реранкер (рекомендую), но и без него качество Вас может полностью устроить.

4. Размер чанка менять не нужно. Это значение по умолчанию из LightRAG. Если очень хочется, тестируйте. Нажимаем «Сохранить и применить». Сервер быстро (10–30с) перезагрузится.
5. Дальше там же, в настройках идем на вкладку «Тестирование» и кликаем «Проверить провайдеров». Если названия моделей, настройки и ключи правильные, — увидите 200 код.

Основные настройки все. Просто правда?
Дальше идем на вкладку документы и кликаем «Загрузить», ну там уж очень очевидно, не буду останавливаться, после выбора документов у Вас начнется автоматом извлечение сущностей для построения графа и параллельно векторное представление чанков.

Если в процессе будут ошибки, система покажет, повторное нажатие «Сканировать/Повторить», в крайнем случае удаление и повторная загрузка, решают все проблемы. Я пока иного не наблюдал, если что пофиксим, главное, сообщайте о таком:)
Когда документы будут загружены, можем зайти на вкладку «Граф знаний» и помедитировать на цветные кружочки с ребрами.

Ну и после медитации, идем в «Чат» и задаем вопрос, медитируем снова

А теперь к более полезной практике
Задача:
Создать два отдела, — бухгалтерия и техническая поддержка.
Прикрепить юзеров Иванова А.А и Петрова В.В к бухгалтерии.
Прикрепить юзера Герасимов Б.Б к отделу техпод.
Загрузить документы «Глоссарий системы», «Зарплатные ведомости», «Спецификация API» в систему.
Бухгалтерии дать доступ к «Глоссарий системы» и «Зарплатные ведомости». API им не нужен.
Техподу дать доступ к «Глоссарий системы» и «Спецификация API». К зарплатным ведомостям доступ не нужен.
Мы уже знаем как загружать документы. Остается создать отделы, юзеров и настроить доступ к докам.
Идем на вкладку «Отделы и пользователи» и в разделе «Отделы» создаем отдел «BUH» и «TECHPOD», кликаем создать.

2. В разделе «Пользователи» вводим логин «a.ivanova», пароль «12345», имя «Иванова А.А». Выбираем роль «Пользователь» и отдел BUH. Кликаем «Добавить». Увидим уведомление и нового юзера.
То же самое делаем с другими юзерами.

3. Далее идем ниже, к разделу «Доступ отдела к документам». Выбираем отдел и ставим галочки в чек‑боксах рядом с теми документами, которые должны попадать в ретривер для отдела и нажимаем «Сохранить». Тут же, можете указать промпт конкретному отделу, он имеет приоритет перед промптом по умолчанию из вкладки «Настройки» > «Промпты».

4.На вкладке «Документы» есть две важные функциональные возможности

Чек‑бокс «Целиком» — при включении документ попадает целиком в ретривер! Это очень важно, когда инструкция процедурная, где описан поэтапно какой-либо сложный процесс, где цена ошибки велика. Любые ограничения на размер и бюджет токенов в «Настройки» > «Параметры запроса», — игнорируются.
* Этот пункт сделан не просто так, это реальная боль во многих компаниях и это здорово выручает, не нужно свой RAG целиком строить на Child‑Parent паттерне, который достаточно дорогой. Включаем только на процедурку.META — Также важная надстройками поверх промптов. Позволяет корректировать поведение генератора на каких‑то узких/сложных документах. Не меняет текст документа, просто подается как { metainfo: «text» } при успешном ретриве документа/его фрагментов.

Все это Вы можете более подробно почитать в разделе «Документация». Я собрал там Wiki страничку с удобным поиском.

Теперь отправляем URL и доступы Герасимову Б.Б.
Лови!
URL: http://localhost:9621/webui/#/login
Login: b.gerasimov
Password: 12 345
Он заходит и задаёт вопрос, получает ответ и оценивает (на самом деле нужно заставлять оценивать, не все понимают насколько это важно). Видит магию

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

Вернемся в админку, посмотрим, жжёт ли Герасимов токены на выбор фильма
Точнее оценим ответ, посмотрим процесс мышления LLM, скорость ответа, использованные документы, расход токенов, оценку. Всё это можно увидеть на вкладке «История».

Все чаты, в том числе удаленные сохраняются в SQLite, потом на их основе можно собирать реальный eval‑сет, а не синтетику.
Послесловие
Я не AI инженер, скорее обычная шестеренка, у которой была боль, как все организовать для компании численностью чуть более ста человек и огромное желание и интерес к LLM и RAG в частности.
Я постарался максимально простым языком показать как использовать эту систему и сделал её простой для конечных пользователей, — рядовых сотрудников и администраторов.
Мне система нужна именно в таком виде, возможно кому‑то тоже будет полезна. Берите, модифицируйте под себя, благо сейчас это очень просто и быстро. Будет важно получать от вас обратную связь, Issue, личка Хабра. Если есть похожие инструменты, готовые, бесплатные, — делитесь. Я тоже в поисках хорошего:)
Дальнейшие планы
Добавить возможность перенаправлять ответы на других провайдеров LLM, эмбеддингов, реранкера в случае если текущий провайдер «лежит».
Вынести больше настроек из-под капота в WebUI. Да их там море.
Добавить возможность автоматизировано собирать и делать eval таблицу для тестов прям в WebUI. Отслеживать метрики после изменений.
Это глобальные задачи, по мере того как буду находить свободное время, проект собираюсь развивать.
