Spring AI w przedsiębiorstwie: Agent obsługi klienta z narzędziami, RAG i mechanizmem przeglądania
Spring AI jako asystent do triażu incydentów: prompty jako umowy, ustrukturyzowany wynik, wywoływanie narzędzi, odkrywanie MCP, Qdrant RAG, śledzenie oraz ograniczone pętle agentów.
Źródła: Leveraging Spring AI for building the next generation of enterprise applications
Ticket obsługi klienta jako przypadek testowy
Wewnętrzne warsztaty z zakresu inżynierii AI dla programistów w firmie zajmującej się technologiami finansowymi powstały na podstawie scenariusza, z którym niemal każdy programista mierzy się prędzej czy później. Nadchodzi ticket obsługi klienta. Zapisy z logów zawierają jedynie częściowe dowody. Istotny kod znajduje się w wewnętrznym repozytorium. Osoba pełniąca dyżur potrzebuje skupionej pierwszej analizy, a nie ogólnej odpowiedzi.
Spring AI nadaje się do takich zadań, ponieważ wprowadza funkcje AI do ekosystemu, w którym programiści Java i Spring już codziennie pracują. Oferuje abstrakcje dla modeli, promptów, strukturyzowanych wyników, wywoływania narzędzi i ich pobierania, które bez większych trudności pasują do istniejącej architektury aplikacji.
Wywoływanie LLM z aplikacji Java nie jest najciekawszą częścią. Ważne jest to, by robić to przy zachowaniu dyscypliny oczekiwanej w środowisku fintech: wyraźnych umów, narzędzi z minimalnymi uprawnieniami, możliwości śledzenia oraz ludzkiej weryfikacji tam, gdzie decyzja ma znaczenie.
Dlatego zakres tego tematu wykracza poza sam warsztat. Projekt „Agent Wsparcia” służy jako przykład pokazujący, jak połączyć AI z istniejącymi systemami, gdzie model powinien znaleźć się w architekturze, jak może on dostarczyć korzyści przedsiębiorstwu i dostęp do danych, oraz jak otaczające go systemy zapewniają, by jego zachowanie było przydatne, przewidywalne i pod kontrolą.
Problem integracji, a nie problem modelu
Wdrożenie sztucznej inteligencji w systemy korporacyjne to przede wszystkim prace integracyjne i ma niewiele wspólnego z wyborem modelu. Zespoły zazwyczaj odkrywają to dopiero po stworzeniu pierwszego prototypu. Wysłanie zapytania do modelu jest proste, a wyniki mogą wyglądać imponująco. Gdy jednak sztuczna inteligencja trafia do systemu produkcyjnego, pojawiają się podstawowe problemy.
Oprogramowanie korporacyjne jest budowane wokół determinizmu. Opiera się na ścisłych umowach, przewidywalnej opóźnieniu i dobrze zdefiniowanym przepływie danych. Określony wprowadzony danych powinien dawać spójny wynik, a zachowanie można prześledzić w kodzie.
Systemy oparte na sztucznej inteligencji działają inaczej. Są z natury probabilistyczne, często przyjmują język naturalny zamiast strukturyzowanych danych i polegają na zewnętrznych dostawcach. To samo zapytanie może przynieść różne odpowiedzi, a część logiki znajduje się wewnątrz modelu, poza kontrolą systemu.
Rezultatem jest niezgodność strukturalna: komponent niedeterministyczny znajdujący się wewnątrz architektury deterministycznej. Znane założenia dotyczące testowania, monitorowania i niezawodności przestają być aktualne. Trudne nie jest tworzenie sprytnych odpowiedzi, lecz dopasowanie ich do systemów, które wymagają kontroli.
Spring AI reaguje, traktując sztuczną inteligencję jako kolejny element integracyjny w ekosystemie Spring, a nie jako przypadek specjalny. Spring już abstrahuje bazy danych, komunikację i wywołania REST, a Spring AI dodaje porównywalne abstrakcje dla modeli językowych, magazynów wektorowych oraz procesów roboczych napędzanych sztuczną inteligencją. Celem nie jest całkowite ukrycie złożoności, lecz jej uporządkowanie tak, by pasowała do istniejących wzorców architektonicznych.
W typowej konfiguracji sztuczna inteligencja nie znajduje się w oddzielnym serwisie – jest wbudowana jako kod integracyjny w warstwie aplikacji.
Logika projektu działa w następujący sposób: przychodzi żądanie, a prośby biznesowe są odrzucane. Prawdziwe incydenty otrzymują ticket. Narzędzie Spring AI sprawdza logi, a diagnoza jest przekształcana w rekord w Javie. Istotny kod źródłowy jest pobierany z magazynu wektorowego opartego na Qdrant, generowana jest sugestia naprawy, a ticket jest aktualizowany, aby osoba mogła go przejrzeć.
Dla programisty AI staje się kolejną zależnością, a aplikacja zachowuje kontrolę nad procesem pracy. Modele są konfigurowane jak każda inna część infrastruktury, a interakcje odbywają się przez dobrze zdefiniowane API zamiast ad-hoc wywołań HTTP.
W projekcie SupportAgentController otrzymuje przychodzącą prośbę w formie SupportTicketRequest. Przekazuje rozumowanie AI do SupportAnalysisService, zapisuje stan za pomocą SupportTicketService, pobiera kod źródłowy przez GithubRagService oraz przechowuje wygenerowane rozwiązanie w bilecie.
Godnym uwagi efektem ubocznym jest to, że logika biznesowa pozostaje niezależna od dostawcy modeli. Zmiana dostawców lub dodawanie alternatyw nie wpływa na sam kod podstawowy. W dłuższej perspektywie chodzi tu raczej o utrzymanie kontroli architektonicznej niż o elastyczność. Jeśli model jest niedostępny, poniższy punkt końcowy powinien nadal utworzyć bilet, oznaczyć analizę AI jako niedostępną i przesłać sprawę do kolejki dla ludzi.
@PostMapping("/requests")
public ResponseEntity<?> submitSupportRequest(@Valid @RequestBody SupportTicketRequest request) {
boolean isBusiness = supportAnalysisService.isItBusinessRequest(request);
if (isBusiness) {
return ResponseEntity.status(HttpStatus.BAD_REQUEST)
.body(ErrorResponse.businessRequest());
}
SupportTicket ticket = ticketService.createTicket(request);
LogCauseReport logCauseReport = supportAnalysisService.analyzeLogs(request);
String classCode = ragService.findRelevantClass(null, logCauseReport.repoName(), null, logCauseReport.className()).stream()
.map(SupportAgentController::stripMetadataLines)
.filter(content -> !content.isBlank())
.collect(Collectors.joining(System.lineSeparator() + System.lineSeparator()));
String solution = supportAnalysisService.suggestFix(classCode, logCauseReport.causeOfProblem());
ticketService.updateTicket(ticket.getId(), SupportStatus.SUBMITTED,
"Cause of the problem: " + logCauseReport.causeOfProblem() + "\n\nSuggested fix: " + solution);
return ResponseEntity.status(HttpStatus.CREATED).body(SupportTicketResponse.from(ticket));
}
ChatClient i prompty jako umowy
Spring AI opiera się na API ChatClient, które stanowi ustrukturyzowany sposób komunikacji z modelami językowymi. Zamiast ręcznie tworzyć żądania HTTP, programiści korzystają z intuicyjnego interfejsu API, który obsługuje budowę promptów, ich wykonywanie oraz obsługę odpowiedzi.
Pierwsza próba stworzenia klasyfikatora ticketów w projekcie Support Agent wyglądała w ten sposób.
String result = chatClient.prompt("Analyze if incoming support ticket is about some kind of issue or is it a business request. "
+ "If it's a business request, the text will ask you to create something new or ask for estimation, if it's a support request "
+ "the text will say that something is not working properly, something is down or needs fixing. Answer with true if it's a "
+ "business request and false if it's a support request" + request.description())
.call()
.content();
Przypomina zwykłą API, z tą różnicą, że umowa jest definiowana przez prompt, a nie już przez schemat JSON.
Czy dałoby to dokładne wyniki w środowisku produkcyjnym? Prawdopodobnie nie. Miesza trwałe instrukcje z niepewnymi danymi wprowadzonymi przez użytkownika w jedną ciąg znaków, nie oddziela treści zlecenia i zakłada, że model zwróci coś, co Java może zinterpretować jako wartość logiczną. Wersja przeznaczona do użycia w produkcji przypomina bardziej umowę aplikacyjną, przy której instrukcje na poziomie systemu są oddzielone od danych wprowadzanych przez użytkownika.
String result = chatClient.prompt()
.system("""
You classify incoming tickets for an L3 support workflow.
Return exactly one token: true or false.
Return true when the request asks for new functionality, estimation, planning, or project work.
Return false when the request reports broken, degraded, unavailable, or incorrect production behavior.
Do not explain your answer.
""")
.user(u -> u.text("""
Ticket title: {title}
Ticket source: {source}
Ticket description:
---
{description}
---
""")
.param("title", request.title())
.param("source", request.source())
.param("description", request.description()))
.call()
.content();
Instrukcje systemu określają zachowanie i ograniczenia, natomiast wiadomość użytkownika zawiera zmieniające się dane wejściowe. Pytania użytkownika stają się częścią samego projektu, odnotowując założenia, ustalając ton i wpływając na sposób interpretacji zapytań.
To prowadzi do powstania nowej dziedziny – inżynierii pytań. Pytanie użytkownika nie jest już tylko przypadkowym ciągiem znaków. Jest to element, który należy wersjonować, testować i utrzymywać, a takie podejście jest konieczne dla stabilnych systemów. Strony referencyjne Spring AI dotyczące pytań oraz ChatClient stanowią naturalny następny materiał do przeczytania.
Strukturyzowany wynik
Jednym z wczesnych wyzwań przy włączaniu sztucznej inteligencji do systemów backendowych jest brak struktury w odpowiedziach. Modele naturalnie wytwarzają tekst w formie swobodnej, podczas gdy aplikacje korporacyjne wymagają danych uporządkowanych.
Spring AI eliminuje tę luki, mapując odpowiedzi bezpośrednio na obiekty Java. Dzięki temu eliminuje się ręczne parsowanie i zmniejsza się ryzyko niejednoznaczności w interpretacji wyników.
Zamiast otrzymywać akapit informujący o błędzie, agent obsługi klienta korzysta z rekordu Java, aby określić, który repositoryj i klasa prawdopodobnie są zaangażowane w incydent.
@Service
@RequiredArgsConstructor
public class SupportAnalysisService {
private final ChatClient chatClient;
private final LogRetrievalTool logRetrievalTool;
public LogCauseReport analyzeLogs(SupportTicketRequest request) {
var converter = new BeanOutputConverter<>(LogCauseReport.class);
var format = converter.getFormat();
String response = chatClient.prompt("Analyze the support problem and provide solution, use available MCP tools to access logs. "
+ "Incoming support request description: " + request.description()
+ " \n provide response in this format " + format).tools(logRetrievalTool).call().content();
LogCauseReport report = converter.convert(response);
return report;
}
}
public record LogCauseReport(String causeOfProblem, String repoName, String className) {
}
Tutaj model jest kierowany tak, aby wytwarzał odpowiedź, którą można bezpośrednio przekształcić w obiekt o ściśle określonym typie, przenosząc integrację z luźnej obróbki tekstu na wyraźne umowy.
Korzyści są znaczne. Nieustrukturyzowany wynik zmusza do delikatnego analizowania, które zawodzi przy najmniejszych zmianach sformułowań. Ustrukturyzowany wynik można zweryfikować, zarejestrować i przekazywać tak jak każdy inny typ danych. Oficjalna dokumentacja opisuje podejście oparte na konwerterach.
Nowsze wersje Spring AI oferują również mapowanie typowanych entytetów oraz, w przypadku niektórych dostawców, natywny ustrukturyzowany wynik – oba te rozwiązania warto rozważyć. Wymuszanie przestrzegania umowy bliżej modelu oznacza mniej kodu do analizy, który musi być obsługiwany przez aplikację.
Wywoływanie narzędzi
Generowanie tekstu jest przydatne, ale prawdziwa wartość pojawia się wtedy, gdy sztuczna inteligencja może współpracować z systemem poprzez pobieranie danych, uruchamianie procesów lub wykonywanie logiki biznesowej.
Narzędzie wywoławcze umożliwia to poprzez udostępnianie funkcji aplikacji, które model może wywołać na podstawie swoich rozumowań. Model nie powinien być traktowany jako operator z bezpośrednim dostępem do infrastruktury. Prosi on o określoną funkcjonalność, a aplikacja decyduje, czy ta funkcjonalność istnieje, jak walidowane są argumenty, jakie dane są zwracane oraz jak rejestrowana jest eksploatacja.
W ramach projektu SupportAnalysisService udostępnia LogRetrievalTool do kroku analizy logów. Definicja narzędzia wymaga adnotacji @Tool, a jego parametr opisowy pomaga modelowi ocenić, kiedy należy wywołać daną funkcję.
@Tool(name = "analyze_logs", description = "Analyzes provided logs and summarizes potential issues")
public LogCauseReport analyzeLogs(
@ToolParam(description = "Application name") String applicationName) {
var converter = new BeanOutputConverter<>(LogCauseReport.class);
var format = converter.getFormat();
String prompt = """
You are a support AI specialized in analyzing application logs to identify potential issues.
Given the application name "%s", analyze the relevant logs and provide a structured report.
Respond ONLY with a single JSON object that strictly matches this format:
%s
Do NOT return the schema itself, only valid JSON with values filled in.
""".formatted(applicationName, format);
String jsonResponse = chatClient.prompt()
.user(prompt)
.call()
.content();
return converter.convert(jsonResponse);
}
Gdy model stwierdza, że potrzebuje więcej informacji, wywołuje funkcję, uwzględnia uzyskany wynik i kontynuuje generowanie. W praktyce model staje się koordynatorem możliwości systemu.
Jednak w miarę rozwoju systemów integracje hardcodowane stają się ograniczeniem, ponieważ każde nowe narzędzie zwiększa powiązania pomiędzy modelem a aplikacją.
Odkrywanie narzędzi za pomocą MCP
Protokół Model Context Protocol rozwiązuje ten problem. MCP standaryzuje sposób, w jaki narzędzia i usługi są dostępne dla modeli, dzięki czemu można je dynamicznie odkrywać i nie muszą być wbudowane w aplikację.
MCP przekształca stałe integracje w dynamiczny ekosystem, w którym możliwe jest dodawanie lub modyfikowanie funkcjonalności bez konieczności zmian w samym oprogramowaniu, co stanowi podstawowy krok w kierunku skalowalnych architektur opartych na agentach. Dokumentacja dotycząca wywoływania narzędzi w Spring AI opisuje model programowania oraz przepływ wykonywania zadań. Gdy narzędzia wymagają dynamicznego wykrywania lub muszą być udostępniane pomiędzy procesami, wsparcie MCP stanowi logiczne rozwiązanie tego problemu.
Generowanie wzbogacone o dane
Modele są potężne, ale nie wiedzą nic o danych w systemach użytkownika. Klienci, produkty oraz wewnętrzne procesy pozostają nieznane, chyba że zostaną dostarczone odpowiednie informacje.
RAG rozwiązuje ten problem poprzez dodanie etapu pobierania danych przed generowaniem treści. Relevanckie dokumenty są pobierane z magazynu wektorowego i włączane do zapytania, dzięki czemu wyniki generowania są oparte na danych firmowych, takich jak instrukcje obsługi, logi produkcji oraz kod aplikacji.
Dla agenta obsługi klienta RAG dostarcza rozwiązanie w postaci kodu na dany problem w produkcji, wykorzystując klasę Java wymienioną w logach aplikacji.
Pierwszym krokiem jest pobranie fragmentów źródłowego kodu przez SupportAgentController za pośrednictwem GithubRagService, który korzysta z LogCauseReport zawierającego informacje o podejrzanym repozytorium i klasie.
String classCode = ragService.findRelevantClass(null, logCauseReport.repoName(), null, logCauseReport.className()).stream()
.map(SupportAgentController::stripMetadataLines)
.filter(content -> !content.isBlank())
.collect(Collectors.joining(System.lineSeparator() + System.lineSeparator()));
W drugim kroku usługa wyszukiwania tworzy filtry metadanych i przeprowadza wyszukiwanie podobieństwa w bazie wektorowej Qdrant.
SearchRequest.Builder searchRequestBuilder = SearchRequest.builder();
if (expressions != null) {
searchRequestBuilder = searchRequestBuilder.filterExpression(expressions.build());
}
Set<String> results = Objects.requireNonNull(vectorStore.similaritySearch(searchRequestBuilder.topK(10).build()))
.stream()
.map(Document::getFormattedContent)
.collect(Collectors.toSet());
Trzeci krok wprowadza pobrany kod do promptu, który prosi o naprawę.
String prompt = """
You are a Senior Java Developer. You have the following class code:
%s
The code has the following problem: %s
Provide a detailed suggestion on how to fix the problem in the code.
Format your response in markdown with clear sections.
""".formatted(classCode, problemDescription);
String suggestion = chatClient.prompt(prompt).call().content();
Skutkiem tego jest przekształcenie modelu z zwykłego asystenta w takiego, który zna dane dziedziny. RAG przede wszystkim ogranicza halucynacje i zapewnia, że odpowiedzi są zgodne z wewnętrzną wiedzą modelu, ale kosztem większej złożoności.
Dodaje on modele embeddingów, bazy danych wektorowych oraz logikę wyszukiwania, z którymi wszystkimi trzeba się zajmować i których trzeba dostosowywać. W zastosowaniach korporacyjnych ta złożoność jest często nieunikniona, ponieważ jakość odpowiedzi zależy od kilku czynników: aktualności przetwarzanych danych, jakości metadanych, strategii dzielenia danych na fragmenty, uprawnień oraz śledzenia dowodów. Dokumentacja Spring AI dotycząca RAG, baz danych wektorowych i Qdrant omawia koncepcje przedstawione w tym rozdziale.
Obserwowalność, ocena i kontrole operacyjne
Obserwowalność w przypadku sztucznej inteligencji funkcjonuje inaczej. Tradycyjne logowanie i monitorowanie zakładają zachowanie deterministyczne, natomiast sztuczna inteligencja wymaga śledzenia dodatkowych wymiarów. Rejestrowanie czasów reakcji i wskaźników błędów jest niewystarczające – zespoły muszą również mieć dostęp do promptów, wyników modeli, użycia tokenów oraz interakcji z narzędziami.
Agent obsługi klienta wykorzystuje Micrometer jako framework do zapewnienia obserwowalności, który rejestruje:
- identyfikatory i kontekst każdej prośby, takie jak numer ticketu, osoba zadająca zapytanie oraz system źródłowy
- dostawcę i nazwę modelu, wersję promptu, opóźnienie, użycie tokenów oraz powód zakończenia
- to, czy konwersja na strukturyzowany wynik się udała
- każde wezwanie narzędzia, wraz z znormalizowanymi argumentami, rozmiarem wyniku i opóźnieniem
- które repozytoria, pliki, wyniki ocen wektorowych oraz fragmenty danych zostały przywrócone
- końcowy stan ticketu oraz to, czy osoba sprawdzająca zaakceptowała lub zmieniła sugestię
Taki poziom szczegółowości jest kluczowy przy debugowaniu i optymalizacji, ponieważ wyjaśnia, dlaczego system zachowuje się w określony sposób. W aplikacjach produkcyjnych wrażliwe zapytania i wyniki nie powinny być rejestrowane dosłownie. Lepszą alternatywą jest ustrukturyzowane rejestrowanie zdarzeń zawierające identyfikator żądania, identyfikator modelu, liczbę tokenów oraz wynik polityki.
Ocena wyników dodaje kolejny warstwę. Systemy mogą oceniać jakość odpowiedzi według z góry określonych kryteriów i nie muszą zakładać, że odpowiedzi są poprawne. To umożliwia takie wzorce jak pętle oceniająco-optymalizujące, w których odpowiedź jest udoskonalana przed dotarciem do użytkownika.
Zmienia to również sposób rozwoju systemu. Za każdym razem, gdy zmienia się zapytanie, model embeddingowy, metoda dzielenia na fragmenty lub wersja modelu, wynik można porównać z już znanymi przypadkami, dzięki czemu zespół może stwierdzić, czy zmiana poprawia przepływ pracy, a nie polega jedynie na kilku imponujących przykładach.
Zanim asystent został udostępniony innym zespołom, dla projektu rozważono szereg środków kontroli operacyjnej:
- ściśle określone limity czasowe dla połączeń z modelem, narzędziami oraz magazynem wektorowym
- budżety tokenów na zapytanie i dla każdego użytkownika, co ogranicza koszty i możliwości awarii
- próby ponowne wykonywane tylko w bezpiecznych warunkach i z określonymi ograniczeniami
- stany awaryjne w przypadku niepracującego modelu, narzędzia lub Qdrant
- maskowanie tajemnic, danych uwierzytelniających oraz informacji osobistych przed wysyłką zapytań i zapisywaniem logów
- logowanie treści domyślnie wyłączone lub dostępne tylko przy zatwierdzonych środkach kontroli dostępu
- jasne zasady przechowywania zapytań, odpowiedzi, embeddingów oraz wyników narzędzi
- panel sterowania i powiadomienia dotyczące nieudanych konwersji, pustych wyników wyszukiwania, błędów narzędzi oraz odrzuceń przez recenzentów
Wskaźnik odrzuceń przez recenzentów najlepiej odzwierciedla rzeczywiste użycie. Gdy inżynierowie regularnie przepisują lub odrzucają generowane rekomendacje, asystent dodaje tylko pracę. System produkcyjny powinien uczyć się na tej sygnale. Automatyczne dopasowywanie we wszystkim nie jest właściwym rozwiązaniem. Lepszą drogą jest podejście operacyjne: ulepszanie promptów, narzędzi, mechanizmów wyszukiwania oraz zasad na podstawie udokumentowanych dowodów. Dokumentacja dotycząca możliwości obserwacji w Spring AI omawia wbudowane narzędzia.
Projektowanie ograniczonych pracowników agentowych
Łącząc wszystko powyższe, pojawia się nowy wzorzec: system agentowy.
Aplikacje tradycyjne podążają za z góry zdefiniowanymi procesami. Te oparte na agentach działają w cyklu iteracyjnym polegającym na obserwowaniu, rozumowaniu i działaniu. Zachowują stan, wykorzystują pamięć i dynamicznie decydują, jakie działania podjąć.
Stan, pamięć i autonomia stają się kluczowymi elementami, a każdy z nich odpowiada już istniejącej funkcji dostępnej w Spring AI:
- stan to to, co jest znane w bieżącej interakcji
- pamięć to to, co przetrwa między interakcjami
- narzędzia określają, jakie działania są dozwolone
- zasady ograniczające wskazują, co jest zabronione lub wymaga potwierdzenia
- kryteria zakończenia określają, kiedy pętla musi się zakończyć
To zmienia rolę aplikacji w porównaniu z klasycznym procesem biznesowym w przedsiębiorstwie. Zamiast definiować każdy krok, system określa możliwości i ograniczenia oraz pozwala modelowi organizować zachowanie w ramach tych granic.
W ramach agenta obsługi klienta pętla zaczyna się od żądania. Agent analizuje je, wykorzystuje narzędzia i pobiera kod. Następnie opracowuje rekomendację i aktualizuje ticket. Nie jest to autonomiczny operator produkcyjny i nie powinien nim stać się. W technologii finansowej ta granica określa, jakie działania agent może podjąć w danym kontekście. Można ufać modelowi, że dobrze podsumuje logi, zanim będzie można mu zaufać przy modyfikacji ticketa.
Tworzenie skutecznych agentów jest trudne, a dokumentacja Spring AI na ten temat stanowi solidny punkt wyjścia.
Od eksperymentów do systemów korporacyjnych
SZI nie jest zwykłą dodatkową funkcją – dodaje nową warstwę do systemów korporacyjnych, warstwę probabilistyczną, dynamiczną i ściśle powiązaną z zewnętrznymi zależnościami. Bez odpowiedniej struktury warstwa ta szybko prowadzi do kruchej, nieprzewidywalnej zachowania.
Spring AI oferuje sposób na jego integrację przy jednoczesnym zachowaniu praktyk inżynieryjnych, które zapewniają niezawodność systemów korporacyjnych. Znane abstrakcje oraz dobrze zdefiniowane wzory integracji umożliwiają zespołom wdrożenie sztucznej inteligencji bez rezygnacji z wyraźnych umów, kontrolowanych interakcji oraz przewidywalnego zachowania.
Zmiana ta nie dotyczy więc tylko dodawania funkcji opartych na sztucznej inteligencji. Chodzi o rozwój systemów tak, aby sztuczna inteligencja stała się użyteczną, kontrolowaną i łatwą do monitorowania częścią architektury. Przyszłe aplikacje korporacyjne będą oceniane pod kątem tego, jak dobrze integrują sztuczną inteligencję, a sposób jej wykorzystania będzie miał mniejsze znaczenie.
Literatura pokrewna
- Praktyczne notatki: RAG jest martwe. LLM Wiki — idea Andreja Karpathy — to to, co nadejdzie następnie — Szczegółowy przewodnik po Praktycznych notatkach: RAG jest martwe. LLM Wiki — idea Andreja Karpathy — to to, co nadejdzie następnie: umowy, sprawdzenia oraz miejsca na kod do wstawienia dla zespołów tworzących rozwiązania typu RAG.
- Projekt RAG to nie jeden ogromny plik Pythona: struktura folderów, która pozwala na rozwój — Podziel aplikację demonstracyjną typu RAG na komponenty odpowiedzialne za pobieranie danych, dzielenie ich na fragmenty, generowanie wektorów, przechowywanie wektorów, wyszukiwanie, tworzenie promptów, klienta LLM, API, testy oraz logi, aby mogła rozwijać się poza etap weekendowy.