Nie można odzyskać liczby, której nikt nie zapisał: OKF kontra baza wektorowa RAG

Każdy projekt ma pewien punkt, do którego ciągle wraca, a jest nim: skompilowanie wykresów i późniejsze uzupełnienie tekstem opisowym. Ten punkt pojawił się w wyniku rozmowy z chatbotem, która rozpoczęła się w typowy sposób. Dziesięć dokumentów CDC, w tym opis ankiety, książka kodów, raport podsumowujący oraz pliki PDF z metodologią, zostały załadowane do bazy wiedzy Bedrock w nadziei, że dobrze zaopatrzona baza dostarczy dobrych odpowiedzi.

Nie udało się to. Przyczyną jest najczęstsze nieporozumienie dotyczące generacji wzbogaconej o wyszukiwanie: że im więcej dokumentów, tym dokładniejsze odpowiedzi. Baza wektorowa może zwrócić jedynie tekst, który już się w niej znajduje. W przypadku pytań, na które odpowiedź nigdy nie została zapisana, rozmiar zbioru w ogóle nie ma znaczenia.

Te dwanaście dokumentów szczegółowo opisywało zmienne związane z cukrzycą: co one oznaczają, kto został zapytany oraz jak kodowane są odpowiedzi. Żaden z nich nie zawierał statystyk, o które faktycznie prosiłby użytkownik. Te liczby zostały obliczone na podstawie 29 522 wierszy danych z ankiety i nie występują w żadnym pliku PDF, więc żadne wyszukiwanie ich nie ujawni.

To prowadzi do jeszcze większego błędu. Ludzie zakładają, że skoro dany temat pojawia się w dokumentach, RAG potrafi odpowiedzieć na każde pytanie na jego temat. W rzeczywistości radzi sobie tylko z pytaniami, których odpowiedzi znajdują się w tekście. Wszystko, co wymaga dalszych obliczeń, jest poza jego zasięgiem.

Zatem chatbot został przebudowany. Początkowo był to aplikacja edukacyjna łącząca Amazon Bedrock Flow, AWS Amplify Gen 2 i Next.js, a podczas przebudowy jego silnik wyszukiwania został zastąpiony weryfikowanym pakietem w formacie Open Knowledge Format (OKF). Aby uzyskać sprawiedliwe porównanie, na podstawie tych samych dokumentów stworzono również prawdziwą bazę wiedzy Bedrock, a obie zostały przetestowane bezpośrednio pod kątem najważniejszych kryteriów: czy odpowiedź jest poprawna i jak szybko się pojawia?

Gdy postawiono kluczowe pytanie, baza wiedzy zidentyfikowała pięć istotnych zmiennych, a następnie dokładnie określiła ograniczenie: dokumenty nie zawierają rzeczywistych statystyk obliczonych. Zaleciła nawet odpowiednią analizę – ważoną proporcję osób z jedną cechą, które mają również inną – co jest dokładnie tym, co OKF wykonywa podczas budowania, choć system, który nie może tego uruchomić, nie potrafi tego poprawnie określić. Wszystko sprowadza się do jednego zdania: nie można uzyskać liczby, której nikt nie zapisał. Strona OKF odpowiedziała liczbą obliczoną na podstawie mikrodanych według właściwej definicji populacji i odpowiednich wag.

Jak przeprowadzono test

Konfiguracja została celowo zaprojektowana symetrycznie. Claude Sonnet 4.5 generował odpowiedzi po obu stronach, w us-east-1, przy użyciu transportu SDK wewnątrz procesu oraz identycznego komunikatu systemowego używanego przez zainstalowany Lambda. Metoda została opisana jeszcze przed pojawieniem się jakichkolwiek wyników, udokumentowano wszystkie siedem pytań oraz każdą próbę, a surowe odpowiedzi zostały zachowane. Uwaga dotycząca czasu działania: narzędzie bezpośrednio wywołuje funkcje pobierania danych i Bedrock, natomiast aplikacja online najpierw kieruje żądania przez AppSync i Lambda. Kod OKF poddawany testom to rzeczywisty kod aplikacji, natomiast transport nie jest nim, więc porównania czasowe dotyczą dwóch rozwiązań mierzonych w ten sam sposób i nie odzwierciedlają tego, co zobaczyłby użytkownik przeglądarki.

Zamiana: jeden Lambda

Chatbot Amplify udostępnia narzędzia jako narzędzia danych Amplify, z których każde to Lambda działające za zapytaniem GraphQL, a Bedrock Flow był jednym z nich. Zmiana polega więc na dodaniu drugiego narzędzia, askOkf, które odpowiada na podstawie zweryfikowanego pakietu zamiast Flow. Schemat, interfejs użytkownika oraz proces wdrażania pozostają bez zmian.

// amplify/functions/askOkf/handler.ts — the essence
export const handler: Schema["askOkf"]["functionHandler"] = async (event) => {
   // in-process TF-IDF over the bundle
  const hits = search(event.arguments.question, 3);
  const top = hits[0];

  // Grounded-or-refuse: below the score floor,
  // nothing verified matches → refuse
  // before ever calling the model.
  if (!top || top.score < MIN_SCORE) {
    return { answer: refusal().text, citation: "", grounded: false, mode };
  }

  // read the verified figure straight from frontmatter
  if (mode === "extractive") {
    // 0 model calls - sub-millisecond
    const a = extractiveAnswer(hits);
    return { answer: a.text, citation: a.citations[0] ?? "", grounded: true, mode };
  }

  // generative: ground Claude on the ONE retrieved concept,
  // safety-prompted grounded-or-refuse
  const concept = top.concept;
  const context = `Concept: ${concept.label}\nSource: ${conceptSource(concept.frontmatter)}\n\n${concept.text}`;
  const response = await bedrock.send(
    new ConverseCommand({
      modelId: env.MODEL_ID,
      // grounded-or-refuse; declines medical-advice intent
      system: [{ text: SYSTEM_PROMPT }],
      messages: [{ role: "user", content: [{ text: `Verified concept:\n${context}\n\nQuestion: ${question}` }] }],
      inferenceConfig: { maxTokens: 400, temperature: 0 },
    })
  );
  const text = response.output?.message?.content?.[0]?.text ?? "";
  return { answer: `${text}\n\nSource: ${citation}`, grounded: true, mode };
};

Wewnątrz obsługiwacza funkcja search() przeszukuje cztery zweryfikowane pliki Markdown dostarczone razem z Lambda. Nie jest potrzebna żadna baza danych wektorowych, żaden serwis embeddingów ani żadna podróż sieciowa w obie strony. Uwzględniane są tylko te koncepcje, które przeszły weryfikację, co oznacza, że ktoś przeprowadził analizę i sprawdził wyniki. Kusząca, błędna wartość, czyli nieuwzględniająca wag całkowitego próbki wskaźnik insuliny wynoszący 3,66%, nie występuje w żadnym z tych plików, więc nigdy nie może zostać udostępniona.

Dostarczane są dwie ścieżki, a benchmark mierzy obie. Ścieżka ekstrakcyjna odczytuje zweryfikowaną wartość z frontmatter bez żadnych wywołań modelu. Ścieżka generatywna wykonuje jedno wywołanie funkcji Converse.

Baza odniesienia: prawdziwy RAG wektorowy

Przeciwnik musiał być silny. Jest to zarządzana baza wiedzy Bedrock na S3 Vectors, która przechowuje prawdziwe materiały CDC 2023 NHIS: opis ankiety, kodownik dla dorosłych, raporty podsumowujące i metodologiczne, notatkę techniczną dotyczącą imputacji oraz dokument README z informacjami o wagach par. Kompetentny inżynier zbudowałby dokładnie to. Ponieważ model jest identyczny, jedyną pozostałą zmienną jest to, skąd pochodzi odpowiedź – czy to z magazynu wektorów, czy z spakowanego pliku wewnątrz funkcji.

Zostało przesłanych trzynaście plików, a dziesięć zostało skatalogowanych. Wszystkie trzy niepowodzenia dotyczyły archiwów .zip, które Bedrock odrzuca, i były to akurat surowe dane mikro. Może to brzmieć jak lukowa regulacja ratująca bazę wektorową, ale tak nie jest. Każdy dokument opisujący zmienne związane z cukrzycą został prawidłowo skatalogowany. Brakuje natomiast surowych wierszy, a wyszukiwanie w tych surowych wierszach i tak nie mogłoby dać tych wyników, ponieważ odsetek ważony badaniami wśród 29 522 rekordów z uniwersum opartym na wzorcu pomijania to obliczenie, a nie fragment tekstu. Nie można do niego dotrzeć poprzez dzielenie na części.

Kolejna szczera obserwacja: strona oparta na wektorach była ta tańsza. Przygotowanie tuzina dokumentów oraz bazy wiedzy zajęło zaledwie kilka minut. Strona OKF wymagała rzeczywistej pracy – modelowania koncepcji i przeprowadzania analizy mikrodanych w celu weryfikacji każdej liczby. Błędne przekonanie, że szybkość wyszukiwania oznacza rozwiązanie problemu dokładności, jest samo w sobie błędem. Tanie rozwiązania i wysoka dokładność to odrębne problemy, a łatwość obsługi jest powodem, by zachować bazę danych wektorową, a nie usunąć ją.

Dokładność

Zestaw pytań składał się z pytań liczbowych z znanych, zweryfikowanych odpowiedziami, trzech pytań testujących odrzucenie odpowiedzi oraz jednego pytania metodologicznego. Oceny przeprowadzano według z góry ustalonej skali – 30 prób na każde pytanie liczbowe i dwie na każde pytanie testujące, przy czym wszystkie wyniki były odnotowywane. We wszystkich trzech pytaniach liczbowych system RAG wektorowy nie był w stanie uzyskać żadnej z zweryfikowanych odpowiedzi w żadnej z prób.

Czas reakcji

W przypadku zadań ilustracyjnych z 30 próbami każde (próby początkowe to te od 2 do 30), ścieżka generatywna OKF okazała się 1,4 do 2,4 raza szybsza, ponieważ pomija krok pobierania danych przez sieć i pracuje z znacznie mniejszym kontekstem. Ścieżka ekstraktywna jest niemal natychmiastowa, gdyż w ogóle nie wywołuje się żadnego modelu. Należy brać pod uwagę rozrzut, a nie średnią: różnica jest największa w przypadku insuliny, wynosząc około 2,4 raza, a najmniejsza w przypadku wieku, około 1,4 raza, gdzie oba wyniki są niemal identyczne; dlatego wiersze przedstawiające wyniki dla poszczególnych zadań są ostatecznym rezultatem, a nie pojedynczym współczynnikiem ogólnym. Szybkość i tak nie jest decydującym czynnikiem. Czas 3,3 do 3,7 sekundy dla bazy wiedzy jest przyzwoity, a model traci na dokładności, a nie na czasie.

Wynik: pobieranie danych versus kompilacja

W każdym z badań system RAG nie był w stanie dostarczyć żadnych z zweryfikowanych danych, a kiepska konstrukcja nie jest tu wyjaśnieniem. Te liczby po prostu nie występują w dokumentach. Wartość 31,96% uzyskana na podstawie analizy próbek pochodzi z mikrodanych, przy użyciu prawidłowej populacji i wag, lecz nie występuje w żadnym pliku PDF. System wyszukiwania może zwrócić jedynie istniejący tekst. OKF potrafi udzielić odpowiedzi, ponieważ dane zostały obliczone i sprawdzone z góry, natomiast baza wiedzy nie ma nic do dostarczenia.

Zauważmy, jak zawodzi baza wiedzy: twierdzi, że nie może znaleźć tej wartości procentowej w dokumentach, i nie wymyśla żadnej liczby. To uczciwe i dodatkowo wzmacnia argument. Nawet dobrze zaprojektowany system RAG jest strukturalnie niezdolny do odpowiedzi na pytania dotyczące statystyk obliczonych na podstawie dokumentacji.

Tutaj pojawiają się jeszcze dwa błędne przekonania.

• Ugruntowanie nie gwarantuje poprawności. Ta baza wiedzy odrzucała dane i nie tworzyła ich z niczego, ale to kwestia dobrych domyśleń, a nie właściwość RAG. Model nieco bardziej chętny lub dokument streszczający, który przypadkowo zawierał nieuwzględnioną częstotliwość, mogłyby dostarczyć niepewną, błędną liczbę.
• Cytat niewiele dowodzi. Link do źródła informuje o pobraniu dokumentu, ale nie o tym, że odpowiedź wynika z niego. Cytat OKF to coś zupełnie innego, ponieważ wskazuje na wartość obliczoną na podstawie danych i zweryfikowaną podczas budowania modelu, a nie na tekst znajdujący się obok podobnego zdania.

Lepsze instrukcje i dodatkowe fragmenty tekstu nie naprawią tego problemu. Rozwiązaniem jest zaprzestanie pobierania tych liczb i ich skompilowanie.

Ograniczenia i kompromisy OKF

OKF nie jest uniwersalnym silnikiem odpowiedzi, a testy pokazują, gdzie się kończy jego możliwości.

Odpowiada na pytanie „ile”, a nie „dlaczego”. W przypadku jakościowego pytania o to, w jaki sposób ważenie ankiet wpływa na częstość występowania, wektor RAG dostarczył bogatą, uzasadnioną odpowiedź bezpośrednio z opisu ankiety, podczas gdy zestaw OKF oparty na czterech koncepcjach mógł dostarczyć jedynie powiązaną liczbę. Zestaw z zweryfikowanymi danymi jest dokładny jeśli chodzi o obliczone statystyki, ale milczy na temat narracji. To jest granica, a nie wada, i wskazuje bezpośrednio na architekturę poniżej.

Szybkość oznacza brak oceniania. Ścieżka ekstrakcyjna odpowiada w mniej niż milisekundę, ale przy prośbie o radę medyczną zwraca jedynie „31,96%”, ponieważ nie potrafi odczytać, czego szuka użytkownik. Ścieżka generatywna odrzuca taką radę i podaje dane demograficzne, wyraźnie ostrzegając, że nie mają one zastosowania do sytuacji konkretnego osoby. Ta zdolność rozróżniania kosztuje jedną próbę przetworzenia modelu, około dwóch sekund. Traktuj natychmiastową odpowiedź oraz ścieżkę świadomą intencji jako oddzielne narzędzia i raportuj obie, nie łącząc ich ze sobą.

Dopowiedzenie: trzecie narzędzie

Te ograniczenia prowadzą do jednego wniosku. OKF dostarcza zweryfikowaną warstwę danych, natomiast baza wektorowa doskonale radzi sobie z warstwą jakościową, narracyjną, do której OKF nie ma dostępu. Rozsądny projekt wykorzystuje obie te warstwy jako odrębne narzędzia, z których agent może wybierać.

Agent oparty na faktach używa już w tym celu dwóch narzędzi, obu zweryfikowanych, działających w trakcie przetwarzania i ograniczonych do danych agregowanych: wyszukiwania pojęć (search_okf) oraz zapytania do danych agregowanych z listą dozwolonych wartości (analyze_rows). Każde z nich zwraca tylko to, co może potwierdzić. Baza wiedzy Bedrock stanowi trzecie narzędzie, wyraźnie oznaczone jako narracja niezweryfikowana. Agent następnie podaje zweryfikowaną wartość w przypadku pytań liczbowych, tekst opisowy w przypadku wyjaśnień, a w sytuacji, gdy żadne z tych rozwiązań nie jest odpowiednie, odmawia odpowiedzi, trzymając te trzy elementy oddzielnie.

To rozdzielenie to również właściwe wykorzystanie zasobów. Kilka minut na bazę wiedzy, godziny na zestaw danych zweryfikowanych. Pozyskuj narracje tanio i wkładaj wysiłek tylko tam, gdzie wartość musi być dokładna: nie kompiluj tego, co dostajesz za darmo poprzez wyszukiwanie, i nie wyszukuj tego, co musisz zweryfikować.

Przegląd powiązanego wyniku

Umieszczając cztery narzędzia w jednym agencie (sprawdzane, obliczane, pobierane i aktualne), pojawia się naturalne pytanie: czy większy model zapewnia prawidłowe funkcjonowanie tych mechanizmów? Trzem modelom pokazano sfałszowany tytuł wiadomości z wymyśloną statystyką, a wszystkie trzy powtórzyły tę liczbę we wszystkich dziewięciu próbach, określając ją jako niepotwierdzone twierdzenie z zewnętrznej źródła. Mimo to informacja ta za każdym razem docierała do czytelnika. Tylko sprawdzenie pochodzenia danych, wdrożone w kodzie, powstrzymywało to we wszystkich dziewięciu przypadkach. Wybrany model nie miał wpływu na bezpieczeństwo.

To zmienia sposób interpretacji tego benchmarku. Sprawdzony zestaw dostarcza właściwą liczbę, co stanowi połowę zadania. Druga połowa polega na zapobieganiu rozpowszechnianiu błędnych danych pod tym samym etykietą, a to zależy od kodu, a nie od modelu.

Aktywne i niezależnie sprawdzone

Żadna z tych informacji nie została zachowana na laptopie. askOkf został uruchomiony w rzeczywistym środowisku testowym Amplify (Cognito, AppSync, Lambda) i udzielił odpowiedzi „31,96% osób obecnie przyjmuje insulinę” wraz z odniesieniem, odrzucając jednocześnie pytanie dotyczące porad medycznych, działając pod prawdziwą rolą IAM. Przed tym niezależna ocena bezpieczeństwa przeanalizowała kod źródłowy i stwierdziła contract-satisfied: zapytanie wymaga autoryzacji, uprawnienie bedrock:InvokeModel ma zasadę najmniejszych uprawnień i jest ograniczone do jednego modelu, nic nie może zostać wstrzyknięte, a każde żądanie obejmuje tylko jedną, ograniczoną liczbą wywołań modelu.

Uwaga na temat modeli: Bedrock właśnie oznaczył Claude 3 Sonnet jako model starszy, więc zarówno OKF Lambda, jak i benchmark używają Claude Sonnet 4.5. To identyczność modeli po obu stronach sprawia, że porównanie jest sprawiedliwe.

Wniosek

Baza danych wektorowych jest oczywistym wyborem i zasługuje na swoje miejsce w przypadku otwartych, jakościowych pytań. Gdy chatbot musi podać konkretną wartość, taką jak wskaźnik rozpowszechnienia, KPI, kwota przychodów lub próg zgodności, wyszukiwanie nie jest odpowiednim narzędziem, ponieważ wiarygodna wersja tej wartości została obliczona, ale nigdy nie została zapisaana w formie tekstu. RAG albo jej nie znajdzie, co jest uczciwe, albo ją wymyśli, co nie jest takie. OKF oblicza tę wartość, sprawdza ją w odniesieniu do źródła podczas tworzenia i dostarcza ją – cztery pliki markdown w formacie Lambda, bez konieczności konfiguracji, dostępne od razu przy każdym próbnym użyciu.

Dziesięć dokumentów nie stanowiło problemu. Problemem była brakująca liczba, a dalsze uzupełnianie bazy nie miało szans jej dostarczyć. Oblicz swoje liczby.

Literatura pokrewna

• Jak działa RAG: Embeddingi, bazy danych wektorowych i dzielenie na fragmenty: Prześledź jeden fragment tekstu od tokenizacji, przez proces agregacji, aż po wyszukiwanie za pomocą podobieństwa kosinowego i zobacz, dlaczego dzielenie na fragmenty oraz modele embeddingów decydują o jakości RAG.
• Znaczenie jako współrzędne: Od embeddingów do baz danych wektorowych i RAG: Proste omówienie embeddingów zdań, podobieństwa kosinowego, baz danych wektorowych oraz cyklu RAG, z czterema krótkimi zdaniami o psach, kotach i Paryżu pokazującymi, jak funkcjonuje wyszukiwanie na podstawie znaczenia.