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
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).