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.

Гэта не натыўны граф, хоць ён добра функцыонуе, падтрымляе стандартныя SQL JOIN-ы, і мае прынтэк, якога не можа запрацаваць Neo4j – адсутнае залежнасць ад інфраструктуры. Пошук па шырыні, напісаны чыстым Python, пераходзіць па зв’язках, каб скласав кантэкст, які пасылаецца модэлю. Для пратотыпаў і дакументаў сяродніх размераў граф на SQLite ўсё аблікова.

Знaczна меньшы модэль

Разлік у размерах модэляў вялік. 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, нацэлёваны на канцэнтр пункт Ollama /v1, таму ідэнтычны код працюе з 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. Такія дэталі разлічваюць протатып, які іноды працуе, ад таго, які працуе ўсега часу.

Урокі

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

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

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

У разы пры выкарыстоўванні TechRAG, перадзеяванне ROE, верагодна, будзе выконвалася па калькі крокаў:

• Ўжыць абстракцыю, сумесную з OpenAI, каб можна было падключыць будзь-каго прадаўца
• Ацэніць LanceDB як альтэратыўную сістэму заместо Qdrant, каб знізіць труднасці падключэння
• Для простыях случаў застаўляць SQLite для зберагання дакументаў, а Neo4j — толькі тады, калі складнасць графа гэта правяжае
• Заставіць веб-інтэрфейс для аналізу графа і корэкцыі фактов, які застаецца неабходным, а таксама дадаць CLI для автаматызаваных запускаў

TechRAG – гэта не лепшы ROE. Гэта іншы варыянт, які спрамованы на простатацію і шырокаспектнае налаштаванне, і ў многіх сцэнарыях гэта ўсё-такі правільны прыорытэт.

Чаму гэта важна

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