Wyszukiwanie semantyczne i embeddingi w firmie

Większość firmowych baz wiedzy przeszukuje się nadal pełnotekstowo: znajdź dokument zawierający te słowa. Działa, gdy pracownik zna terminologię. Nie działa, gdy klient pisze inaczej niż dokumentacja, gdy pytania dotyczą pojęć opisanych rozrzuconymi fragmentami albo gdy kilka działów nazywa ten sam proces różnie. Wyszukiwanie semantyczne rozwiązuje właśnie ten problem — bez przepisywania dokumentów.

Embedding to reprezentacja tekstu jako wektor liczb. Model embeddingów (sieć neuronowa wytrenowana na ogromnym korpusie) odwzorowuje każde zdanie w przestrzeń wielowymiarową tak, że zdania o podobnym znaczeniu lądują blisko siebie, a o różnym znaczeniu dalej. To nie jest wyszukiwanie po hashach ani po n-gramach — to geometria znaczenia.

Praktyczny efekt: zdanie „jak anulować zamówienie" i zdanie „procedura odstąpienia od umowy" trafiają do sąsiadujących punktów w przestrzeni, choć nie mają żadnego wspólnego słowa. Klasyczna wyszukiwarka pełnotekstowa te zapytania traktuje jako rozłączne. Silnik semantyczny traktuje je jako bliskoznaczne.

Mechanizm w skrócie:

1. Każdy fragment bazy wiedzy jest zamieniany na embedding raz (podczas indeksowania).
2. Zapytanie użytkownika jest zamieniane na embedding w czasie rzeczywistym.
3. Silnik oblicza podobieństwo kosinusowe między wektorem zapytania a wektorami dokumentów.
4. Zwraca fragmenty o najwyższej zbieżności semantycznej, niezależnie od użytych słów.

Wybór modelu embeddingów ma bezpośredni wpływ na jakość wyszukiwania, prędkość i to, czy dane w ogóle opuszczają Waszą infrastrukturę. Podstawowa zasada bezpieczeństwa: treści wewnętrzne (umowy, procedury, dane klientów) powinny być osadzane lokalnie, zanim cokolwiek trafi do zewnętrznego modelu generatywnego.

Korzystamy z BGE-M3 uruchamianego lokalnie przez Ollama. BGE-M3 produkuje 1024-wymiarowe wektory, obsługuje wielojęzyczność (w tym polski) bez potrzeby tłumaczenia zapytań i działa na CPU serwera firmowego — żadne treści nie opuszczają Waszej sieci podczas indeksowania.

Gdy dane są niejawne lub objęte RODO, wybieramy hosting lokalny. Przy treściach publicznych (np. katalog produktów bez danych osobowych) chmurowy endpoint jest akceptowalny, pod warunkiem maskowania PII przed wysłaniem.

Wektory przechowuje baza wektorowa. W naszym stacku to Qdrant uruchomiony na własnym serwerze (storage lokalny, bez połączeń wychodzących). Qdrant obsługuje:

• wyszukiwanie ANN (przybliżone najbliższe sąsiedztwo) z indeksem HNSW — milion wektorów w kilkanaście milisekund,
• payload filtering — wyszukaj semantycznie tylko w dokumentach kategorii „procedury HR" albo tylko produktów czynnych,
• named vectors — ten sam dokument ma embedding do wyszukiwania i osobny do reranking.

Alternatywy to pgvector (rozszerzenie Postgres — dobra opcja, gdy chcesz jednej bazy danych dla wszystkiego) i Weaviate (pełna platforma z własnym schema). Qdrant wybieramy przy projektach wymagających dużej przepustowości zapytań i izolacji danych na poziomie kolekcji.

Wyszukiwanie hybrydowe łączy wyniki pełnotekstowe (BM25) z semantycznymi i scala je przez reranking. To kluczowe przy:

• zapytaniach o kod lub numery — „ustawa 2025/0048" trafia precyzyjnie przez BM25, nie przez semantykę,
• zapytaniach o nazwy własne — modele embeddingów gorzej radzą sobie z unikalnymi nazwami produktów, SKU, nazwiskami,
• krótkich zapytaniach jednosłownych — zbyt mało kontekstu, by semantyka dała przewagę.

W praktyce silnik hybrydowy: wyszukuje równolegle BM25 i ANN, scala wyniki Reciprocal Rank Fusion (RRF), a potem reranker (cross-encoder) punktuje je ponownie z uwzględnieniem pełnego kontekstu zapytanie+fragment. Wynik: wyższa jakość przy zmiennych typach pytań, niż dałby jeden mechanizm.

Więcej o tym wzorcu w artykule RAG czy fine-tuning — hybryda jest jednym z powodów, dla których RAG tak dobrze skaluje się na zróżnicowanych bazach wiedzy.

RAG (retrieval-augmented generation) to architektura, w której model generatywny nie odpowiada „z głowy", lecz najpierw dostaje wyszukane fragmenty Waszej wiedzy, a potem konstruuje odpowiedź z cytowaniem źródeł. Embeddingi i baza wektorowa są dokładnie tym „wyszukiwaniem" w środku RAG.

Praktyczny pipeline:

1. Dokument jest dzielony na fragmenty (chunking — zwykle 256–512 tokenów z nakładką).
2. Każdy fragment jest osadzany (embedding) i zapisywany w Qdrant z metadanymi (kategoria, data, dział).
3. Zapytanie użytkownika jest osadzane i wyszukiwane w Qdrant.
4. Top-k fragmentów trafia jako kontekst do LLM przez router modeli.
5. Model odpowiada wyłącznie na podstawie tych fragmentów, podając cytaty.

Gdy wyszukiwanie nie znajdzie fragmentu o wystarczającej zgodności (próg podobieństwa), system mówi „nie wiem" i eskaluje do człowieka — zamiast zmyślać. To human-handoff, a nie wada architektury.

Cały pipeline opisujemy też w artykule od czego zacząć wdrożenie AI — wyszukiwanie semantyczne jest jednym z najszybciej zwracających się wdrożeń, bo działa na istniejącej wiedzy firmy.

Nie każda baza wiedzy potrzebuje embeddingów. Warto wdrożyć, gdy:

• Użytkownicy nie trafiają na właściwe dokumenty mimo że te istnieją — bo pytają inaczej niż dokumentacja jest napisana.
• Firma ma ponad kilkaset dokumentów i różne działy nazywają te same pojęcia różnie.
• Chcesz zbudować asystenta odpowiadającego na pytania na podstawie wewnętrznych danych (RAG).
• Dane dotyczą wielu języków lub klientów piszących nieformalnie (obsługa klienta, e-commerce).

Nie wdrażaj semantycznego jako pierwszego kroku, gdy baza wiedzy nie istnieje albo jest chaotyczna. Embeddingi odzwierciedlają jakość danych wejściowych. Porządkowanie wąskiego wycinka pod wybrany proces jest szybsze i daje lepsze wyniki niż osadzanie niespójnych plików.

Sprawdź gotowość organizacji w ocenie gotowości AI — jeden z wymiarów wprost dotyczy stanu bazy wiedzy.

Koszt zależy od wolumenu dokumentów, wyboru modelu i docelowej architektury. Orientacyjne parametry projektu pilotażowego:

• Indeksowanie do kilku tysięcy fragmentów na standardowym serwerze CPU trwa minuty.
• BGE-M3 lokalnie: zero kosztu licencyjnego, koszt sprzętu lub serwera VPS.
• Chmurowe embeddingi: kilka centów za milion tokenów (poniżej 1 USD za typową bazę wiedzy SME).
• Qdrant self-hosted: bezpłatny (open-source), koszt hostingu.

Zwrot jest najłatwiej policzalny w scenariuszu obsługi klienta: jeśli system semantyczny zamknie 30% pytań bez udziału człowieka, a agent kosztuje N zł/h, masz prosty kalkulator. Oblicz sam w kalkulatorze ROI.

Pełny projekt (indeksowanie + RAG + interfejs + guardrails) szacujemy po audycie danych. Pilot na jednym obszarze wiedzy zwykle zamyka się w zakresie tygodni. Skontaktuj się przez formularz kontaktowy, by omówić zakres.

Poniższy sandbox uruchamia ten sam mechanizm semantyczny co nasze wdrożenia — wklej fragment dokumentu i zadaj pytanie. Model odpowie wyłącznie na podstawie Twojego tekstu, nie z własnej pamięci. PII maskowane przed modelem, zero retencji.

Wyszukiwanie pełnotekstowe (np. Elasticsearch, PostgreSQL FTS) szuka dokumentów zawierających podane słowa lub ich odmiany. Wyszukiwanie semantyczne zamienia zapytanie na embedding i szuka dokumentów o zbliżonym znaczeniu, niezależnie od użytych słów. W praktyce: klient pytający o „reklamację" trafi na procedurę opisaną słowem „zgłoszenie", czego klasyczna wyszukiwarka nie połączy.

Tylko jeśli wybierzesz chmurowy model embeddingów. Przy lokalnym BGE-M3 (Ollama) treści nie opuszczają Waszej infrastruktury podczas indeksowania. Do modelu generatywnego trafia jedynie kontekst wyszukanych fragmentów, wcześniej przez nasz router maskowany ze zmiennych PII. Dane wrażliwe mogą pozostać wyłącznie lokalnie przez cały pipeline.

Wyszukiwanie semantyczne zaczyna dawać wyraźną przewagę nad pełnotekstowym już od kilkudziesięciu dokumentów, gdy pytania są różnorodne językowo. Poniżej kilkunastu dokumentów zwykły BM25 jest prostszy i wystarczy. Powyżej kilku tysięcy fragmentów warto zadbać o chunking i metadane — jakość dzielenia dokumentów wpływa na jakość odpowiedzi bardziej niż wybór modelu embeddingów.

Pilot na jednym obszarze wiedzy (np. FAQ obsługi klienta albo procedury HR) to zwykle kwestia tygodni, zależnie od stanu i objętości danych. Wydłuża czas niespójna baza wiedzy wymagająca porządkowania lub konieczność integracji z systemem zewnętrznym (CRM, ERP). Więcej o etapach wdrożenia w artykule od czego zacząć wdrożenie AI.

Samo wyszukiwanie semantyczne nie narusza RODO. Kluczowe pytania dotyczą tego, co indeksujecie i gdzie przechowujecie wektory. Jeśli dokumenty zawierają dane osobowe, obowiązuje RODO: podstawa prawna, minimalizacja danych, prawo do usunięcia. Przy lokalnym hostingu (Qdrant on-prem, BGE-M3 lokalnie) dane nie opuszczają Waszej infrastruktury. Szczegóły prawne opisuje artykuł AI Act i RODO 2026.