Naprawa systemu RAG za pomocą ontologii i grafu wiedzy w dokumentacji półprzewodnikowej
Dokumentacja EDA dla półprzewodników została wyposażona w ontologię RDF/OWL, graf wiedzy Neo4j oraz mechanizm wyszukiwania ograniczony ontologią, co pozwoliło zmniejszyć liczbę dodatkowych pytań typu RAG o 30 procent.
Źródła: How I Built a Semantic Layer to Ground Our RAG System…And Why Ontology Was the Missing Piece
Gdzie zwykły RAG zawodzi
Pierwszy prototyp generowania wzbogaconego o wyszukiwanie na podstawie dokumentacji produktowej zazwyczaj wygląda obiecująco. Wchodzi magazyn wektorowy, dokumenty są dzielone na fragmenty, wykonywane są kilka zapytań, a odpowiedzi brzmią wiarygodnie. Następnie inżynier ds. weryfikacji pyta, jaką metodologię zastosować do weryfikacji uwzględniającej zużycie mocy w danym bloku, a system z pełną pewnością siebie odpowiada o metodologii weryfikacji funkcjonalnej. Treść jest dokładna według własnych kryteriów, ale błędna w odniesieniu do postawionego pytania.
Powodem jest słownictwo. W weryfikacji półprzewodników „metodyologia” nie jest słowem codziennym. Odnosi się do konkretnych podejść weryfikacyjnych, z których każde jest powiązane z określonymi narzędziami, etapami oraz artefaktami wykonania. System wyświetlił tekst, ale nie wiedzę. To sprawia, że chodzi o problem znaczenia, a nie o problem wyszukiwania, i lepszy model embeddingów tego nie naprawi. Warstwa semantyczna tak. Poniżej opisano, jak taką warstwę projektuje i buduje dla zestawu dokumentacji EDA: ontologię, graf wiedzy, połączenie z RAG oraz uzyskane wyniki.
Dokumentacja jako pustynia wiedzy
Chodzi o oprogramowanie do weryfikacji na poziomie przedsiębiorstw, zawierające tysiące tematów w formacie DITA XML z różnych linii produktowych, obejmujących konfigurację narzędzi, procesy wykonywania zadań oraz wskazówki metodologiczne. Materiały te istnieją, ale są w formie zwykłego tekstu, a nie ustrukturyzowanej wiedzy. Etapy weryfikacji, metodyki oraz narzędzia znajdują się w oddzielnych dokumentach i są ze sobą powiązane jedynie tym, co czytelnik już wie. Do pracy nad tym poradzi sobie doświadczony inżynier z dziesięcioletnim doświadczeniem, natomiast sztuczna inteligencja szukająca odpowiednich informacji błądzi po polu minowym.
Celem było rozwiązanie, które jednocześnie spełnia kilka potrzeb: RAG, wyszukiwanie w przedsiębiorstwach, odkrywanie treści oraz długoterminowe zarządzanie treściami.
Najpierw sformułowanie problemu
Przed napisaniem jakiegokolwiek kodu ontologicznego upłynęły tygodnie rozmów z menedżerami produktów, ekspertami od weryfikacji, kierownikami dokumentacji, inżynierami wyszukiwania oraz zespołem nauk danych odpowiedzialnym za asystenta GenAI. Te rozmowy kierowały trzy pytania.
Pierwsze brzmiało: jakie wyniki biznesowe są ważne? Odpowiedziami była lepsza dokładność wyszukiwania, kanoniczna warstwa podstawowa dla asystentów opartych na modelach językowych oraz zintegrowane dane w całej gamie produktów. Drugie pytanie brzmiało: jak wygląda obecnie niepowodzenie? Wyszukiwanie według słów kluczowych zwraca nieistotne wyniki, użytkownicy wysyłają dodatkowe zapytania, ponieważ pierwsza odpowiedź nie uwzględniała kontekstu, a ręczne łączenie treści nie nadąża za potrzebami. Trzecie pytanie brzmiało: jak wyglądałby sukces? System wyszukiwania powinien rozumieć, że zapytanie dotyczące dynamicznej weryfikacji projektów zarządzanych energią wymaga treści powiązanych z określoną metodologią, na określonym etapie weryfikacji, z użyciem konkretnych narzędzi, a nie po prostu dowolnego dokumentu zawierającego te słowa kluczowe.
To podstawowe działanie zapobiega nadmiernemu rozrostowi ontologii, czyli nawyku modelowania wszystkiego, co wydaje się intelektualnie interesujące, zamiast tego, czego potrzebuje biznes.
Odkrywanie koncepcji i projektowanie ontologii
Projektowanie ontologii zaczyna się od odkrywania wiedzy, a nie od narzędzi takich jak Protégé czy pliki Turtle. Służyły temu cztery źródła danych:
- Wywiady z inżynierami weryfikacji, którzy opisali, jak postrzegają relacje między narzędziami, kolejność wykonywania zadań oraz punkty decyzyjne, co różni się od sposobu działania tych narzędzi
- Istniejąca dokumentacja oraz interfejsy narzędzi, których powtarzające się terminy ujawniły koncepcje pozostające stabilne od lat
- Łogi, pliki konfiguracyjne oraz definicje procesów, które pokazały rzeczywiste powiązania między narzędziami, etapami i wynikami, często sprzeczne z dokumentacją
W rezultacie powstał podstawowy zestaw stabilnych koncepcji domeny, co w praktyce stanowiło taksonomię, która została najpierw celowo zapisana w Excelu. Praca nad ontologią jest współpracowa, a osoby, które muszą sprawdzić model – eksperci od danej dziedziny i menedżerowie produktów – nie potrafią czytać języka Turtle. Arkusz kalkulacyjny umożliwia im weryfikację i udoskonalanie modelu oraz budowanie wspólnego zrozumienia, na długo przed rozpoczęciem formalnego kodowania.
Gdy model został ustalony po kilku rundach przeglądów, sformalizowano go przy użyciu standardów sieci semantycznej:
- RDF przedstawia każdą entytetę i związek jako trójki
- OWL dostarcza hierarchie klas, ograniczenia właściwości oraz reguły logiczne
- SKOS standaryzuje terminologię w różnych liniach produktowych za pomocą kontrolowanych słowników
- Schematron sprawdza poprawne używanie ontologii podczas tworzenia w Oxygen XML
Sama ontologia znajduje się w plikach TTL, natomiast reguły Schematron są bezpośrednio integrowane z środowiskiem tworzenia. Dzięki temu autorzy nie mogą wprowadzać koncepcji, które naruszają strukturę ontologii, więc zarządzanie nią jest częścią procesu pracy, a nie czymś dodanym później. Każde mapowanie jest egzekwowane za pomocą metadanych prolog w plikach DITA XML oraz słowników kontrolnych, bez możliwości używania swobodnych tagów i bez zasady „wystarczy w przybliżeniu.”
Architektura grafu wiedzy
Ontologia potrzebuje miejsca do przechowywania, grafu, który można wyszukiwać i przemierzać. Projekt jest podzielony na warstwy:
- Warstwa schematu: definicje ontologii w plikach TTL
- Warstwa terminologii: słownik oparty na SKOS
- Warstwa instancji: trojki RDF tworzone na podstawie metadanych treści
- Warstwa infrastruktury: Neo4j do przechowywania i wyszukiwania
Wokół tych warstw znajdują się pipeline’y do przetwarzania semantycznego, które przekształcają stworzony treść w triple gotowe do użycia w grafie i ładowają je do Neo4j, API do wyszukiwania i pobierania danych, które udostępniają ten graf użytkownikom, takim jak pipeline RAG, oraz infrastruktura chmurowa Azure zapewniająca skalowalność i integrację z istniejącymi usługami platformy.
Pipeline od tworzenia treści do tworzenia grafu sprawia, że to rozwiązanie wykracza poza zwykłe ćwiczenia z ontologiami. Autorzy piszą teksty w formacie DITA przy użyciu Oxygen XML. Schematron sprawdza, czy metadane są zgodne z wymogami ontologii, podczas pisania. Treść jest publikowana za pośrednictwem Adobe Experience Manager. Metadane semantyczne przetrwają całą tę ścieżkę w nienaruszonym stanie i zostaną zaimportowane do Neo4j, gdzie systemy do wyszukiwania, analizy i sztucznej inteligencji mogą z nich korzystać. Chodzi o pełną kontrolę architektoniczną nad całym przepływem danych, od narzędzia do tworzenia treści, przez graf, aż po warstwę API.
Łączenie warstwy semantycznej z RAG
Tutaj wkład wysiłku przynosi owoce. Standardowy RAG dzieli dokumenty na fragmenty, wstawia te fragmenty, przechowuje je w bazie danych wektorowej, wyszukuje według podobieństwa i przekazuje uzyskane wyniki do modelu LLM. To działa, ale jest ślepy na znaczenie, a powtarzają się trzy rodzaje awarii:
- Zamieszanie kontekstowe, gdy system wyszukiwania znajduje właściwy pojęcie w niewłaściwym kontekście, podobnie jak opisany wcześniej brak zgodności na etapie weryfikacji
- Niezgodność słownictwa, gdy inżynierowie używają skrótów, a dokumentacja formalnych terminów, przez co pomijany jest istotny treść
- Halucynacje spowodowane niejednoznacznością, gdy niejasne terminy w fragmencie pozwalają modelowi LLM wypełniać luki wiarygodną, ale błędną wiedzą z danej dziedziny
Dzięki temu, że graf wiedzy pełni rolę warstwy podstawowej, proces wyszukiwania zmienia się na cztery sposoby.
Zasady ontologii określają, co może zostać odzyskane. Gdy zapytanie wymienia metodologię weryfikacji, system najpierw sprawdza ten termin w ontologii, a następnie ogranicza wyszukiwanie do treści oznaczonych tą metodologią oraz jej ważnymi relacjami. Wyszukiwanie wektorowe nadal odbywa się, ale tylko w semantycznie przefiltrowanej podgrupie danych.
Wprowadzony jest kanoniczny słownik. Zapytania użytkowników są najpierw mapowane na kontrolowane terminy przed odzyskiwaniem informacji, dzięki czemu „power-aware sim” zostaje przekształcone w formalny termin oznaczający symulację uwzględniającą zużycie energii, a odpowiednia treść jest przywracana niezależnie od sposobu sformułowania pytania przez inżyniera.
Każdy fragment tekstu odpowiada granicom ontologii, a nie stałej długości. Akapit opisujący rolę danego narzędzia na określonym etapie weryfikacji pozostaje nienaruszony i nie jest przerywany w środku myśli.
Nieważne kombinacje są filtrowane. Ontologia określa, które kombinacje narzędzi, metodologii i etapów są dopuszczalne, więc fragmenty wskazujące na nieważną kombinację są obniżane w priorytecie lub pomijane, zanim model LLM je zobaczy.
Korzyści były widoczne od razu. Odpowiedzi opierają się na zweryfikowanym, oznaczonym metadanymi ontologii treści, a nie na domysłach modelu dotyczących weryfikacji półprzewodników. Ograniczenie tego, co może zobaczyć model, wyeliminowało grupę halucynacji spowodowanych niejednoznacznym lub pozbawionym kontekstu wyszukiwaniem. Każdy pobrany fragment zawiera metadane ontologii, dzięki czemu system może wyjaśnić swój wybór: jaką entytetę, jaką relację, jakie ograniczenie. Ponadto procesy agentywne mogą przemieszczać się po grafie, aby planować wieloetapowe zadania weryfikacyjne na podstawie rzeczywistych relacji między entytetami, a nie tylko podobieństwa tekstowego.
Stack technologiczny
- Tworzenie treści: Oxygen XML z DITA
- Walidacja i zarządzanie: Schematron oraz Schematron Quick Fix
- Kodowanie ontologii: RDF, OWL i SKOS w plikach Turtle
- Graf wiedzy: Neo4j
- Publikowanie: Adobe Experience Manager
- Chmura: Microsoft Azure
- Integracja RAG: niestandardowe API do wyszukiwania łączące Neo4j z wyszukiwaniem wektorowym
- Szyna LLM: własny, korporacyjny asystent GenAI
Wyniki
Po wdrożeniu cztery wskaźniki pokazały efekty działania rozwiązania:
- Liczba zapytań powtórzonych spadła o 30%. Dokumentacja stanowi teraz dokładne źródło prawdy dla asystentów AI, dzięki czemu użytkownicy znacznie częściej otrzymują właściwą odpowiedź od razu. Był to kluczowy wskaźnik, ponieważ bezpośrednio odzwierciedla jakość wyszukiwania.
- Użycie treści wielokrotnie wzrosło o 25%. Dzięki tagom semantycznym i świadomości relacji ta sama treść może pojawiać się w różnych liniach produktowych bez konieczności tworzenia kopii ręcznie.
- Czas ręcznego tworzenia linków skurczył się o 60%. Funkcja „Powiązane treści” w AEM teraz działa na podstawie grafu, dzięki czemu linki wcześniej tworzone ręcznie są generowane na podstawie relacji ontologicznych. Samodzielna obsługa przez użytkowników również poprawiła się o 25%.
- Cykle ręcznej audytoryzacji treści skróciły się o 40%. Zasady Schematron pochodzące z ontologii wykrywają problemy w Oxygen podczas pracy autorów, dzięki czemu jakość jest kontrolowana na wczesnym etapie.
Lekcje dla podobnych projektów
Zamodeluj domenę przed wyborem technologii. Zespoły często od razu sięgają po Neo4j lub bazę danych wektorową, zanim jeszcze określą, jakie są ich entity i relacje. To jak budowanie domu bez narysowania planu. Poświęć początkowy czas na prace z ekspertami od danej dziedziny w arkuszu kalkulacyjnym. Choć nie wygląda to efektownie, to właśnie stamtąd pochodzi prawdziwa wartość.
Traktuj zarządzanie jako strukturę. Ontologia bez zarządzania szybko ulega degradacji, ponieważ każdy nowy autor, produkt lub szczególny przypadek podważa spójność. Wbuduj proces walidacji w workflow tworzenia treści, aby odbywała się automatycznie, zamiast poprzez okresowe audyty, które zawsze przychodzą za późno.
RAG bez semantyki to wyszukiwanie z dodatkowymi krokami. Podobieństwo wektorowe jest konieczne, ale nie wystarcza do skutecznego wyszukiwania w dużych systemach przedsiębiorstw. Gdy domena ma ustrukturyzowane relacje, hierarchie i ograniczenia, jak to ma miejsce w większości domen przedsiębiorstw, warstwa semantyczna przekształca proces wyszukiwania z znajdowania podobnego tekstu w znajdowanie istotnej wiedzy.
Mierz to, na czym zależy biznesowi. „Stworzyliśmy graf wiedzy” to nie jest wynik biznesowy. „Zapytania powtórne zmniejszyły się o 30%, ponieważ wyszukiwanie stało się dokładniejsze” – to już jest. Każda decyzja architektoniczna powinna być powiązana z metryką, którą cenią osoby spoza zespołu.
Co dalej
Szara warstwa jest fundamentem, a nie sufitem możliwości. Ontologia stale się rozwija – testowane, weryfikowane i łączone są nowe koncepcje bez niszczenia istniejącej semantyki – a postępy w narzędziach opartych na LLM, konwergencji grafów z sztuczną inteligencją oraz architekturze agentów mogą być budowane na jej bazie. Szerszy wniosek jest taki, że w pośpiechu ku GenAI najbardziej niedocenianą inwestycją nie jest lepszy model ani większe okno kontekstowe, lecz lepszy fundament semantyczny. Modele przychodzą i odchodzą, natomiast znaczenie trwa.
Literatura pokrewna
- Dlaczego agenci analityczne AI potrzebują warstwy semantycznej zamiast surowego SQL — Przekształcanie tekstu na SQL w surowych tabelach magazynowych prowadzi do tworzenia fałszywych metryk i ignorowania zasad dostępu. Zobacz, jak warstwa semantyczna takia jak Cube w połączeniu z MCP nadaje agentom spójne znaczenie biznesowe.
- Od prostego rozwiązania do gotowego systemu RAG do przetwarzania dokumentów SEC 10-K: dzielenie na fragmenty, wyszukiwanie hybrydowe — Dlaczego standardowy pipeline RAG zawodził przy 300-stronicowych dokumentach 10-K oraz jak to naprawić: dzielenie na fragmenty uwzględniające strukturę dokumentu, hybrydowe wyszukiwanie, ponowna sortowanie za pomocą cross-encodera, weryfikacja oraz odwołania do metadanych.