Názory k článku pgvector, embedding a sémantické vyhledávání: sofistikovanější indexy a různé typy vektorů

Při nasazování je dobré si dát pozor nejenom na počet dimenzí, ale i na celkovou velikost jednoho záznamu. Nesmí překročit jeden blok (ten je někde v PG zadrátován), takže například při hybridním vyhledávání (vedle vektoru musí být uložen i text), nebo pokud se do tabulky ukládají i tagy, skóre apod. to už může být na limitu. Hlavně když se použije float32 (ale to zase není tak často).

Autor článku: docela bojujeme s tím, jakou implementaci RAG použít. pgvector a Faiss fungují, ale mají každá své problémy (imho je pgvector mnohem lepší, hlavně na hybrid search). Na scéně je Milvus, ale popravdě už je trošku unavující každých pár měsíců měnit technologie. Co se osvědčilo nebo naopak neosvědčilo ostatním?

Teď se toho rojí hodně (jako další mě napadá třeba Qdrant). Z tohoto hlediska se jako produkční scénář jeví zůstat u pgvector (protože stabilita API) a počkat, kdo přežije test časem :)

Díky. Qdrant mám taky v hledáčku, ale tato oblast je už jak svět JS frameworků - každý týden něco nového. Ten pgvector je fajn mj.i proto, že se kromě jedné knihovny může používat produkční DB a je to (zatím) hodně stabilní.

Pro Open WebUI mame opensearch, funguje dobre.

Tohle je docela ostrej clanek "proti".
https://alex-jacobs.com/posts/the-case-against-pgvector/

Osobne jsem PgVector s halfvec do produkce pustil. Mensim problemem ovsem je, ze frameworky jako Langchain a podobne s tim nativne nepocitaji a tak je clovek musi vselijak ohybat.

Dobře napsanej článek. Tedy až na ten konec, kde se trošku slepě porovnává pgvector s "obecnou" vektorovou databází. Ale je vidět, že si autor už prošel reálným nasazením, to je fajn.

My teď řešíme problém s častými updaty DB, využitím dalších klíčů a hybridním vyhledáváním, kde se právě uplatňují indexy atd. (a navíc odpadají tradiční vektorové databáze typu FAISS - ty je nutné s něčím zkombinovat, a vlastně si nejsem jistej, jestli to FAISS plně zvládá).