---
title: "Wyszukiwanie w ontologii wygrywa z wyszukiwaniem w dokumentach"
url: "https://hurukan.com/pl/blog/wyszukiwanie-w-ontologii-nie-w-dokumentach"
description: "Wyszukiwanie w stosie dokumentów znajduje tekst, który wygląda na trafny. Wyszukiwanie w modelu firmy znajduje fakty, które są prawdziwe teraz, razem z ich relacjami."
---

# Wyszukiwanie w ontologii wygrywa z wyszukiwaniem w dokumentach

7 września 2026·3 min czytania·Redakcja

Uporządkowane szare regały z opisanymi segregatorami w nowoczesnym archiwum, jeden segregator z niebieskim grzbietem do połowy wysunięty i sięgająca po niego dłoń, mała głębia ostrości

Firma podłącza model językowy do swojego repozytorium dokumentów: umów, procedur, polityk, notatek ze spotkań z wielu lat. To generowanie wspomagane wyszukiwaniem, w skrócie RAG: kiedy ktoś zadaje pytanie, system znajduje fragmenty najbardziej do niego podobne i przekazuje je modelowi, żeby na ich podstawie odpowiedział.

Pracownik obsługi klienta pyta, jakie warunki dostawy ma konkretny klient. System znajduje trzy wersje umowy z tym klientem, szkic aneksu, którego nigdy nie podpisano, i maila, w którym ktoś zaproponował inne warunki. Model łączy je w płynną, pewną siebie odpowiedź, która nie zgadza się z żadnym z nich. Innego dnia znajduje ogólne warunki firmy zamiast aneksu dla tego klienta, który je zastępuje.

Przyczyną jest sposób działania wyszukiwania w dokumentach. Znajduje ono tekst, którego znaczenie przypomina pytanie. Nie wie, która wersja obowiązuje, który dokument jest szkicem, którego klienta dotyczy dany zapis ani że aneks ma pierwszeństwo przed ogólnymi warunkami. To nie są cechy tekstu. To stany i relacje, czyli dokładnie to, do czego służy model firmy, ontologia.

## Gdzie zawodzi wyszukiwanie w dokumentach

**Wersje.** Nieaktualna umowa jest tak samo podobna do pytania jak obowiązująca, więc wyszukuje się ją równie chętnie. Podobieństwo nie zna pojęcia „obowiązuje”.

**Relacje zgubione przy cięciu.** Przed indeksowaniem dokumenty dzieli się na fragmenty. Zapis o warunkach dostawy trafia do jednego fragmentu, strona z nazwą klienta do drugiego, a związek między nimi znika.

**Pytania, które są tak naprawdę liczeniem.** „Ile otwartych reklamacji ma ten klient?” nie jest zapisane w żadnym dokumencie. To liczba policzona na rekordach i żadne podobieństwo tekstu nie da jej wiarygodnie.

**Uprawnienia stosowane za późno.** Jeśli indeks zawiera dokumenty, których pytający nie może zobaczyć, odfiltrowanie ich po wyszukaniu jest kruche, a pomyłka pokazuje poufny tekst niewłaściwej osobie.

**Aktualność.** Indeks jest tak aktualny jak jego ostatnia przebudowa. Umowy podpisanej dziś rano jeszcze w nim nie ma.

**Cytaty, które niczego nie rozstrzygają.** Odpowiedź cytuje fragment, ale nic nie mówi czytelnikowi, czy pochodzi z dokumentu, który teraz obowiązuje.

## Najpierw szukaj w modelu, potem w dokumentach

**Zacznij od obiektu.** Pytanie wymienia klienta. Zamień to na obiekt klienta w ontologii, a potem idź po jego relacjach: obowiązujące umowy, ich aneksy, otwarte zamówienia, otwarte reklamacje. Model firmy zawęża to, czego podobieństwo zawęzić nie umie.

**Przeszukuj dokumenty przypięte do rekordów.** Obowiązująca umowa to dokument przypięty do rekordu umowy o statusie „obowiązuje”. Wyszukiwanie tekstu działa potem w tym dokumencie, a nie we wszystkim, co firma kiedykolwiek napisała.

**Na pytania o strukturę odpowiadaj zapytaniami.** Liczby, sumy, daty i statusy pochodzą z rekordów, policzone, a nie z fragmentów, które akurat o nich wspominają.

**Stosuj uprawnienia przed wyszukiwaniem.** Uprawnienia osoby decydują, które obiekty są w ogóle widoczne. Model nigdy nie dostaje reszty, więc nie może jej ujawnić.

**Cytuj rekord i wersję.** Odpowiedź prowadzi do rekordu umowy, jej wersji i konkretnego zapisu, więc człowiek sprawdza ją jednym kliknięciem.

Wyszukiwanie w dokumentach nadal przydaje się do wiedzy, która naprawdę mieszka w prozie: procedur, instrukcji, zgromadzonego doświadczenia. Nawet tam działa lepiej, gdy każdy dokument jest przypięty do obiektów, które opisuje, tak żeby wyszukiwanie mogło zacząć od właściwego miejsca.

Tak jest projektowany Hurukan. Każdy dokument jest przypięty do swojego rekordu, z wersjami i przeglądami, jak opisuje strona [Projekty i dokumenty](https://hurukan.com/pl/modules/projekty-i-dokumenty). Warstwa [Ontologia](https://hurukan.com/pl/system/ontologia) trzyma obiekty, relacje i stany, a warstwa [Superinteligencji](https://hurukan.com/pl/system/superinteligencja) jest projektowana tak, żeby opierać modele najpierw na tej strukturze, z już zastosowanymi uprawnieniami. System jest w budowie. Skąd w ogóle bierze się taki model, opisuje tekst [Twoja firma ma już ontologię](https://hurukan.com/pl/blog/twoja-firma-ma-juz-ontologie).

## Test na dziś

Zbierz dziesięć pytań, które Twoi pracownicy naprawdę zadali w tym miesiącu o klientów, zamówienia, dostawców albo umowy. Przy każdym zapisz, gdzie naprawdę mieszka poprawna odpowiedź:

-   w jednym dokumencie,
-   w kilku dokumentach, które trzeba połączyć,
-   w rekordzie,
-   albo w liczbie lub sumie po wielu rekordach.

Potem zadaj te same dziesięć pytań obecnemu systemowi wyszukiwania w dokumentach, jeśli go masz, i sprawdź każdą odpowiedź z prawdziwym źródłem.

Zanotuj, gdzie pojawia się zła wersja, zły klient albo zmyślona liczba. Jeśli błędy skupiają się we wszystkich kategoriach poza „jednym dokumentem”, znalazłeś granicę wyszukiwania w dokumentach, i jest to granica projektu, a nie modelu. Szersze pytanie o to, gdzie modele językowe pomagają, a gdzie nie, omawia tekst [gdzie duże modele językowe naprawdę zarabiają na siebie](https://hurukan.com/pl/blog/gdzie-modele-jezykowe-zarabiaja-na-siebie).

-   RAG
-   wyszukiwanie
-   ontologia
-   zarządzanie wiedzą

## Czytaj dalej

-   [Jedna tożsamość dla ludzi i agentów: kto co może](https://hurukan.com/pl/blog/jedna-tozsamosc-dla-ludzi-i-agentow)
-   [Stan bieżący i zapis: dwie pamięci systemu operacyjnego firmy](https://hurukan.com/pl/blog/stan-biezacy-i-zapis-dwie-pamieci-systemu-operacyjnego-firmy)