RAG nad bazą wiedzy z 500 tys. rekordów gry
Asystent AI do World of Warcraft, który odpowiada na podstawie realnych danych z Wowhead — rozmowa z dużą, ustrukturyzowaną bazą, gdzie każda liczba jest osadzona w pobranym źródle, a nie w pamięci modelu.
- Stack
- Python · LangChain · PostgreSQL · pgvector · FastAPI
- Skala
- 500 tys.+ rekordów gry
- Retrieval
- hybrydowy — dense + BM25 + reranking
Ustrukturyzowane dane gry są wrogie naiwnemu RAG
Dane World of Warcraft są strukturalnie wrogie standardowemu RAG. Zapytanie w rodzaju „najlepszy sposób na farmienie Frostweave Cloth” wymaga skrzyżowania ID przedmiotów, tabel dropu w strefach, czasów respawnu mobów i historii wersji patchy — a wszystko to w różnych schematach na Wowhead. Nie istnieje jeden fragment, który na to odpowiada.
Naiwne wyszukiwanie po embeddingach zwraca tekst najbardziej podobny semantycznie, a nie najbardziej przydatną odpowiedź. Podnosi wszystko, co wspomina o farmieniu cloth, i gubi konkretną tabelę dropu, o którą naprawdę chodzi. Gdy poprosić o liczbę, jest jeszcze gorzej: model podaje drop rate z pamięci — pewnie i precyzyjnie, i błędnie.
Dwuetapowy retrieval: najpierw encja, potem wyszukiwanie
Rozdzieliliśmy retrieval na dwa etapy. Etap pierwszy to entity resolution: zapytanie jest parsowane, by wyciągnąć nazwy przedmiotów, stref i mechanik, a następnie zmapować je na kanoniczne ID przez ustrukturyzowany lookup. Etap drugi to wyszukiwanie semantyczne po pofragmentowanej treści poradników, filtrowane tymi ID jako ograniczeniami w metadanych.
Dzięki temu „farm Frostweave” najpierw znajduje właściwy przedmiot, a potem pobiera tylko te poradniki i tabele dropu, które odnoszą się do tego konkretnego przedmiotu — a nie wszystko, co przy okazji wspomina o cloth. Sam retrieval jest hybrydowy: wektory dense i BM25 łączone, a następnie reranking, więc do finalnego kontekstu liczą się zarówno trafienia po dokładnej nazwie, jak i semantyczne.
Każda liczba jest weryfikowana względem źródła
Jeśli model wygeneruje drop rate z pamięci, a nie z pobranych danych, odpowiedź jest błędna i podana z pełną pewnością. Dlatego każda liczbowa deklaracja — procent dropu, czas respawnu, wymagany poziom reputacji — jest weryfikowana względem źródłowego chunku, zanim odpowiedź trafi do użytkownika. Deklaracja bez możliwego do pobrania źródła jest pomijana albo oznaczana jako niezweryfikowana, nigdy wygładzana.
Odpowiedzi cytują konkretne odwołania do stron Wowhead, wersję patcha i znacznik czasu zebrania danych stojące za każdym faktem, więc użytkownik dokładnie wie, jak aktualna jest informacja i skąd pochodzi.
Utrzymanie bazy aktualnej, gdy gra się zmienia
Baza wiedzy o grze nie jest statyczna — każdy patch przetasowuje drop rate'y, strefy i mechaniki. Pipeline ingestii przetwarza dane z Wowhead w sposób ciągły, wersjonuje chunki, gdy patch je zmienia, i oznacza nieaktualną treść, zanim dotrze ona do retrievalu, tak by stara odpowiedź nie wróciła po cichu jako aktualna.
Ten wzorzec się uogólnia. Każda firma siedząca na dużej, ustrukturyzowanej bazie — katalogach, specyfikacjach, politykach, danych operacyjnych — spotyka ten sam tryb awarii, gdy postawi przed nią LLM: płynne odpowiedzi subtelnie błędne w liczbach, i dlatego koszt błędnej odpowiedzi rozstrzyga, ile kontroli trzeba dobudować. Dwuetapowy retrieval, hybrydowe wyszukiwanie, walidacja każdej deklaracji i wersjonowana ingestia to właśnie to, co zamienia „rozmowę z danymi” w odpowiedzi, na których zespół naprawdę może polegać — każde z nich doszło dlatego, że coś prostszego wcześniej pękło, co rozkładamy w tekście o tym, jak RAG dla firmy zachowuje się przy 500 tys. rekordów.
Zobacz, jak wyglądałoby to w Twoich procesach.
30 minut · wskazujemy 3 najlepsze obszary do automatyzacji · bez zobowiązań