Mój Pierwszy RAG

Mój pierwszy RAG napisałem w 2019 roku (troche może brakowało mu G). Dostałem do wykonania produkt, który działał w taki sposób: wysyłamy zdjęcie jakiegoś ubrania, aplikacja sugeruje 10 najbardziej podobnych produktów i prowadzi do różnych sklepów.

Trzeba było zebrać bazę sklepów, bazę ich produktów, zdjęcia, a następnie przekształcić te zdjęcia na wektory i osadzić w przestrzeni wielowymiarowej.

Architektura Systemu

Ingestia Danych (Facade & Strategy Pattern)

Projekt na początku zakładał użycie Kafki jako systemu kolejkowego, jednak przy użyciu dobrych wzorców projektowych — takich jak fasada i strategia — udało się ujednolicić klasy workerów:

• Worker odpytujący sklepy o zaktualizowane produkty
• Worker przetwarzający zdjęcia na wektory
• Worker aktualizujący przestrzeń wielowymiarową

Aplikacja obsługuje wielu dostawców danych. Każdy sklep posiada własną strategię mapowania pól XML na ustandaryzowany model produktu.

Pipeline Wektoryzacji Zdjęć

Kluczowym elementem systemu RAG było visual embedding. Aplikacja pobierała zdjęcia, skalowała je do formatu 224x224px (RGB) — standardowego rozmiaru wejściowego dla modeli computer vision — a następnie wyciągała zestawy danych do obliczania wektorów podobieństwa (KNN).

Indeksowanie i Baza Danych

Sercem systemu była baza PostgreSQL zarządzana przez SQLAlchemy. Produkty były indeksowane nie tylko po ID, ale również w relacji z kategoriami i płcią, co pozwoliło na hybrydowe wyszukiwanie.

Główne Cechy

• Skalowalność: Dzięki wielowątkowości proces pobierania zdjęć i aktualizacji danych zachodzi równolegle dla wielu sklepów
• Ujednolicony Model Danych: Bez względu na źródło, każdy produkt trafia do bazy w tej samej strukturze
• Automatyzacja: Skrypty monitorujące zmiany i automatyzujące codzienne aktualizacje
• Gotowość na AI: Struktura bazy zaprojektowana pod integrację z Keras czy TensorFlow

Największy Sukces

Udane wyprowadzenie produktu na produkcję. Wszystkie kawałki — od ingestii danych, przez przetwarzanie obrazów, aż po wyszukiwanie wektorowe — działały razem seamlessly.

Co zrobiłbym dziś inaczej

Architektura się broni, komponenty już nie. Trzy rzeczy wyglądałyby inaczej:

• Przechowywanie wektorów. PostgreSQL trzymał produkty, ale podobieństwo liczone było poza nim. Dziś wektory leżą w tej samej bazie dzięki pgvector, a krok KNN staje się zapytaniem, nie osobną usługą.
• Model embeddingowy. Ekstraktor cech CNN na wejściu 224x224 był standardem w 2019 roku. Współczesny model multimodalny daje lepszych sąsiadów i przyjmuje tekst jako zapytanie, czego pierwotny system nie potrafił wcale.
• Kolejka. Rezygnacja z Kafki na rzecz fasady i strategii była słuszna dla trzech typów workerów. Przestaje być słuszna w chwili, gdy ktoś zgłosi wymaganie retry i kolejności przetwarzania.

Reguła, która przetrwała: zbuduj najpierw granicę ingestii i trzymaj każde źródło za jednym modelem produktu. Wybory modeli zestarzały się w trzy lata. Warstwa mapowania nie.

Jeśli zaczynasz dziś coś podobnego, przeczytaj Multimodalny RAG dla zdjęć zamiast kopiować ten projekt.