Dlaczego Twio wybrało Vertex AI Search zamiast pgvector
Nasz pierwszy system RAG w Twio zbudowaliśmy przy użyciu pgvector. Był to szybki wybór. Nasze dane znajdowały się w PostgreSQL. Dodawanie tam embeddingów było proste.
W miarę skalowania nasz problem uległ zmianie. Nie pytaliśmy już o to, jak przechowywać wektory. Pytaliśmy, jak zrozumieć tysiące nieuporządkowanych dokumentów brokerskich, e-maili i załączników.
Twio obsługuje brokerów kredytowych. Pojedyncza sprawa zawiera: • Wątki e-mailowe • Paski wypłat i wyciągi bankowe • Formularze kredytowe i zasady pożyczkodawców • Odręczne notatki
AI musi odpowiadać na pytania takie jak: • Który e-mail wspominał o brakującym wymogu? • Czy ten wyciąg bankowy potwierdza dochód? • Podsumuj wszystkie dokumenty dla tego pożyczkobiorcy.
Jeśli proces retrieval jest słaby, odpowiedź również będzie słaba. Jeśli parsing jest błędny, model widzi niewłaściwe dowody. RAG to pamięć naszego produktu.
pgvector sprawdzał się dobrze w naszej pierwszej wersji, ponieważ: • Nie wymagał nowej infrastruktury. • Generował niskie koszty. • Pozwalał na łatwe debugowanie SQL. • Pozwalał na szybkie wdrożenie.
Ale pgvector to tylko jedna część potoku (pipeline) RAG. Resztę zostawił nam: • Pobieranie załączników. • Wyodrębnianie tekstu z plików PDF i skanów za pomocą OCR. • Dzielenie dokumentów na fragmenty (chunking) i generowanie embeddingów. • Projektowanie metadanych i zapytań retrieval. • Dostrajanie indeksów i rankingu. • Monitorowanie obciążenia bazy danych.
Czysty plik PDF jest łatwy. Skan wyciągu bankowego jest trudny. E-mail z pięcioma załącznikami i tabelami jest jeszcze trudniejszy. Korzystając z pgvector, musieliśmy naprawiać każdą słabość w tym potoku.
Koszt przesunął się z rachunku za chmurę na czas pracy naszych inżynierów. Czas inżynierski był naszym najbardziej ograniczonym zasobem.
Porównanie: • Skanowane dokumenty: Budujemy OCR z pgvector. Vertex obsługuje większość przetwarzania dokumentów. • Pytania dotyczące dokumentów: Projektujemy zapytania i ranking z pgvector. Vertex zapewnia zarządzaną wyszukiwarkę (managed search). • Nagłe przyrosty załączników: Postgres dźwiga obciążenie z pgvector. Vertex utrzymuje obciążenie poza naszą główną bazą danych. • Koszt: pgvector ma niższe koszty usługi. Vertex ma niższe koszty inżynieryjne i utrzymania.
pgvector jest tańszy jako rozszerzenie bazy danych. Vertex jest tańszy jako decyzja produktowa.
Vertex pomaga nam na cztery sposoby: • Mniej infrastruktury do zarządzania. • Mniej logiki przetwarzania dokumentów do utrzymania. • Postgres pozostaje skoncentrowany na transakcjach biznesowych. • Skaluje się wraz ze wzrostem wolumenu naszych dokumentów.
Vertex nie jest darmowy. Ale budowanie własnego OCR, indeksowania i rankingu również generuje koszty. Płacimy ten koszt w tygodniach pracy inżynierów.
Użyj pgvector, jeśli: • Wolumen Twoich danych jest umiarkowany. • Twoje dokumenty to już czysty tekst. • Potrzebujesz ścisłego filtrowania SQL. • Chcesz szybko stworzyć pierwszą, niskokosztową wersję.
Nasza lekcja jest prosta: Zacznij od narzędzia, które pozwala Ci najszybciej się uczyć. Przejdź do narzędzia, które pozwala Ci najlepiej operować.
Source: https://dev.to/twio_ai/why-twio-chose-vertex-ai-search-over-pgvector-for-production-rag-51jm
Optional learning community: https://t.me/GyaanSetuAi