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 разів менша, і результати залишаються на високому рівні. Згідно з README, тест на технічному PDF із 50 частин дає 263 ентитети та 213 атомарних фактів. Питання потім отримують оцінку evidence_coverage=0.6 на основі контексту з лише 4 частин та 10 фактів.

Це свідчить про те, що якість гібридного пошуку, поєднання векторної схожості з онтологічною сіткою, допомагає компенсувати слабкість моделі. Коли контекст обирається так ретельно, навіть проста LLM здатна створювати послідовні та перевірювані відповіді.

CLI замість веб-додатку

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“ за допомогою регулярних виразів, тому не потрібен другий виклик моделі. Це швидше, але менш точно.

Справжній BFS через SQL. Функція graph_context_for починається з початкових ентитетів, взятих з отриманих фрагментів, обходить вузли у ширину, збирає вхідні та вихідні краї та зупиняється при досягненні кількості max_nodes або max_edges. Сховище не є нативною графом, але процес обходу поводиться точно так само, як у графі.

Обережне оброблення схожості. У файлі vector_store.py вектори нормалізуються за формулою L2 перед вставкою та перед кожним запитом. Потім обчислюється косинусова схожість із подвійним резервним варіантом: спочатку використовується квадрат відстані за формулою L2, що є стандартом для Faiss, а якщо результат опиняється поза діапазоном [-1, 1], застосовується формула лінійної нормалізації L2. Тому повернений score завжди є чистим значенням косинуса від 0 до 1, незалежно від того, яку формулу насправді використовує LanceDB. Саме такі деталі відрізняють прототип, який іноді працює, від того, який працює завжди.

Уроки

Перше — це підтвердження. Коли незалежний розробник переimplementує архітектуру з використанням іншого набору інструментів та досягає результатів, ця ідея не є прив’язаною до її початкової реалізації. Це принцип, який можна застосовувати в різних ситуаціях. Шари векторів, онтологій та графів не потребують Qdrant чи Neo4j, і вони так само добре функціонують у LanceDB та SQLite.

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

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

З огляду на TechRAG, переробка ROE, ймовірно, вимагатиме кількох кроків:

• Використовувати абстракцію, сумісну з OpenAI, щоб можна було під’єднати будь-якого постачальника
• Оцінити LanceDB як вбудовану альтернативу Qdrant для зниження бар’єрів під час налаштування
• Зберігати SQLite для зберігання документів у простіших випадках, а Neo4j використовувати лише тоді, коли складність графа це вимагає
• Зберегти веб-інтерфейс для дослідження графів та корекції фактів, що залишається надзвичайно важливим, додавши CLI для автоматизованих виконань

TechRAG — це не кращий показник ROE. Це інший підхід, орієнтований на доступність та швидкість налаштування, і в багатьох ситуаціях саме це є правильним пріоритетом.

Чому це важливо

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