Wskazówki praktyczne: Budowa systemu wyszukiwania obrazów z wykorzystaniem nowoczesnych usług sztucznej inteligencji

Poniższe notatki przedstawiają praktyczny plan działania w ramach tematu „Budowa systemu wyszukiwania obrazów wykorzystującego nowoczesne usługi AI”. Nacisk kładziony jest na umowy, sprawdzenia oraz miejsca na kod do wstawienia, a nie na motywacyjne aspekty. Podczas przechodzenia przez etap przeglądu, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Wolno preferować małe, testowalne jednostki zamiast rozbudowanych skryptów. Gdy jakiś krok się nie powiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowany proces.

Przegląd architektury systemu

Etap przeglądu architektury systemu działa najlepiej, gdy traktuje się go jako mierzalną powierzchnię do analizy. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres pracy. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzuć przypadki częściowego ukończenia pracy bez informacji. Rozdziel politykę dzielenia na fragmenty od polityki pobierania danych. Zmiana jednej z nich nie powinna zmuszać do przepisywania drugiej, gdy zmieniają się metryki jakości.

Dwukrotne wplecenie danych

Metoda Dual Embedding Approach działa najlepiej, gdy traktuje się ją jako mierzalną powierzchnię. Zapisz jeden idealny przepis, jeden przypadek awarii oraz notatkę o cofnięciu zmian, zanim rozszerzysz zakres pracy. Zarejestruj czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy przechodzi się z środowiska demonstracyjnego do współdzielonych środowisk. Oddziel zasadę dzielenia na fragmenty od zasady wyszukiwania. Zmiana jednej nie powinna zmuszać do przepisywania drugiej, gdy zmieniają się metryki jakości.

Rozpoznawanie obiektów za pomocą YOLO

Faza wykrywania obiektów za pomocą YOLO działa najlepiej, gdy jest traktowana jako mierzalna powierzchnia. Zapisz jeden idealny przykład działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian przed rozszerzaniem zakresu. Przechowuj konfigurację poza kodem aplikacji. Pliki środowiskowe, składysek tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Oddziel zasadę dzielenia na fragmenty od zasady wyszukiwania. Zmiana jednej z nich nie powinna zmuszać do przepisywania drugiej w przypadku zmian wskaźników jakości. Faza wykrywania obiektów za pomocą YOLO działa najlepiej, gdy jest traktowana jako mierzalna powierzchnia. Zapisz jeden idealny przykład działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian przed rozszerzaniem zakresu. Wolij małe, testowalne jednostki nad rozbudowane skrypty. Gdy jakiś krok zawiedzie, awaria powinna wskazywać na konkretną odpowiedzialność, a nie na skomplikowaną sekwencję operacji.

Rozpoznawanie i klasyfikacja entytetów

W etapie rozpoznawania i klasyfikacji entytetów należy zdefiniować dane wejściowe, osobę odpowiedzialną za ten krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nazwij poszczególne elementy, zdefiniuj kryteria sukcesu i odrzuć ciche, częściowe ukończenie zadania. Podaj fragmenty tekstu, które faktycznie stanowią podstawę odpowiedzi. Bez tych odniesień operatorzy nie będą w stanie odróżnić halucynacji od luki w indeksowaniu.

Example Transformation:

YOLO: "person" (coordinates: [120, 45, 220, 320])
Web Extraction: "Elon Musk" (confidence: 0.96)

YOLO: "building" (coordinates: [50, 100, 400, 600])
Web Extraction: "Eiffel Tower" (confidence: 0.92)

Rozpoznawanie atrybutów za pomocą Google Vision API

W fazie wykrywania atrybutów za pomocą Google należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy rejestrować czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy ścieżka przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Należy podawać fragmenty tekstu, które faktycznie stanowiły podstawę odpowiedzi. Bez tych odniesień operatorzy nie mogą odróżnić halucynacji od luki w indeksowaniu.

wzbogacanie metadanych za pomocą Gemini

W fazie wzbogacania metadanych za pomocą Gemini należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Konfigurację należy przechowywać poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Należy oddzielić budowę klienta od pętli przekazywania wiadomości, aby można było wymieniać dostawców bez konieczności przepisywania maszyny stanu rozmowy. W fazie wzbogacania metadanych za pomocą Gemini należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy preferować małe, testowalne jednostki nad rozbudowanymi skryptami. Gdy dany krok zawiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na całą strukturę.

w skomplikowanej łańcuchowej strukturze.

System: You are an expert image analyzer. Extract the following attributes from the image, with a confidence score (0-1):

1. sensitivity (none, low, medium, high)
2. emotion (neutral, joy, sadness, surprise, etc.)
3. emotion_triggered (yes/no)
4. text_overlay (yes/no)
5. has_frames (yes/no)
6. has_religious_symbols (yes/no)
7. has_scattered_objects (yes/no)
8. style (photographic, illustrated, cartoon, abstract, etc.)
9. has_crowd (yes/no)
...
[full list of 25 attributes]

Response format: JSON object with attributes as keys and values as described above.

Tworzenie wzbogaconych opisów obrazów

Podczas prace nad etapem tworzenia wzbogaconych opisów obrazów najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzuć ciche, częściowe ukończenie zadania. Zmierz stopień odzwierciedlenia informacji na ustalonej grupie pytań przed dostosowywaniem promptów. Częste zmiany promptów rzadko naprawiają słabe możliwości wyszukiwania.

Generate a comprehensive, search-optimized description for this image based on the following data:

[Entity data from object detection and recognition]
[Label data from Vision API]
[Structured metadata from previous Gemini analysis]

Your description should:
1. Begin with the most significant entities and their actions/relationships
2. Include key visual attributes (colors, style, composition)
3. Mention emotional tone and aesthetic qualities
4. Incorporate likely search terms
5. Be 3-5 sentences in length

Objects: person (0.98), guitar (0.95), microphone (0.92)
Entities: Taylor Swift (0.97)
Labels: concert, performance, stage, entertainment
Metadata: emotion=joy, has_crowd=yes, style=photographic, dominant_color=purple

Taylor Swift performs energetically on stage with an acoustic guitar during a concert, singing into a microphone with passionate expression. The image captures the excitement of a live performance with purple stage lighting creating a vibrant atmosphere. This high-quality photograph conveys feelings of joy and excitement, with Swift's iconic performance style clearly visible. The composition includes partial views of an enthusiastic crowd in the foreground, making this suitable for music, entertainment, and celebrity content.

Przepływ przetwarzania zapytań

Gdy przechodzisz przez etap przetwarzania zapytań, najpierw zapisz specyfikację: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Obok wyników funkcjonalnych zapisz czas wykonywania oraz koszt tokena lub zapytania. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy przechodzi się z środowiska demonstracyjnego do współdzielonych środowisk. Zmierz stopień odzyskiwania informacji na ustalonej serii pytań przed dostosowywaniem promptów. Częste zmiany promptów rzadko poprawiają słabe możliwości wyszukiwania.

Wyzwania w implementacji i rozwiązania

Gdy przechodzisz przez etap wyzwań implementacyjnych i rozwiązań, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Trzymaj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Zmierz stopień odzyskiwania informacji na ustalonej serii pytań przed dostosowywaniem promptów. Częste zmiany promptów rzadko naprawiają słabe mechanizmy wyszukiwania. Gdy przechodzisz przez etap wyzwań implementacyjnych i rozwiązań, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Wolij małe, testowalne jednostki nad rozbudowane skrypty. Gdy jakiś krok się nie powiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowaną sekwencję operacji.

Wpływ na biznes i zwrot z inwestycji

Etap analizy wpływu na biznes i zwrotu z inwestycji działa najlepiej, gdy traktowany jest jako mierzalna struktura. Zapisz jeden idealny przepis postępowania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres pracy. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań. Rozdziel politykę dzielenia na części od polityki pobierania danych. Zmiana jednej z nich nie powinna zmuszać do przepisywania drugiej, gdy zmieniają się metryki jakości.

Budujące na przyszłość kierunki

Etap „Kierunki rozwoju” funkcjonuje najlepiej, gdy traktowany jest jako mierzalna powierzchnia do analizy. Zapisz jeden udany przypadek, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres pracy. Zapisuj czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy proces przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Oddziel zasadę dzielenia na fragmenty od zasady wyszukiwania. Zmiana jednej z nich nie powinna zmuszać do przepisywania drugiej, gdy zmieniają się metryki jakości.

Listwa kontrolna operacyjna

Dla etapu listwy kontrolnej operacyjnej zdefiniuj dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia pracy przed zmianą kodu. Operatorzy powinni móc ponownie wykonać dany krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu systemu.

Zdokumentuj zarówno „szczęśliwą ścieżkę”, jak i ścieżkę naprawczą. Próby ponownych działań, kontrolne punkty ludzkie oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później.

Należy podać fragmenty tekstu, które faktycznie stanowią podstawę odpowiedzi. Bez odniesień operatorzy nie będą w stanie odróżnić halucynacji od luki w indeksowaniu.

Napisz krótki przewodnik: jak rotować klucze, jak opróżnić kolejkę, jak cofnąć ostatnie zadanie.

Należy preferować małe, testowalne jednostki zamiast rozbudowanych skryptów. Gdy jakiś krok zawiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowany proces.

Należy podać fragmenty tekstu, które faktycznie stanowią podstawę odpowiedzi. Bez odniesień operatorzy nie będą w stanie odróżnić halucynacji od luki w indeksowaniu.

Zanim zastosuje się nową wersję, należy zamrozić istniejące wersje, zapisać idealny zapis dla kluczowych etapów oraz potwierdzić kroki cofania. Środowiska współdzielone wymagają ograniczeń szybkości, weryfikacji dostępności oraz wyraźnego właściciela odpowiedzialnego za rotację haseł. Lepiej mała niezawodność niż pomysłowe, jednorazowe demonstracje.

Uwagi dotyczące pliku 1d37f7063a2b: unikaj przechowywania kluczy dostawcy w repozytorium, ustaw ograniczenie liczby tokenów na sesję oraz przechowuj transkrypcje obok plików testowych, aby późniejsze zmiany modeli pozostały porównywalne.

Literatura pokrewna

• Praktyczne notatki: Nauczyłem się RAG budując system Q&A — Szczegółowy przewodnik po Praktycznych notatkach: Nauczyłem się RAG budując system Q&A: umowy, sprawdzenia oraz gotowe elementy kodu dla zespołów wdrażających ten wzorzec.

Notatki praktyczne: Lekcje, których nauczyliśmy się podczas tworzenia asystenta RAG bez oddzielnego komponentu — Szczegółowy przewodnik po Notatkach praktycznych: Lekcje, których nauczyliśmy się podczas tworzenia asystenta RAG bez oddzielnego komponentu: umowy, sprawdzenia oraz miejsca na kod do wstawienia dla zespołów wdrażających ten wzorzec.