ROE против TechRAG: GraphRAG на Docker с Qdrant или на SQLite с LanceDB.

Видеть, как кто-то другой с использованием иных инструментов самостоятельно реализует ту же архитектуру, — это полезный способ проверить, действительно ли при проектировании имелись в виду именно эти инструменты. Таков случай с RAGraph Ontological Engine (ROE) — локальной реализацией GraphRAG — и TechRAG, проектом с открытым исходным кодом под лицензией MIT, который принимает его основные идеи, но меняет почти все аспекты инфраструктуры. Сравнение этих двух решений показывает, какие идеи были сохранены, а какие переосмыслены.

Общая тезисная основа

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

1. Векторный поиск через Qdrant с использованием вкладок bge-m3, генерируемых локально с помощью Ollama
2. Словарь понятий (онтология домена), сформированный на основе примеров, расположенных по всему документу
3. Граф знаний, состоящий из узлов, рёбер и атомарных фактов, каждый из которых указывает на своё исходное источник

Цель довольно скромна: не нужно загружать в запрос полное руководство. Вместо этого модель получает небольшой набор данных — несколько фрагментов текста, некоторые атомарные факты и несколько путей в графе. Это снижает количество лишней информации, обеспечивает более чёткий контекст и позволяет читателю проверять ответы. Исходная версия ROE работала в Docker (Qdrant плюс MongoDB) и предоставляла веб-интерфейс с чатом на основе онтологии и визуализацией графа, а также систему аудита для отчётности по показателям охвата и оценкам логики.

TechRAG сохраняет эту концепцию и принимает решения, которые практически полностью соответствуют ей.

Хранение: от двух сервисов к одному файлу

ROE хранит векторы в Qdrant, а всё остальное (документы, онтологию, записи аудита) — в MongoDB. Это означает необходимость в двух внешних сервисах, Docker и открытых портах. TechRAG не требует внешней инфраструктуры. LanceDB, встроенная безусловно-серверная база данных векторов, записывает данные непосредственно в файловую систему, а SQLite через SQLAlchemy хранит остальное: документы, фрагменты, сущности, атомарные факты, семантические пути и сериализованную онтологию — всё это находится в одном файле roe.db.

Первая структура выглядит следующим образом:

# ROE (original)
Qdrant (vectors) + MongoDB (docs/ontology/audit)
→ Docker, ports 6333 and 27017

А вот как выглядит TechRAG:

# TechRAG
LanceDB (vectors) + SQLite (everything else)
→ Zero external services, one .db file

Подход к настройке полностью отличается. ROE требует Docker с запущенными обоими контейнерами, тогда как TechRAG работает просто с командой uv run roe ingest document.pdf. Один подход подходит для контролируемой среды, а другой функционирует практически где угодно, даже на ноутбуке разработчика.

Граф в виде реляционных таблиц

ROE планировал использовать Neo4j для своего графа, а в качестве более легкого варианта для хранения документов — MongoDB. TechRAG использует что-то другое — SQLGraph. Узлы и рёбра преобразуются в реляционные таблицы в SQLAlchemy, при этом не требуется использование графовой базы данных. Таблица entities хранит узлы с именем, онтологическим типом и описанием. Таблица facts хранит рёбра с полями subject_id, predicate, object_id, source_text и confidence.

Это не нативная графовая структура, однако она функционирует хорошо, поддерживает обычные операции JOIN в SQL и имеет преимущество, которого не может дать Neo4j: отсутствие зависимости от инфраструктуры. Поиск в ширину, написанный на чистом Python, проанализирует связи между элементами, чтобы собрать контекст, передаваемый в модель. Для прототипов и документов умеренного размера графовая структура на SQLite более чем достаточна.

Значительно меньшая модель

Разница в размере моделей велика. ROE использует модель gpt-oss:120b-cloud с 120 миллиардами параметров, тогда как TechRAG обходится моделью qwen2.5:7b, которая примерно в 17 раз меньше, но результаты остаются на высоком уровне. Согласно документации, тест на техническом PDF из 50 фрагментов показал 263 сущности и 213 атомарных фактов. При этом при использовании всего 4 фрагментов и 10 фактов показатель evidence_coverage составляет 0,6.

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

Командная строка вместо веб-приложения

ROE поставляется в виде веб-приложения: чат, графический вид, инструмент Facts Composer для редактирования фактов и лог прошлых запросов. TechRAG предназначен исключительно для работы из командной строки:

uv run roe ingest manual.pdf
uv run roe query "Which procedure reduces the risk associated with alarm A1?"
uv run roe stats

Нет графического интерфейса и визуального отображения графа — только терминал. Тем не менее функция query выводит полный JSON-документ с ответом и связанными данными аудита: использованные фрагменты, факты, узлы, рёбра, пути, evidence_coverage, reasoning_score и recovered. Удобство пользователя заменяется простотой использования в автоматизированных пайплайнах.

Что осталось прежним

Несмотря на архитектурные различия, основной алгоритм строго следует первоначальной спецификации. Обе системы выполняют один и тот же алгоритм: парсинг документов (PDF с помощью pypdf, Markdown или обычный текст), разделение на фрагменты по 1000 символов с перекрытием в 200 символов, встраивание их с использованием bge-m3 на конечной точке Ollama, формирование онтологии на основе распределенной выборки фрагментов и извлечение атомарных фактов для каждого фрагмента с обратной ссылкой на источник. Формулировки запросов на извлечение отличаются по стилю, поскольку запросы TechRAG написаны на немецком языке, но суть одинакова: модель должна возвращать JSON-тройки в формате субъект, предикат, объект и источник.

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

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

Логика восстановления также совместная. Если лучший фрагмент получает оценку ниже 0,45, ни одна из систем не увеличивает контекст произвольно. Обе переписывают запрос: TechRAG делает это с помощью специального промпта, в котором просит модель сгенерировать два альтернативных запроса с использованием разной терминологии, после чего пытается снова получить информацию. Если доля покрытия доказательствами падает ниже 40%, обе системы предпринимают вторую попытку с более обширным контекстом; TechRAG реализует это с помощью параметра max_recovery_rounds=1.

Варианты, выходящие за рамки первоначального дизайна

Некоторые решения TechRAG выходят за пределы установленных спецификаций.

Клиент, не зависящий от поставщика. Вместо встроенного API Ollama он использует openai.OpenAI, ориентированный на конечную точку /v1 Ollama, поэтому одинаковый код может работать с Ollama, OpenAI, vLLM или любой другой конечной точкой, совместимой с OpenAI:

# TechRAG clients.py
self._client = OpenAI(api_key=self.api_key, base_url=self.base_url)
resp = self._client.chat.completions.create(model=self.model, ...)

ROE связан с Ollama, в то время как TechRAG — нет. Это тонкое отличие, имеющее реальные последствия: позже переход на GPT-4o не требует изменений в коде.

Современная структура пакета. TechRAG — это настоящий Python-пакет с файлом pyproject.toml, управляемый инструментом uv, менеджером пакетов Astral, который работает гораздо быстрее, чем pip. Чистая структура пакета roe/, CLI-интерфейс в файле __main__.py и четко указанные зависимости обеспечивают воспроизводимость, поскольку для синхронизации достаточно лишь команды uv sync.

Более низкий балл рассуждений. ROE формирует свой балл рассуждений на основе классификации утверждений (Подтверждено, Противоречит, Не подтверждается), выполняемой моделью. TechRAG делает то же самое, но добавляет гистеретический метод: он с помощью регулярных выражений сопоставляет в ответе слова «verified»/«verifiziert», «contradicted»/«widerspr» и «unsupported»/«nicht belegbar», поэтому не требуется второй вызов модели. Это делает процесс быстрее, но менее точным.

Настоящий обход в ширину через SQL. Функция graph_context_for начинает с исходных элементов, взятых из полученных фрагментов, обходит узлы в ширину, собирает входящие и исходящие рёбра и останавливается при достижении количества max_nodes или max_edges. Хранилище не является нативной графом, но процесс обхода ведётся точно так же, как в графе.

Аккуратная обработка сходства. В файле vector_store.py векторы нормализуются по стандарту L2 перед вставкой и перед каждым запросом. Затем вычисляется косинусное сходство с двойным резервным вариантом: сначала используется квадрат расстояния по стандарту L2, что является значением по умолчанию в Faiss, и если результат выходит за диапазон [-1, 1], применяется формула линейного L2. Следовательно, возвращаемое значение score всегда представляет собой чистое косинусное сходство в диапазоне от 0 до 1, независимо от того, какой алгоритм используется внутри LanceDB. Именно такие детали отличают прототип, который работает иногда, от того, который работает всегда.

Уроки

Первый аспект — это подтверждение. Когда независимый разработчик переосуществляет архитектуру с использованием другого набора инструментов и получает работающие результаты, это означает, что идея не связана с её первоначальной реализацией. Это принцип, который можно применять в других ситуациях. Слои векторов, онтологий и графов не требуют использования Qdrant или Neo4j; они так же хорошо функционируют в LanceDB и SQLite.

Второй аспект — это простота. Для ROE требуются Docker, Qdrant, MongoDB и веб-приложение, тогда как для TechRAG достаточно LanceDB, SQLite и CLI. Для прототипов, демонстрации концепции и интеграции с CI/CD второй подход объективно лучше, и это сравнение служит напоминанием о том, насколько часто разработчики создают чрезмерно сложную инфраструктуру, которая не требуется для решения поставленной задачи.

Третий аспект касается самой модели. Модель размером 7 миллиардов параметров, демонстрирующая результаты, сопоставимые с результатами модели в 120 миллиардов параметров при наличии хорошо структурированного контекста, показывает, что качество извлечения информации в GraphRAG имеет не меньшее значение, чем размер модели, а возможно, и большее. Тщательно подобранный контекст, состоящий из нескольких фрагментов, релевантных фактов и путей в графе, позволяет небольшой LLM точно рассуждать, в то время как шумный контекст сбивает с толку даже самую мощную модель.

Учитывая TechRAG, переработка ROE, вероятно, потребует нескольких шагов:

• Использовать абстракцию, совместимую с OpenAI, чтобы можно было подключить любого поставщика
• Оценить LanceDB в качестве встроенной замены Qdrant для снижения барьеров при настройке
• Для более простых случаев сохранять SQLite для хранения документов, а использовать Neo4j только тогда, когда сложность графа этого требует
• Сохранить веб-интерфейс для исследования графа и коррекции фактов, что остается крайне важным, добавив к нему CLI для автоматизированных операций

TechRAG — это не просто более эффективный ROE. Это совершенно иной подход, ориентированный на доступность и скорость настройки, и во многих ситуациях именно это является правильным приоритетом.

Почему это важно

Оба проекта приводят к одному и тому же выводу: следует сохранять онтологию, граф знаний и векторный поиск раздельно, извлекать атомарные факты с ссылками на источники, ограничивать контекст несколькими тщательно выбранными элементами и проверять ответы с помощью метрик покрытия. Они также показывают, что один и тот же результат может быть достигнут с использованием совершенно разных технологий, и что более простой вариант — LanceDB вместо Qdrant, SQLite вместо MongoDB и qwen2.5 вместо модели объемом 120 млрд параметров — часто является наилучшим стартовым вариантом.