Лакальны RAG без вектараў: SQLite FTS5 і BM25 для пошуку па кодзе

Пару гадоў рэцэпт лакальнага пошуку па кодзе быў адзін і той жа: нарэзаць рэпазіторый на фрагменты, ператварыць кожны фрагмент у эмбэдынг на 1536 вымярэнняў і трымаць індэкс HNSW жывым у фонавым працэсе. Гэта здавалася сучасным, быццам у ноўтбука з'явіўся маленькі пашукавік, які разумее сэнс кода. Але на загружанай працоўнай станцыі ў гэтага рэцэпта ёсць цана, пра якую рэдка пішуць у README.

Гучныя лічбы вакол лакальнага вектарнага пошуку ўражваюць: высокія ацэнкі пошуку ў MTEB, мільёны токенаў кода, ператвораныя ў эмбэдынгі за хвіліны, «імгненны семантычны інтэлект» на спажывецкім жалезе. Але калі чытаць нататкі пра памяць, а не маркетынг, карціна іншая. Шчыльная вектарная індэксацыя купляе паўнату выдачы цаной прапускной здольнасці памяці, RAM або VRAM і прадказальнасці.

Калі «вектары ўсюды» ўпіраюцца ў сцяну памяці

Запусціце вектарную базу побач з лакальнай LLM, IDE і парай Docker-кантэйнераў, і яна не будзе прастойваць. Яна трымае ў RAM або VRAM вялікія графавыя структуры, змагаецца з іншымі інструментамі за прапускную здольнасць і прыносіць семантычны дрэйф: шукаеце дакладны радок ERR_AUTH_EXPIRED, а атрымліваеце код, які толькі неяк звязаны з аўтэнтыфікацыяй.

Таму шмат каманд ціха вяртаюцца да натыўных алгарытмаў на C, а менавіта да SQLite FTS5 з BM25. Замест вектарнай матэматыкі для лакальных запытаў яны выкарыстоўваюць дэтэрмінаванае ранжыраванне па частаце тэрмінаў і знаходзяць дакладныя ідэнтыфікатары хутчэй чым за 5 мілісекунд.

Супастаўленне паняццяў супраць прадказальнай хуткасці

Гэта не дробная налада. Гэта мяняе тое, як будуюцца інструменты для распрацоўшчыкаў. Замяніўшы лакальныя вектарныя накладныя выдаткі на FTS5, вы адмаўляецеся ад тэарэтычнага супастаўлення па сэнсе дзеля ашчаднага і хуткага выканання.

• Эфектыўнасць: адмова ад шчыльнай індэксацыі вызваляе гігабайты памяці. Праца, якая марнавала каля 200 мс на вылічэнне эмбэдынгаў, натыўна завяршаецца менш чым за 5 мс.
• Дакладнасць: пошук дакладных ключавых слоў і імёнаў функцый, напрыклад getUserById(), цалкам дэтэрмінаваны, таму індэкс не верне целы старонніх функцый.

Два падыходы параўноўваюцца так:

[Dense Vector RAG Flow]
Code Query -> Generate Vector Embeddings -> HNSW Index Search -> Semantic Drift Risk -> LLM Context

[Deterministic BM25 Flow]
Code Query -> Native SQLite C-Index -> Exact Keyword Match (5ms) -> Minimal LLM Context

Сімптомы, якія вы, магчыма, ужо бачылі

Кожны, хто запускае лакальных агентаў або пошук па кодзе, напэўна заўважаў трэнне:

• Канкурэнцыя за рэсурсы. Вентылятар раскручваецца, батарэі хапае на дзве гадзіны, а лакальны інферэнс ледзь паўзе, бо фонавы рухавік адбірае памяць.
• Штраф за дакладнае супадзенне. Пошук канкрэтнага радка памылкі або зменнай вяртае пяць файлаў, блізкіх да аўтэнтыфікацыі па сэнсе, але не той адзіны файл, дзе ёсць патрэбны сцяжок.

Параўнанне побач, з прыблізнымі лічбамі:

Параметр	Лакальная вектарная БД (Chroma, Qdrant)	SQLite FTS5 (BM25)
Спажыванне памяці	Каля 1,5–4 ГБ RAM або VRAM	Каля 15–30 МБ RAM
Затрымка пошуку	120–400 мс, у асноўным на эмбэдынгі	Менш за 5 мс, натыўны C
Дакладнае супадзенне ідэнтыфікатараў	Слабае, схільнае да дрэйфу	Моцнае, дэтэрмінаванае супадзенне па ключавых словах
Сістэмныя накладныя выдаткі	Фонавыя дэманы, прывязкі да C++	У прастоі нічога не працуе
Найлепш падыходзіць для	Шырокага тэматычнага пошуку па тэксце	Дакладных запытаў па кодзе, логах і лакальным RAG

Лічыце гэта арыенціровачнымі лічбамі: вынікі залежаць ад памеру корпуса, выбару мадэлі і жалеза.

Што гэта азначае для тэхлідаў

Рэфлекс падключаць вектарную базу да кожнай лакальнай задачы згасае. Карысней звычка трымаць прапорцыі. Майстэрства старэйшага архітэктара не ў тым, каб уціснуць больш цяжкую ШІ-інфраструктуру ў ноўтбукі распрацоўшчыкаў. Яно ў тым, каб зразумець, калі дзесяць радкоў натыўнага кода або SQLite-файл на 30 МБ лепшыя за нейронны канвеер, які вымяраецца гігабайтамі.

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