Názory k článku Rozšíření PostgreSQL jménem pgvector, embedding a sémantické vyhledávání (1. část)

MariaDb podporuje vektory nativne (bez nutnosti instalovat extensions) uz od zaciatku roka.

Poměrně dlouho to bylo v release kandidátovi, v ostré verzi 11.8 až od letošního června. Ale funguje to zdá se poměrně dobře.

Dík za info. Budu to muset prozkoumat, jestli tam nejsou nějaká omezení a jaké to používá strategie indexování. Ona se tato oblast hodně vyvíjí a zrovna pgvector nemusí být ideálním řešením.

Hodí se to pro stávající mariadb/mysql aplikace, kde chtějí přidat RAG nad dokumenty/objekty, které mají i další výběrová kritéria - stávající komplexní selecty se jen rozšíří o vektorové kritérium. V našem případě to bylo pomocí WITH/CTE docela jednoduché, vektorové kritérium se celkem snadno zaintegrovalo do stávajícího vyhledávání. Držet vektory mimo hlavní DB by bylo daleko složitější a méně efektivní.

12. 8. 2025, 10:35 editováno autorem komentáře

Skusal som to na vlastnom vyhladavani obrazkov, v databaze som mal cez 50 000 vektorov a na problemy som nenarazil.

jj u nás to jsou spíš miliony, takže se tam ukazují vlastnosti indexů (v podstatě se už u těchto velikostí musí přejít k odhadům a ne přesným výsledkům, více o tom příště)

Nemate zkustenost, proc ruzne backendy vraci ruzne dobre vysledky? Napr. jsme zkusili, ze pgvector vlastne je asi nejlepsi, o chlup horsi byla chromadb a hodne spatne vychazi v default nastaveni opensearch. U pgvectoru je neprijemne omezeni na delku vektoru 2048 (pro fp32 vektory), a treba qwen3-embed-4b model vraci kolem 2500 dlouhe vektory. U chromadb jsem narazil na dost hloupou implementaci pomoci sqlite, ktera behem par mesicu nabobtnala na 25GB a kazdy insert do db ji celou cetl, takze vse trvalo velmi dlouho.

Toto se vyplatí jen když člověk nemá těch vektorů moc a potřebuje opravdu SQL jako filter. Zkoušel jsem to na jeden projekt a prostě to nešlo - když má člověk třeba 100m vektorů tak je potřeba mnohem lepší index a tuning. A když to filtrování není složité tak post-filter taky funguje celkem dobře.

Je to velký trade-off a ty funkce v pgvectoru mi a ni nepřišli nějak optimalizované. Třeba cosine distance a L2 distance může člověk udělat velmi podobně ryché, jen je k tomu potřeba normalizační koeficient těch vektorů (pro oba vektory co se porovnávají se dá předpočítat, a pro ty v DB dokonce uložit jako metadata).

přesně tak, pro tak velké datové sady (100M, ale už klidně u 1M) už je exaktní vyhledávání strašně pomalé a je nutný použít IVFFlat nebo HNSW (nic dalšího pgvector zatím nepodporuje). Nebo jít do FAISS na GPU, když na to má firma peníze (což většinou nemá :-).

Nebo Vamana - to je podle mě top pro opravdu velký dataset. Jen je potřeba následovat tu implementaci od MS a ne to dělat podle toho jejich research paperu, který tam má snad i úmyslné chyby.