Przejdź do treści
Wiedza i research

Firmowa baza wiedzy z AI — od źródeł do oceny jakości

Jak przygotować firmową bazę wiedzy z AI: właściciele treści, źródła danych, architektura, uprawnienia, ocena odpowiedzi i utrzymanie aktualności dokumentów.

Firmowa baza wiedzy ma pomagać znaleźć właściwą informację i sprawdzić, czy nadal obowiązuje. AI może wspierać wyszukiwanie, przygotowanie odpowiedzi i porządkowanie treści. Nie zastępuje jednak właścicieli dokumentów ani decyzji o tym, które źródło jest wiarygodne.

Warto zacząć od zadania użytkownika: odnalezienia procedury, wyjaśnienia decyzji projektowej lub znalezienia osoby odpowiedzialnej za proces. Dopiero potem można ocenić, czy potrzebne są nowe funkcje wyszukiwania, RAG, graf wiedzy lub poprawa obecnej wiki.

Ustal odpowiedzialność za treści

Wybierz właściciela procesu zarządzania wiedzą i osoby zatwierdzające poszczególne obszary. Ustal, gdzie powstaje aktualna wersja dokumentu, kto może ją zmienić i jak użytkownik zgłasza błąd. Różne działy mogą używać różnych narzędzi, jeśli odpowiedzialność i przepływ informacji są jasne.

Nie każdy dokument traci aktualność po określonej liczbie miesięcy. Data ostatniej edycji jest sygnałem do przeglądu, a nie dowodem, że treść jest błędna. Zmiana produktu, przepisów lub procesu może wymagać szybszej reakcji niż cykliczne przypomnienie.

Krok 1: mapa źródeł i pytań użytkowników

Zbierz przykłady pytań, które dziś trudno rozwiązać, oraz miejsca zawierające odpowiedzi. Źródła mogą obejmować dokumenty, zatwierdzone strony wiki, repozytoria kodu, rekordy biznesowe i zapisane decyzje. Wiedzę niezapisaną trzeba najpierw pozyskać od osób, które ją posiadają.

Dla każdego źródła określ:

  • właściciela i przeznaczenie;
  • format, język, skalę i częstotliwość zmian;
  • jakość treści, duplikaty i sprzeczne wersje;
  • uprawnienia oraz możliwość ich odczytu i aktualizacji;
  • podstawy wykorzystania, retencję i ograniczenia dostawcy;
  • techniczny sposób pobierania danych i obsługi usunięć.

Prywatne wiadomości, poczta i rozmowy nie powinny trafiać do indeksu wyłącznie dlatego, że da się je wyeksportować. Trzeba ustalić uzasadniony cel, zakres, uprawnienia i właściwe obowiązki informacyjne. Użytkownik powinien mieć jasność, jakie źródła są przeszukiwane.

Krok 2: dobierz architekturę do pytań

Wiki może oferować wersjonowanie, linki, tagi, uprawnienia i rozbudowane wyszukiwanie. Warto sprawdzić te możliwości przed dodaniem kolejnej warstwy. Baza wiedzy nie musi mieć wszystkich funkcji AI ani interfejsu rozmowy.

PodejścieGdzie może pomócCo sprawdzić
Uporządkowana wiki i wyszukiwanie tekstoweDokumenty po nazwie, identyfikatorze, słowach i filtrachMetadane, aktualność, konfiguracja rankingu
Wyszukiwanie semantycznePytania i dokumenty używające różnych sformułowańTrafność, nazwy własne, liczby i terminologia
RAGPrzygotowanie odpowiedzi na podstawie odnalezionych materiałówPoprawność twierdzeń, cytowania i odmowa przy braku źródeł
Graf wiedzyJawne relacje między obiektami i zależnościModel pojęć, identyfikatory, pochodzenie i aktualizacja relacji
Połączenie metodZadania wymagające kilku sposobów dostępu do informacjiCzy korzyść uzasadnia złożoność i koszt utrzymania

RAG nie wymaga wyłącznie bazy wektorowej. Może korzystać także z wyszukiwania tekstowego, filtrów i innych źródeł. Graf wiedzy może uzupełnić kontekst relacjami, ale nie gwarantuje kompletności ani poprawności odpowiedzi.

Liczba dokumentów sama nie wyznacza architektury. Mały zbiór może zawierać trudne zależności, a duży dobrze uporządkowany katalog może być skutecznie przeszukiwany po polach. Porównaj rozwiązania na własnych zadaniach.

Krok 3: przygotuj dokumenty i indeks

Odczyt formatów wymaga sprawdzenia rzeczywistych plików. PDF może zawierać tekst, skan albo oba rodzaje treści. Tabele, przypisy, makra wiki i załączniki mogą utracić znaczenie po nieprawidłowym przekształceniu. OCR należy oceniać na reprezentatywnych dokumentach.

Zachowuj identyfikator, tytuł, wersję, źródło, datę obowiązywania i uprawnienia. Fragment wycięty z dokumentu powinien pozwalać wrócić do właściwego miejsca, w tym nagłówka lub tabeli. Duplikaty i archiwalne wersje wymagają zasad indeksowania, aby nie dominowały w wynikach.

Podział na fragmenty

Podział o stałym rozmiarze jest prostym punktem odniesienia. Podział według nagłówków może lepiej zachować strukturę, a oparty na podobieństwie fragmentów — granice tematów. Żadna z tych metod nie jest zawsze najlepsza.

Wielkość fragmentu i ewentualne nakładanie się treści wpływają na trafność, koszt oraz kompletność kontekstu. Testuj także tabele, listy warunków i odwołania do wyjątków. Rozdzielenie zasady od zastrzeżenia może prowadzić do błędnej odpowiedzi mimo poprawnego wyszukania.

Wybór modelu embeddingowego

Model zamienia tekst na reprezentację numeryczną używaną do porównywania podobieństwa. Wybór zależy od języka, terminologii, długości fragmentów, kosztu i możliwości uruchomienia. Dokumenty i zapytania muszą być przetwarzane w zgodnej przestrzeni, według wymagań wybranego modelu.

Nie zakładaj najlepszego modelu dla całego języka polskiego. Przygotuj pytania z odmianami słów, skrótami, nazwami własnymi i dokumentami w kilku językach. Sprawdź licencję, warunki usług i przepływ danych, jeśli używasz API. Embedding nie jest automatyczną anonimizacją dokumentu.

Krok 4: zaprojektuj sposób korzystania

Interfejs może oferować listę wyników, filtry, odpowiedź z odnośnikami lub widok relacji. Wybór powinien wynikać z testów z użytkownikami, nie z obowiązku udostępnienia każdego trybu.

Przy generowanej odpowiedzi użytkownik powinien móc otworzyć źródło i sprawdzić fragment potwierdzający twierdzenie. Sam link do dokumentu o podobnym temacie nie wystarcza. System powinien sygnalizować brak podstaw i sprzeczne materiały; skuteczność tego zachowania wymaga testów.

Ustal sposób zgłoszenia błędu i przekazania pytania właścicielowi treści. Nie przedstawiaj liczby podobieństwa wektorów ani deklaracji modelu jako wiarygodnego procentu pewności bez odpowiedniej oceny.

Uprawnienia muszą działać w całym przepływie

Kontrola obejmuje odczyt źródeł, indeks, fragmenty wyników, modele, historię rozmów, pamięć podręczną, logi i eksport. Ograniczone materiały nie powinny trafiać do modelu ani użytkownika bez właściwej autoryzacji. Zmiana dostępu lub usunięcie dokumentu wymaga propagacji do wszystkich używanych kopii i indeksów zgodnie z przyjętymi zasadami.

Przetestuj role z różnymi uprawnieniami, cofnięcie dostępu i próbę ujawnienia samego istnienia poufnego dokumentu. Oddziel instrukcje systemu od treści znalezionych materiałów: dokument może zawierać polecenie próbujące wpłynąć na zachowanie modelu. Sama instrukcja w poleceniu nie zastępuje ograniczeń dostępu i narzędzi.

Własny serwer, chmura prywatna i usługa zarządzana wymagają oceny całej architektury. Lokalny indeks może korzystać z zewnętrznego API do embeddingów lub generowania. RODO nie nakazuje wyłącznie hostingu w UE, a lokalizacja i umowa powierzenia nie potwierdzają same zgodności całego procesu.

Krok 5: oceń wyszukiwanie i odpowiedzi osobno

Przygotuj pytania z potwierdzonymi źródłami, pytania bez odpowiedzi, przypadki sprzeczne i testy uprawnień. Zestaw powinien odzwierciedlać realne zadania i pozostać dostępny do kolejnych porównań.

  • Trafność wyszukiwania: czy odpowiednie materiały pojawiają się w wynikach i na użytecznej pozycji?
  • Pokrycie informacji: czy odnaleziony materiał zawiera warunki potrzebne do odpowiedzi?
  • Poprawność odpowiedzi: czy treść odpowiada na pytanie i nie dopisuje niepotwierdzonych twierdzeń?
  • Zgodność cytowań: czy wskazane fragmenty rzeczywiście potwierdzają odpowiednie zdania?
  • Zachowanie przy braku danych: czy system potrafi wstrzymać odpowiedź lub poprosić o doprecyzowanie?
  • Wynik zadania użytkownika: ile trwa znalezienie i sprawdzenie informacji oraz ile spraw wymaga pomocy?

Model oceniający odpowiedzi może wspierać przegląd, ale również popełnia błędy. Porównuj jego oceny z ustalonymi kryteriami i przeglądem ludzi. Test A/B bywa przydatny, lecz wymaga porównywalnych zadań i grup; nie jest jedynym sposobem oceny.

Utrzymanie: treści, integracje i modele

Ustal właścicieli źródeł, częstotliwość przeglądów i zdarzenia uruchamiające aktualizację. System może wskazywać możliwe konflikty lub duplikaty do sprawdzenia, ale nie potwierdza sam, która wersja jest prawidłowa. Brak odczytów dokumentu nie dowodzi, że jest niepotrzebny.

Archiwizacja i usuwanie powinny wynikać z zasad retencji oraz potrzeb procesu. Zarchiwizowany dokument może być potrzebny do pytania historycznego, ale nie powinien zostać przedstawiony jako bieżąca instrukcja. Monitoruj opóźnienie synchronizacji, błędy pobierania i zmianę jakości po aktualizacji modelu lub konfiguracji.

Budżet obejmuje przygotowanie treści, integracje, indeksowanie, modele, interfejs, testy i utrzymanie. Potrzebne role oraz nakład pracy zależą od zakresu; nie ma jednej minimalnej liczby etatów dla każdej firmy. Cenę i harmonogram ustalamy indywidualnie, a zakres produkcyjny powinien wynikać z wyników pilotażu.

BeHive — silnik do pogłębionego researchu

BeHive to otwarty silnik badawczy QA10. Pomaga badać materiały źródłowe, oceniać twierdzenia i porządkować powiązania między informacjami. Pakiet Python jest dostępny w PyPI na licencji MIT i pozwala korzystać z własnego modelu językowego.

pip install behive

Instrukcje konfiguracji i aktualny zakres działania znajdziesz w dokumentacji BeHive. Firmowa baza wiedzy, integracje z systemami i kontrola uprawnień wymagają osobnego projektu i weryfikacji. Samo uruchomienie pakietu nie potwierdza bezpieczeństwa, zgodności prawnej ani jakości odpowiedzi na Twoich danych.

Najczęstsze pytania

Ile kosztuje firmowa baza wiedzy z AI?

Koszt zależy od jakości źródeł, funkcji, integracji, modeli, infrastruktury i utrzymania. Oferty warto porównywać dla tego samego zakresu i kryteriów odbioru. W QA10 cenę ustalamy indywidualnie.

Jak długo trwa przygotowanie rozwiązania produkcyjnego?

Harmonogram zależy od dostępu do źródeł, ich przygotowania, uprawnień, integracji i testów. Pilotaż pomaga ocenić te założenia, lecz sam nie dowodzi gotowości produkcyjnej. Termin wymaga indywidualnego uzgodnienia.

Czy trzeba zastąpić Confluence lub Notion?

Nie zawsze. Można wykorzystać obecne funkcje albo dodać warstwę wyszukiwania lub odpowiedzi. Możliwości odczytu, synchronizacji i kontroli dostępu trzeba sprawdzić dla konkretnego systemu i planu.

Czy RAG gwarantuje odpowiedzi zgodne z dokumentami?

Nie. Błąd może powstać przy pobieraniu materiałów, ich wyborze lub generowaniu. Potrzebne są testy źródeł, cytowań, poprawności odpowiedzi i zachowania przy braku wystarczających informacji.

Jak zadbać o bezpieczeństwo bazy wiedzy?

Prześledź dane od źródeł przez indeksy i modele po logi oraz odpowiedzi. Sprawdź uprawnienia, podstawy przetwarzania, retencję, usługi zewnętrzne i propagację zmian dostępu. Sama lokalna instalacja nie zapewnia bezpieczeństwa.

Kto powinien odpowiadać za utrzymanie?

Potrzebne są osoby odpowiedzialne za treści, proces, integracje, jakość odpowiedzi, bezpieczeństwo i infrastrukturę. Role można łączyć zależnie od zakresu, ale odpowiedzialność oraz czas na utrzymanie trzeba uzgodnić przed wdrożeniem.

Od pytania do zakresu projektu

Przygotuj przykładowe pytania, opis źródeł i wymagania dotyczące dostępu. To podstawa rozmowy o rozwiązaniu i kryteriach jego odbioru.

Q-Dev to software house QA10. Projektujemy oprogramowanie według uzgodnionego zakresu; cenę i harmonogram ustalamy dla konkretnego projektu. Prawa do kodu przechodzą na klienta po rozliczeniu całego projektu.

Wróć do bazy wiedzy

Od wiedzy do działania BeHive

Poznaj BeHive

Zobacz aktualny zakres produktu i jego dostępność.