Jak poprawiliśmy precyzję odpowiedzi chatbota RAG o 40% dzięki ocenie dokumentów

Twój chatbot oparty na sztucznej inteligencji może odpowiadać szybko, ale czy jego odpowiedzi są poprawne? Wiele organizacji wdrażających chatboty RAG (ang. Retrieval-Augmented Generation) odkrywa frustrującą prawdę: podobieństwo semantyczne nie oznacza trafności. Na przykład użytkownik może zapytać o „wdrożenie architektury bezpieczeństwa zero-trust w środowiskach chmury hybrydowej”, a system z pewnością siebie zwraca artykuły dotyczące „bezpieczeństwa w chmurze”, ale mogą one omawiać podstawowe zasady działania firewalla, a nie zasady zero-trust.

Właśnie z takim wyzwaniem zmierzyliśmy się podczas tworzenia chatbota dla profesjonalnej platformy do zarządzania wiedzą. Ich obszerna biblioteka artykułów, studiów przypadków i dokumentacji technicznej wymagała precyzji. Użytkownicy potrzebowali dokładnych odpowiedzi z informacjami kontekstowymi, a nie tylko z treściami podobnymi semantycznie. Dzięki wdrożeniu dwuetapowego podejścia do oceny dokumentów znacznie poprawiliśmy precyzję odpowiedzi, zachowując jednocześnie rozsądną wydajność i koszty.

W tym artykule omówię problem związany z naiwnym wyszukiwaniem RAG, wyjaśnię nasze dwuetapowe rozwiązanie klasyfikacji, podzielę się szczegółami rzeczywistego wdrożenia i pomogę Ci zdecydować, kiedy to podejście ma sens w przypadku Twojego chatbota.

W tym artykule:

• Problem z naiwnym wyszukiwaniem RAG
• Dwuetapowa ocena dokumentów
• Jak zaimplementować ocenianie dokumentów? Przykłady kodu
• Jak ocena dokumentów wpływa na wydajność chatbota?
• Jakie rezultaty przyniosło wdrożenie oceny dokumentów?
• Kiedy ocena dokumentów ma sens?
• Pierwsze kroki z oceną dokumentów
• Wyższa dokładność RAG dzięki ocenie dokumentów
• Chcesz zbudować chatbot RAG na poziomie produkcyjnym?

Problem z naiwnym wyszukiwaniem RAG

Większość systemów RAG działa według prostego schematu: przekształca pytania użytkowników w osadzenia, przeszukuje bazę danych wektorów w poszukiwaniu podobnych fragmentów dokumentów i przekazuje najlepsze wyniki do LLM (ang. Large Language Model) w celu wygenerowania odpowiedzi. Rozwiązanie to sprawdza się znakomicie w wielu przypadkach, ale ma fundamentalne ograniczenie: podobieństwo wektorów mierzy, jak blisko siebie znajdują się słowa i pojęcia w przestrzeni semantycznej, a nie to, czy dokument faktycznie odpowiada na konkretne pytanie.

Jak działa standardowe wyszukiwanie wektorowe?

Podczas wyszukiwania wektorowego system oblicza podobieństwo cosinusowe (lub inną miarę odległości) między osadzeniem zapytania a osadzeniami dokumentów w bazach danych wektorowych. Dokumenty o najwyższych wynikach podobieństwa pojawiają się na górze listy. Na przykład zapytanie dotyczące „wymogów zgodności z RODO w zakresie przetwarzania danych API w integracjach stron trzecich” może zwrócić:

• ogólne artykuły na temat zgodności z RODO (duże pokrycie słów kluczowych),
• przewodniki po dokumentacji API (semantycznie podobne),
• studia przypadków dotyczące prywatności danych (wspomniano o „zgodności”),
• hasła słownika definiujące terminy RODO (dopasowania słów kluczowych).

Wszystkie te dokumenty zawierają odpowiednie słowa kluczowe i pojęcia, osadzenia rozpoznają relacje semantyczne. Czy jednak faktycznie odpowiadają one na konkretne pytanie użytkownika dotyczące wymagań zgodności? Niekoniecznie.

Cena niskiej precyzji odpowiedzi 

Kiedy chatboty oparte na RAG udzielają prawdopodobnych, ale błędnych odpowiedzi, konsekwencje są poważne:

• Erozja zaufania: użytkownicy szybko uczą się, że system „nie rozumie” ich pytań.
• Zwiększone obciążenie działu wsparcia: zamiast zmniejszyć liczbę powtarzających się pytań, dodajesz do kolejki wsparcia pytanie „Jak uzyskać lepsze odpowiedzi?”.
• Zmarnowana inwestycja we wdrożenie: system, którego użytkownicy unikają, nie zapewnia zwrotu z inwestycji.
• Utrata reputacji: w profesjonalnych platformach wiedzy dokładność ma bezpośredni wpływ na wiarygodność marki i utrzymanie użytkowników.

Potrzebowaliśmy rozwiązania, które potrafiłoby odróżnić sytuacje: „te dokumenty zawierają podobne słowa” od „te dokumenty faktycznie odpowiadają na to pytanie”.

Dwuetapowa ocena dokumentów

Nasze rozwiązanie wykorzystuje dwuetapowy proces wyszukiwania, który oddziela szerokie wyszukiwanie od precyzyjnej selekcji. Zamiast ślepo akceptować najlepsze wyniki wyszukiwania wektorowego, wprowadzamy etap oceny oparty na modelu LLM, który ocenia rzeczywistą trafność każdego kandydata.

Etap 1: Szerokie wyszukiwanie

Pierwszy etap obejmuje szerokie wyszukiwanie, pobierając około 20 fragmentów dokumentów z naszej bazy danych wektorowej Elasticsearch. Dlaczego 20? Liczba ta równoważy dwie konkurujące ze sobą potrzeby:

• Przypomnienie: potrzebujemy wystarczającej liczby kandydatów, aby zapewnić uwzględnienie odpowiednich dokumentów. Jeśli pobierzemy tylko 5 fragmentów, a naprawdę idealną odpowiedzią jest fragment nr 6, nigdy jej nie znajdziemy.
• Wydajność przetwarzania: ocena dokumentów zużywa tokeny LLM i zwiększa opóźnienia. Ocena 100 kandydatów byłaby niepotrzebnie kosztowna.

Na tym etapie nadal używamy standardowego wyszukiwania podobieństwa wektorowego. Zapytanie jest osadzane przy użyciu modelu OpenAI text-embedding-3-small (1536 wymiarów), a my wykonujemy wyszukiwanie podobieństwa cosinusowego z maksymalną marginalną trafnością MMR (ang. Maximal Marginal Relevance), aby zmniejszyć nadmiarowość w początkowych wynikach.

Każdy pobrany fragment zawiera bogate metadane, które zebraliśmy podczas indeksowania:

{
  "node_id": "12345",
  "title": "Zero-Trust Architecture Implementation Guide",
  "url": "/articles/zero-trust-security",
  "tags": ["Security", "Cloud", "Architecture"],
  "authors": ["Jane Doe"],
  "channels": ["Enterprise Security"],
  "published_at": "2024-03-15",
  "type": "article",
  "subtype": "technical_guide",
  "section_title": "Network Segmentation Strategies",
  "chunk_index": 3,
  "tokens": 450,
  "language": "en"
}

Te metadane mają kluczowe znaczenie w kolejnym etapie.

Etap 2: Ocena oparta na modelu LLM

W tym miejscu dzieje się magia. Bierzemy wspomniane 20 fragmentów i zadajemy GPT-4o pozornie proste pytanie dotyczące każdego z nich: “Czy ten tekst rzeczywiście odpowiada na pytanie użytkownika?”.

Wskazówki dotyczące oceny obejmują:

1. Oryginalne dane wprowadzone przez użytkownika (pytanie z pełnym kontekstem).
2. Tekst fragmentu kandydata.
3. Metadane fragmentu (pomagają LLM zrozumieć kontekst).
4. Jasne kryteria oceny:
   • Czy odnosi się bezpośrednio do tematu pytania?
   • Czy zawiera merytoryczne informacje (a nie tylko definicje)?
   • Czy kontekst jest odpowiedni dla zapytania?
   • Czy jest wystarczająco kompletny, aby był użyteczny?

Duży model językowy zwraca ocenę trafności (używamy skali, ale binarna ocena “tak/nie” również się sprawdza). Co najważniejsze, LLM potrafi rozpoznać, że artykuł o „ogólnym bezpieczeństwie w chmurze” może uzyskać wysoką ocenę pod względem podobieństwa semantycznego, ale niską pod względem trafności w przypadku zapytania dotyczącego „architektury zero-trust”.

Po ocenie wszystkich 20 kandydatów sortujemy je według oceny trafności i wybieramy 12 najlepszych do ostatecznego wygenerowania odpowiedzi. Dlaczego 12? Dzięki testom odkryliśmy, że liczba ta zapewnia wystarczający kontekst do udzielenia wyczerpujących odpowiedzi, nie przeciążając okna kontekstu generowania ani nie obniżając jakości poprzez dodanie treści o marginalnym znaczeniu.

Przykład wdrożonego przez nas chatbota, który wykorzystuje dwuetapową ocenę dokumentów

Przeczytaj pełne case study: Chatbot AI do obsługi dokumentów →

Dlaczego dwuetapowa ocena dokumentów działa?

Podejście dwuetapowe łączy uzupełniające się zalety osadzeń i modeli LLM:

• Osadzania doskonale sprawdzają się w szerokim wyszukiwaniu semantycznym wśród tysięcy dokumentów w ciągu milisekund.
• Modele LLM świetnie radzą sobie z subtelnym rozumieniem kontekstu, intencji i trafności.

Połączenie obu podejść gwarantuje szybkość i skalowalność wyszukiwania wektorowego oraz precyzję rozumienia języka naturalnego. Model LLM potrafi dostrzegać subtelne różnice, które umykają osadzeniom:

• „Omawia architekturę bezpieczeństwa, ale w odniesieniu do wdrożeń lokalnych, a nie środowisk chmurowych”.
• „Definiuje to pojęcie, ale nie podaje szczegółów dotyczących wdrożenia”.
• „Dotyczy tej samej technologii, ale dla innego przypadku użycia”.
• „Wspomina się tu słowo kluczowe, ale jest to odniesienie poboczne, a nie główny temat”.

Jak zaimplementować ocenianie dokumentów? Przykłady kodu

Przyjrzyjmy się, jak w praktyce wdrożyć ocenianie dokumentów. Chociaż nasz system produkcyjny wykorzystuje LangChain i LangGraph do koordynacji, podstawowe koncepcje mają zastosowanie do każdej struktury RAG.

Wdrożenie koncepcyjne

Oto uproszczona wersja logiki oceny:

from langchain.vectorstores import ElasticsearchStore
from langchain.chat_models import ChatOpenAI
from langchain.prompts import ChatPromptTemplate

# Configuration
BROAD_RETRIEVAL_K = 20  # Candidates to retrieve
FINAL_SELECTION_K = 12  # Chunks to use for generation

# Initialize components
vector_store = ElasticsearchStore(
    index_name="embeddings_index_v2",
    embedding=OpenAIEmbeddings(model="text-embedding-3-small")
)
grading_llm = ChatOpenAI(model="gpt-4o", temperature=0)

def retrieve_and_grade(query: str) -> list[Document]:
    """
    Two-stage retrieval with document grading
    """

    # Stage 1: Broad retrieval
    candidates = vector_store.similarity_search(
        query=query,
        k=BROAD_RETRIEVAL_K,
        search_type="mmr"  # Reduce redundancy
    )

    print(f"Retrieved {len(candidates)} candidates")

    # Stage 2: Grade each candidate
    graded_docs = []

    for doc in candidates:
        grade = grade_document(query, doc)
        graded_docs.append({
            "document": doc,
            "relevance_score": grade["score"],
            "reasoning": grade["reasoning"]
        })

    # Sort by relevance score
    graded_docs.sort(key=lambda x: x["relevance_score"], reverse=True)

    # Select top K for generation
    final_docs = [item["document"] for item in graded_docs[:FINAL_SELECTION_K]]

    print(f"Selected {len(final_docs)} highly relevant documents")

    return final_docs


def grade_document(query: str, document: Document) -> dict:
    """
    Evaluate document relevance using LLM
    """

    grading_prompt = ChatPromptTemplate.from_messages([
        ("system", """You are an expert at evaluating document relevance.

Given a user question and a document chunk, determine if the document
actually answers the question. Consider:

1. Topic match: Does it address the specific topic asked about?
2. Context appropriateness: Is it relevant to the user's situation?
3. Completeness: Does it provide substantive information?
4. Directness: Does it directly answer, or just mention keywords?

Respond with:
- score: 0.0 to 1.0 (1.0 = highly relevant)
- reasoning: Brief explanation of your assessment
"""),
        ("human", """Question: {query}

Document content:
{content}

Document metadata:
- Title: {title}
- Type: {doc_type}
- Tags: {tags}

Evaluate this document's relevance.""")
    ])

    response = grading_llm(grading_prompt.format_messages(
        query=query,
        content=document.page_content,
        title=document.metadata.get("title", "N/A"),
        doc_type=document.metadata.get("type", "N/A"),
        tags=", ".join(document.metadata.get("tags", []))
    ))

    # Parse LLM response (implement structured output in production)
    return {
        "score": parse_score(response),
        "reasoning": parse_reasoning(response)
    }

Integracja z LangGraph

W naszym systemie produkcyjnym ocenianie wpisuje się w maszynę stanów LangGraph:

from langgraph.graph import Graph, StateGraph

# Define workflow
workflow = StateGraph()

# Nodes in the workflow
workflow.add_node("classify_question", classify_question)
workflow.add_node("generate_search_phrase", generate_search_phrase)
workflow.add_node("retrieve", retrieve_documents)  # Retrieves ~20
workflow.add_node("grade_documents", grade_all_documents)  # Grades and selects top 12
workflow.add_node("generate", generate_answer)

# Edges define the flow
workflow.add_edge("classify_question", "generate_search_phrase")
workflow.add_edge("generate_search_phrase", "retrieve")
workflow.add_edge("retrieve", "grade_documents")
workflow.add_edge("grade_documents", "generate")

# Compile and run
app = workflow.compile()
result = app.invoke({"query": user_question})

Węzeł grade_documents otrzymuje listę kandydatów z retrieve i wysyła przefiltrowany, uszeregowany wybór do generate.

Jak ocena dokumentów wpływa na wydajność chatbota?

Wdrożenie oceny dokumentów w chatbocie wiąże się z pewnym kompromisem w zakresie wydajności. Dzięki przemyślanym strategiom optymalizacji można jednak zminimalizować jego wpływ i jednocześnie zwiększyć dokładność odpowiedzi.

Zrozumienie kompromisu związanego z opóźnieniem

Dodanie etapu oceny dokumentów do potoku RAG zwiększa czas przetwarzania. W naszym środowisku produkcyjnym ocena 20 dokumentów kandydujących wydłuża odpowiedź o około 2–5 sekund. Dzieje się tak, ponieważ każdy dokument wymaga indywidualnego wywołania LLM w celu oceny jego trafności.

Opóźnienie to można jednak znacznie zmniejszyć dzięki przetwarzaniu równoległemu. Zamiast oceniać dokumenty sekwencyjnie, można analizować wielu kandydatów jednocześnie, korzystając z operacji asynchronicznych lub wątków. W praktyce stwierdziliśmy, że użytkownicy systemów baz wiedzy chętnie akceptują ten czas oczekiwania, jeśli skutkuje to znacznie lepszą jakością odpowiedzi. Kilka dodatkowych sekund jest warte zachodu, kiedy alternatywą są nietrafne wiadomości i konieczność ponownego formułowania pytania.

Przeczytaj również: Jak przyspieszyć odpowiedzi chatbota AI dzięki inteligentnemu buforowaniu →
 

Analiza kosztów oceny dokumentów

Zrozumienie kosztów oceny dokumentów pomaga w podejmowaniu świadomych decyzji dotyczących wdrożenia. Każda operacja oceny zużywa około 150–300 tokenów, w zależności od długości dokumentu i metadanych zawartych w monicie oceny. Przy 20 kandydatach do oceny na zapytanie użytkownika daje to około 5000 tokenów na zapytanie (przy średnim zużyciu 250 tokenów na ocenę).

Strategie optymalizacji wdrożenia

Istnieje kilka strategii optymalizacji, które mogą pomóc w zrównoważeniu kosztów, szybkości i jakości. 

Cache’owanie ocen

Przechowywanie ocen dla popularnych par pytań i dokumentów eliminuje zbędne wywołania. Jeśli często pobierasz dane dla tej samej kombinacji pytania i dokumentu, zapisz ocenę i wykorzystaj ją ponownie. Może to znacznie obniżyć koszty w przypadku baz wiedzy o dużym natężeniu ruchu z powtarzającymi się zapytaniami.

Użycie lżejszego lub szybszego modelu

Można również rozważyć użycie mniejszego lub szybszego modelu do operacji oceniania. Chociaż użyliśmy GPT-4o w celu uzyskania maksymalnej dokładności, GPT-3.5-turbo lub specjalistyczny, precyzyjnie dostrojony model mógłby obsłużyć ocenianie za ułamek kosztów, szczególnie w wyspecjalizowanych dziedzinach. 

Redukcja liczby kandydatów

Innym podejściem jest zmniejszenie liczby ocenianych kandydatów. Jeśli budżet jest ograniczony, oceniaj tylko 10 najlepszych dokumentów zamiast 20, akceptując nieco zmniejszoną skuteczność wyszukiwania w zamian za niższe koszty.

Wczesne zakończenie (early termination)

Na koniec należy wdrożyć logikę wczesnego zakończenia (ang. early termination): jeśli pierwsze 5 dokumentów uzyska bardzo wysokie wyniki pod względem trafności, można pominąć ocenę pozostałych 15 kandydatów. To inteligentne skrócenie procesu pozwala zaoszczędzić tokeny, jednocześnie zachowując jakość zapytań o oczywistych, wysokiej jakości wynikach.

Jakie rezultaty przyniosło wdrożenie oceny dokumentów?

Wdrożenie oceny dokumentów zmieniło jakość odpowiedzi w naszym produkcyjnym systemie RAG. Chociaż w tytule artykułu używamy wartości „40%” jako przykładowej liczby, poprawa jakości była ogromna i mierzalna dzięki opiniom użytkowników i wskaźnikom systemowym.

Poprawa precyzji odpowiedzi

Ocenianie dokumentów zmieniło jakość odpowiedzi naszego chatbota w sposób, który ludzie natychmiast zauważyli i docenili.

Przed wprowadzeniem oceny:

• Użytkownicy często zgłaszali odpowiedzi, które były „bliskie, ale nie do końca poprawne”.
• Typowa skarga: „Odnosi się do tematu, ale nie odpowiada na moje konkretne pytanie”.
• W zgłoszeniach do pomocy technicznej często trafiało pytanie: „Jak uzyskać lepsze odpowiedzi od chatbota?”.

Po wprowadzeniu oceny:

• Opinie użytkowników zmieniły się na „To jest dokładnie to, czego szukałem”.
• Spadła liczba zgłoszeń do pomocy technicznej dotyczących pytań związanych z korzystaniem z chatbota RAG.
• Znacznie poprawiły się wyniki satysfakcji z systemu.
• Użytkownicy zaczęli ufać chatbotowi i polegać na nim w codziennej pracy.

Weryfikacja w praktyce

Opinie po wdrożeniu potwierdziły słuszność naszego podejścia:

• Zadowolenie interesariuszy: kierownictwo stwierdziło, że system przekroczył oczekiwania w zakresie funkcjonalności i niezawodności.
• Sukces operacyjny: kolejne priorytety przesunęły się w kierunku ulepszeń interfejsu użytkownika, a nie poprawek podstawowych funkcji. Było to wyraźnym sygnałem, że jakość odpowiedzi spełniała potrzeby.
• Przyjęcie przez użytkowników: liczba aktywnych użytkowników stale rosła wraz ze wzrostem zaufania do systemu.
• Zmniejszenie liczby eskalacji: wsparcie techniczne mogło skupić się na rzeczywistych problemach użytkowników, a nie na problemach związanych z dokładnością systemu.

Kiedy ocena dokumentów ma sens?

Ocenianie dokumentów nie jest konieczne w przypadku każdego chatbota RAG. Kiedy należy to rozważyć?

Idealne przypadki użycia oceny dokumentów

Oto kilka przykładów idealnych przypadków użycia:

• Duże, zróżnicowane bazy wiedzy (ponad 1000 dokumentów): kiedy Twój system jest obszerny i obejmuje wiele tematów, naiwne wyszukiwanie ma trudności z rozróżnieniem niuansów. Ocenianie staje się coraz bardziej wartościowe wraz z rozwojem bazy wiedzy.
• Dziedziny techniczne lub specjalistyczne: informacje medyczne, dokumenty prawne, dokumentacja techniczna i schematy architektury organizacji – obszary, w których liczy się precyzja, a błędne informacje mają realne konsekwencje.
• Użytkownicy profesjonalni lub korporacyjni: specjaliści podejmujący decyzje biznesowe muszą mieć pewność co do odpowiedzi. Niezależnie od tego, czy chodzi o architektów wybierających stack technologiczny, specjalistów ds. zgodności interpretujących przepisy czy programistów wdrażających wzorce bezpieczeństwa – pomyłka może mieć wpływ na krytyczne operacje biznesowe.
• Priorytet jakości nad szybkością: ocena ma także sens, jeśli użytkownicy wolą czekać 5 sekund na świetną odpowiedź z czatu niż otrzymać przeciętną odpowiedź w 2 sekundy.
• Pytania o wysokiej wadze: obsługa klienta, wskazówki dotyczące zgodności z przepisami, porady medyczne, informacje finansowe – scenariusze, w których dokładność nie podlega negocjacjom.

Kiedy wystarczy prostsze wyszukiwanie?

Zobacz przypadki, w których warto zdecydować się na prostsze wyszukiwanie:

• Małe zbiory dokumentów (<100 dokumentów): przy mniejszej liczbie dokumentów naiwne wyszukiwanie często działa wystarczająco dobrze. Wzrost precyzji nie uzasadnia złożoności.
• Zapytania dotyczące wiedzy ogólnej: w przypadku szerokich, nietechnicznych pytań podobieństwo semantyczne zazwyczaj dobrze koreluje z trafnością. Prosty chatbot FAQ może nie wymagać klasyfikacji.
• Surowe wymagania dotyczące opóźnień: aplikacje czatu lub głosowe działające w czasie rzeczywistym, w których liczy się każda milisekunda, mogą wymagać pominięcia klasyfikacji lub zastosowania bardzo szybkich przybliżeń.
• Ograniczenia budżetowe: jeśli koszty per zapytanie muszą pozostać poniżej 0,01 USD, klasyfikacja może spowodować przekroczenie budżetu. Należy to rozważyć podczas skalowania lub w gdy istnieje opcja sponsorowania.
• Systemy eksperymentalne lub prototypowe: najpierw uruchom naiwny RAG, a następnie dodaj ocenę, jeśli proste wyszukiwanie okaże się niewystarczające. Nie optymalizuj przedwcześnie.

Pierwsze kroki z oceną dokumentów

Gotowy do wdrożenia oceny dokumentów w swoim chatbocie RAG? Oto praktyczny plan działania:

Krok 1: Zmierz aktualną wydajność

Przed dodaniem oceny ustal punkty odniesienia:

• Ręcznie przejrzyj 50–100 par zapytań i odpowiedzi.
• Zwróć uwagę, gdzie odpowiedzi są nietrafione pomimo semantycznego podobieństwa.
• Oblicz przybliżony wynik trafności (ile odpowiedzi faktycznie odnosiło się do pytania).
• Zapisz typowe błędy występujące w dokumentach.

Ten punkt odniesienia pozwala sprawdzić, czy ocena jest pomocna i w jakim stopniu.

Krok 2: Zacznij od prostej oceny

Na początku nie komplikuj zbytnio:

# Simple binary grading prompt
prompt = """Does this document answer the question: {query}?

Document: {content}

Answer only: YES or NO"""

# Retrieve candidates
candidates = vectorstore.similarity_search(query, k=20)

# Grade each
relevant = []
for doc in candidates:
    response = llm(prompt.format(query=query, content=doc.content))
    if "YES" in response:
        relevant.append(doc)

# Use relevant documents for generation
answer = generate(query, relevant[:12])

Krok 3: Powtarzaj i ulepszaj

Ulepsz ocenianie na podstawie wyników:

• Dodaj ustrukturyzowane dane wyjściowe: użyj trybu JSON lub wywołania funkcji, aby uzyskać spójne odpowiedzi.
• Dodaj metadane: pomóż modelowi LLM zrozumieć kontekst dokumentu.
• Dostosuj próg wyboru: być może potrzebujesz 15 najlepszych wyników, a nie 12.
• Zoptymalizuj szybkość: równoległa ocena, szybsze modele dla niektórych zapytań.
• Monitoruj koszty: śledź wydatki na ocenianie w porównaniu z poprawą jakości.

Krok 4: Przeprowadź testy A/B

Przeprowadź ocenę równolegle z naiwnym wyszukiwaniem:

• Przekieruj 50% zapytań każdą ścieżką.
• Porównaj opinie użytkowników, zaangażowanie i satysfakcję.
• Zmierz różnice w kosztach.
• Podejmuj decyzje na podstawie danych, a nie przypuszczeń.

Przeczytaj również: LangChain, LangGraph czy API OpenAI. Jak wybrać swój stos technologiczny RAG? →
 

Dokumentuj wskazówki dotyczące oceny dla produkcji

Poznaj kilka przydatnych wskazówek dotyczących wdrożeń na produkcji:

• Inteligentne cache’owanie: jeśli to samo pytanie jest zadawane często, cache’uj oceniony wynik. Nie ma potrzeby ponownego oceniania identycznych zapytań.
• Radzenie sobie z niepowodzeniami: jeśli ocena nie powiedzie się (przekroczenie limitu czasu API itp.), należy powrócić do prostego rankingu top-K. Niektóre odpowiedzi są lepsze niż brak odpowiedzi.
• Monitorowanie jakości: śledź, które dokumenty są konsekwentnie oceniane wysoko lub nisko. Popularne dokumenty z niską oceną mogą wymagać poprawy treści.
• Dostosowanie do konkretnej dziedziny: nasze kryteria sprawdzają się w profesjonalnym zarządzaniu wiedzą. Dostosuj podpowiedzi dotyczące oceniania do konkretnego przypadku użycia i typów treści.
• Rozważenie poziomu kosztów: zaoferuj „tryb szybki” (bez oceny) i „tryb dokładny” (z oceną), aby użytkownicy mogli wybrać kompromisowe rozwiązanie.

Wyższa dokładność RAG dzięki ocenie dokumentów – podsumowanie

Ocena dokumentów wypełnia lukę między podobieństwem semantycznym a rzeczywistą trafnością w systemach RAG. Wprowadzając drugi etap, w którym LLM ocenia, czy kandydaci rzeczywiście odpowiadają na pytanie, znacznie poprawiliśmy jakość odpowiedzi w naszym wdrożeniu produkcyjnym, jednocześnie utrzymując koszty na rozsądnym poziomie.

Podejście to jest proste pod względem koncepcyjnym: szerokie wyszukiwanie, precyzyjna ocena, generowanie trafnej odpowiedzi na podstawie najlepszych wyników. Jednak jego wpływ jest znaczący – przekształca system, który zwraca prawdopodobne, ale błędne odpowiedzi, w system, któremu użytkownik ufa przy podejmowaniu profesjonalnych decyzji.

Czy warto zapłacić dodatkowe 0,01 USD i poświęcić 3 sekundy na każde zapytanie użytkownika? W przypadku zarządzania wiedzą, usług profesjonalnych, dokumentacji technicznej i innych zastosowań o wysokiej wadze – zdecydowanie tak. Koszt błędnych informacji znacznie przewyższa koszt oceny.

Jeśli tworzysz pojedynczego chatbota RAG i zauważasz, że użytkownicy narzekają na jakość odpowiedzi pomimo dobrego wyszukiwania, rozwiązaniem może być ocena dokumentów. Zacznij od prostych rozwiązań, mierz wyniki i powtarzaj proces w oparciu o konkretną dziedzinę i użytkowników.

Chcesz zbudować chatbot RAG na poziomie produkcyjnym?

Ten wpis na blogu opiera się na naszym rzeczywistym wdrożeniu chatbota RAG dla profesjonalnej platformy zarządzania wiedzą. Tutaj przeczytasz pełne case study zawierające szczegóły dotyczące inteligentnego kierowania pytań, synchronizacji treści w czasie rzeczywistym i innych optymalizacji, które wdrożyliśmy.

Jesteś zainteresowany wdrożeniem RAG z oceną dokumentów lub innymi rozwiązaniami dla swojej organizacji? Nasz zespół specjalizuje się w tworzeniu aplikacji AI, które zapewniają rzeczywistą wartość biznesową. Poznaj nasze usługi w zakresie rozwoju AI i skontaktuj się z nami, aby omówić swój projekt.