pgvector rieši chýbajúce výsledky po filtrovaní. Firemný RAG potrebuje aj pravidlá prístupu
Iteratívne skenovanie môže doplniť kandidátov, ktorých po aplikovaní filtra zostalo málo. PostgreSQL zároveň ponúka samostatnú vrstvu pravidiel na úrovni riadkov; relevancia a oprávnenie riešia odlišné problémy.
Prečo sa päť výsledkov zmení na dva
Pri firemnom vyhľadávaní nestačí nájsť podobné texty. Dotaz často obmedzuje výsledky na projekt, oddelenie alebo zákazníka. Dokumentácia pgvector upozorňuje, že pri približných indexoch sa filter uplatňuje po prehľadaní indexu. Ak vhodní kandidáti neprejdú filtrom, výsledkov môže zostať menej, než požadoval LIMIT.
Od verzie 0.8.0 pgvector dokumentuje iteratívne skenovanie, ktoré podľa potreby prehľadá ďalšiu časť indexu, kým nenájde dostatok výsledkov alebo nedosiahne nastavenú hranicu. Nie je to dnešné oznámenie vydania: ide o existujúci mechanizmus overený v dokumentácii 18. októbra 2026. Pre malý tím je dôležitý v okamihu, keď sa nad spoločným úložiskom začnú uplatňovať firemné filtre.
Relevancia má výpočtový rozpočet
Iteratívny režim nezaručuje neobmedzené hľadanie. Dokumentácia opisuje limity prehľadávania a rozlišuje prísne a uvoľnené poradie výsledkov. Ide teda o kompromis medzi množstvom práce a nájdenými kandidátmi, nie o bezplatné zvýšenie kvality. Pri menšom súbore môže byť užitočný aj obyčajný index na filtrovanej hodnote a presné vyhľadávanie.
Redakčný návrh pilotu je porovnať rovnaké otázky s rovnakým filtrom pred zmenou indexu a po nej. Nestačí sledovať iba rýchlosť: tím potrebuje vedieť, či sa stratili relevantné dokumenty konkrétneho zákazníka. Projekt používa PostgreSQL License. Samotné pgvector však nevytvára firemné oprávnenia ani nepozná význam jednotlivých zákaziek.
Prístup sa rozhoduje osobitne
PostgreSQL dokumentuje Row-Level Security, ktorou možno určiť viditeľnosť alebo zmenu riadkov podľa politík. Keď je táto ochrana zapnutá a neexistuje zodpovedajúca politika, platí predvolené odmietnutie. Dokumentácia zároveň uvádza výnimky: superuser a roly s BYPASSRLS pravidlá obchádzajú; vlastník tabuľky ich obvykle obchádza tiež, pokiaľ sa nevynúti FORCE ROW LEVEL SECURITY.
Pre firemný RAG z toho vyplýva architektonická požiadavka: nestačí napísať do promptu, že používateľ nesmie vidieť cudzie dáta. Treba overiť skutočnú databázovú rolu a politiky ešte pred odovzdaním textu modelu. Iteratívny index pomáha nájsť viac oprávnených kandidátov, ale nie je autorizačným mechanizmom. Článok nepredkladá vlastné meranie výkonu ani audit izolácie; vysvetľuje dve dopĺňajúce sa vrstvy dokumentovaného riešenia.
Repozitár https://github.com/pgvector/pgvector bol overený 18. októbra 2026 na commite f37c13f68b57. GitHub Releases neposkytol samostatné posledné vydanie; článok vychádza zo zachytenej dokumentácie. Opisovaný mechanizmus nie je tvrdením, že vznikol až v tomto vydaní.
Technický kontext
Stav overenia: Spracované podľa zdroja; redakcia postup nereprodukovala.
Verzie: f37c13f68b57
Podmienky použitia: Vlastná aplikácia a konfigurácia komponentov podľa odkazovanej dokumentácie; konkrétny integračný bod vysvetľujú sekcie článku.
Obmedzenia: Rozbor zachytených technických podkladov. Bez vlastného nasadenia, benchmarku alebo merania úspory.