Jak Legalka KB wykorzystuje AI: RAG, głos i zero halucynacji

Przeprowadzka do innego kraju to niemal zawsze stres, a Polska nie jest wyjątkiem. Karta pobytu, wiza, ZUS, konto bankowe, podatki, nostryfikacja dyplomu, łączenie rodzin — na każdym kroku pojawiają się dziesiątki pytań, a odpowiedzi są rozproszone po forach, czatach, nieaktualnych artykułach i okienkach urzędów, gdzie przy sąsiednim stanowisku nierzadko mówią co innego. Łatwo się zgubić, łatwo uwierzyć błędnej poradzie i stracić na tym tygodnie, pieniądze i nerwy. Właśnie z tego chaosu wyrósł nasz projekt.

Legalka KB to darmowy bot Telegram, który pomaga rozeznać się w relokacji do Polski. W przeciwieństwie do zwykłego chatbota — który na takie pytania odpowiada z pełną pewnością, zmyślając numery kont, terminy i adresy urzędów, które nie istnieją — Legalka KB odpowiada wyłącznie ze zweryfikowanej bazy wiedzy i uczciwie mówi «nie wiem», gdy w bazie nie ma odpowiedzi. W tym artykule przystępnie, ale szczegółowo pokażemy, jak system działa od środka: skąd biorą się dane, jak powstaje odpowiedź, co powstrzymuje bota przed zmyślaniem i jak utrzymujemy bazę w aktualności. Po drodze — wszystkie schematy z naszej wewnętrznej dokumentacji.

Główna zasada, na której opiera się wszystko inne, jest prosta: baza wiedzy to sam produkt. Bot nie jest «mądry sam z siebie» — jedynie starannie wydobywa i przekazuje to, co już leży w zweryfikowanej bazie. Nie ma w bazie — nie ma odpowiedzi. Z tej zasady wynika też cała architektura, do której teraz przejdziemy.

Jak zbudowany jest cały system

Zanim zanurzymy się w szczegóły, warto zobaczyć całą mapę. System składa się z czterech dużych części: bazy wiedzy, kolektora praktyki, asystenta z botem Telegram oraz panelu sterowania dla kuratora.

flowchart TB
  subgraph Sources["Źródła społeczności"]
    TG["Czaty i kanały<br/>na Telegramie"]
  end
  subgraph Pipeline["Kolektor praktyki (LangGraph)"]
    direction LR
    ING["odbiór"] --> THR["składanie rozmów"] --> EXT["ekstrakcja faktów (LLM)"]
    EXT --> PII["filtr danych osobowych"] --> CLS["klasyfikacja tematu"]
    CLS --> DED["deduplikacja"] --> STG["przygotowanie<br/>faktów"]
  end
  subgraph KB["Baza wiedzy (sam produkt)"]
    NORM["warstwa «norma»<br/>(prawo, ze źródłami)"]
    PRAC["warstwa «praktyka»<br/>(społeczność, z datami)"]
  end
  subgraph RAG["Asystent odpowiadający wyłącznie z bazy"]
    IDX["indeks"] --> RET["wyszukiwanie"] --> ANS["odpowiedź<br/>norma/praktyka + linki + abstencja"]
  end
  subgraph Revise["Agent poprawek (LangGraph)"]
    REV["wczytanie → plan → poprawka →<br/>walidacja → zapis"]
  end
  subgraph Dash["Panel sterowania (dla kuratora)"]
    COL["Panel zbierania"]
    REVIEW["Recenzja i zatwierdzanie"]
  end
  TG --> ING
  STG -. "ręczne przeniesienie" .-> PRAC
  Authoring["kurator + oficjalne źródła"] --> NORM
  NORM --> IDX
  PRAC --> IDX
  ANS --> Users["Użytkownicy RU/UA/BE/PL/EN<br/>(bot Telegram)"]
  Dash -->|dane| Pipeline
  Dash -->|dane| KB
  Dash -->|dane| RAG
  REVIEW --> REV
  REV --> KB

Po lewej — źródła: otwarte czaty i kanały diaspory na Telegramie. Z nich kolektor wydobywa «praktykę» — jak sprawy wyglądają naprawdę. Po prawej — sami użytkownicy, którzy zadają botowi pytania w pięciu językach. W centrum — baza wiedzy podzielona na dwie warstwy oraz asystent, który zamienia pytanie w odpowiedź. Wszystkim tym zarządza kurator przez osobny panel. Dalej omówimy każdy blok po kolei.

Technicznie projekt jest złożony jako jedna całość: każda duża część odpowiada za swój obszar pracy i może rozwijać się niezależnie od pozostałych.

flowchart LR
  ROOT["Projekt Legalka"]
  ROOT --> KB["Baza wiedzy —<br/>strony ze źródłami"]
  ROOT --> PIPE["Kolektor praktyki<br/>i agent poprawek"]
  ROOT --> RAGD["Asystent<br/>i bot Telegram"]
  ROOT --> DASH["Panel sterowania"]
  ROOT --> EVAL["Zestaw pytań<br/>regresyjnych"]
  ROOT --> INBOX["Skrzynka: pytania<br/>i szkice faktów"]
  ROOT --> DOCS["Dokumentacja"]
  ROOT --> CLAUDE["Narzędzia zespołu"]

Baza wiedzy: «norma» i «praktyka»

Sercem systemu jest sama baza wiedzy — zbiór ustrukturyzowanych stron. Wiedza w niej jest celowo podzielona na dwie warstwy, których nigdy się nie miesza.

Warstwa «norma» to, czego wymaga prawo. Każde twierdzenie ma odnośnik do źródła (w miarę możliwości do konkretnego artykułu), zostaje oznaczone jako zweryfikowane dopiero po recenzji prawnika i jest sprawdzane ponownie nie rzadziej niż co 60 dni.

Warstwa «praktyka» to, jak to działa w rzeczywistości: terminy, przyzwyczajenia inspektorów, niuanse konkretnych urzędów. To obserwacje wnioskodawców, zawsze z zastrzeżeniem «na podstawie relacji wnioskodawców» i zawsze z datą, po której fakt uznaje się za nieaktualny (nie później niż +90 dni).

Żadna strona nie trafia do użytkowników od razu. Wszystko powstaje jako szkic i musi przejść recenzję — to chroni przed tym, by surowe lub błędne dane poszły «na produkcję».

stateDiagram-v2
  state "szkic" as draft
  state "zweryfikowane — praktyka" as vp
  state "zweryfikowane — norma" as vn
  [*] --> draft: tworzy kurator
  draft --> draft: poprawki
  draft --> vp: recenzja kuratora
  draft --> vn: recenzja prawnika
  vp --> [*]
  vn --> [*]
  note right of draft
    Poprawki wprowadza AI albo kurator ręcznie.
    Bot pokazuje też szkice,
    ale uczciwie oznacza je
    jako jeszcze niezweryfikowane
  end note

Dopóki strona jest szkicem, bot może ją mimo to pokazywać, ale uczciwie oznacza taką odpowiedź jako niezweryfikowaną — żeby nie tracić świeżych danych, a zarazem nie podawać ich za ostatecznie sprawdzone.

Jak powstaje odpowiedź

To najważniejsza część — to, po co całość powstała. Gdy użytkownik pisze pytanie, odpowiedź przechodzi przez łańcuch: przeformułowanie → wyszukiwanie → ocena trafności → generowanie ze sprawdzeniem → zapis do informacji zwrotnej. Na każdym kroku system ma możliwość uczciwie się zatrzymać i powiedzieć «nie wiem».

flowchart TB
  Q["Pytanie użytkownika<br/>(tekst lub głos)"] --> CQ["Przeformułowanie:<br/>pytanie odsyłające → samodzielne zapytanie"]
  CQ --> R["Wyszukiwanie: najbliższe znaczeniowo<br/>sekcje bazy + priorytet województwa"]
  R --> G{"Ocena trafności"}
  G -->|"dopasowanie zbyt niskie<br/>lub brak wyników"| AB["Abstencja:<br/>«nie wiem»"]
  G -->|"dopasowanie pewnie wysokie"| A
  G -->|"w innym razie"| V{"Sprawdzenie przez model<br/>wg pierwotnego pytania"}
  V -->|nietrafne| AB
  V -->|trafne| A["Odpowiedź<br/>etykiety norma/praktyka + linki"]
  A --> DIS["+ zastrzeżenie"]
  AB --> DIS
  DIS --> REC["Zapis odpowiedzi<br/>(bez danych osobowych)"]
  REC --> FB["👍/👎 powiązane<br/>z tą odpowiedzią"]

Omówmy to krok po kroku.

Przeformułowanie. Rozmowa rzadko składa się z pełnych pytań. «A jakie dokumenty?», «do tego», «a tam?» — takie wypowiedzi są bezużyteczne dla wyszukiwania w oderwaniu od kontekstu. Dlatego krótkie i odsyłające pytania kompaktowy model gpt-4o-mini przeformułowuje w samodzielne zapytanie, uwzględniając historię rozmowy i wybrane województwo: «a jakie dokumenty?» po pytaniu o pobyt na podstawie działalności zmienia się w «dokumenty do zezwolenie na pobyt czasowy i pracę, mazowieckie». Dzięki temu wyszukiwanie nie gubi wątku.

Wyszukiwanie. Każda sekcja każdej strony bazy jest z wyprzedzeniem zamieniana w wektor przez model text-embedding-3-small i przechowywana w indeksie wyszukiwania. Pytanie również zamieniane jest w wektor, a system znajduje najbliższe znaczeniowo sekcje według podobieństwa kosinusowego. Jeśli użytkownik wybrał województwo, jego strony mają priorytet nad ogólnymi — aby konkrety, takie jak numer konta czy adres urzędu, wygrywały ze stronami ogólnymi.

Ocena trafności. Zanim cokolwiek zostanie wygenerowane, system patrzy wyłącznie na oceny wyszukiwania (to osobny, ściśle przetestowany krok). Jeśli najlepszy wynik jest poniżej ustalonego progu albo nie ma trafień — bot od razu się wstrzymuje. Jeśli dopasowanie jest oczywiście dobre, a pytanie nie było przeformułowane — odpowiada od razu, bez dodatkowego sprawdzenia przez model. W przypadkach pośrednich uruchamia się dodatkowe sprawdzenie.

Sprawdzenie przez model. Porównuje ono PIERWOTNE pytanie użytkownika (a nie przeformułowane zapytanie) ze znalezionymi fragmentami — ponieważ przeformułowanie czasem «zjeżdża» na poprzedni temat i wysoko ocenia niewłaściwą stronę. Jeśli sprawdzenia nie da się jednoznacznie zinterpretować, system skłania się ku odpowiedzi. Bot wstrzymuje się tylko wtedy, gdy kontekst zostanie uznany za nietrafny.

Generowanie. Odpowiedź układa ten sam model gpt-4o-mini — ale wyłącznie ze znalezionych sekcji, bez wiedzy «z głowy». Każdy fakt oznaczany jest jako «norma» (to, czego wymaga prawo) lub «praktyka» (obserwacja wnioskodawców, zawsze z datą). Jeśli w kontekście są konkretne dane — numer konta, kwota, adres — bot podaje je wprost, zamiast odsyłać «dopytaj w urzędzie», i dołącza oficjalne linki do samodzielnej weryfikacji. Odpowiada w języku pytania, tłumacząc fakty z rosyjskojęzycznej bazy. Na końcu — zastrzeżenie.

Zapis i informacja zwrotna. Każda udzielona odpowiedź jest zapisywana (z obowiązkowym usunięciem danych osobowych), aby późniejsze 👍 lub 👎 przypięło się dokładnie do tego, co legło u jej podstaw, i przetrwało restart bota. Głos 👎 jest automatycznie rozkładany na typ — złe wyszukiwanie, złe generowanie albo luka w bazie — i trafia na panel jako sygnał, co naprawić w pierwszej kolejności.

Co bot potrafi dla użytkownika

Odpowiedź wyłącznie z bazy to rdzeń, ale wokół niego zbudowaliśmy cały zestaw udogodnień, aby korzystanie z bota było wygodne.

flowchart TB
  subgraph In["Wejście użytkownika"]
    T["pytanie tekstowe"]
    Vc["wiadomość głosowa"]
    Cmd["komendy"]
  end
  subgraph Core["Odpowiedź wyłącznie z bazy"]
    ANSW["odpowiedź + etykiety norma/praktyka<br/>+ linki + zastrzeżenie"]
  end
  Vc -->|rozpoznawanie mowy| T
  T --> ANSW
  ANSW --> Buttons["przyciski pod odpowiedzią"]
  Buttons --> B1["👍 / 👎 opinia"]
  Buttons --> B2["🔊 odczytaj na głos"]
  Buttons --> B3["✍️ zaproponuj poprawkę"]
  Buttons --> B4["📍 pokaż na mapie<br/>(jeśli polski adres)"]
  Buttons --> B5["🔔 lista oczekujących dla regionu"]
  Buttons --> B6["📋 utwórz listę kontrolną"]
  Cmd --> C1["/topics — przegląd bazy"]
  Cmd --> C2["/checklist — osobiste listy"]
  Cmd --> C3["/region — województwo"]
  Cmd --> C4["/lang — język interfejsu i odpowiedzi"]
  Cmd --> C5["/new, /chats, /reset —<br/>pamięć wielu czatów"]

Głos w obie strony. Pytania nie trzeba pisać — można je podyktować: wiadomość głosową rozpoznaje model whisper-1 z podpowiedzią językową, bot echem pokazuje rozpoznany tekst i traktuje go jak zwykłe pytanie. Działa też kierunek odwrotny: pod każdą odpowiedzią jest przycisk «Przeczytaj na głos» — tekst zostaje oczyszczony z niepotrzebnych elementów i odczytany przez model tts-1.

Przyciski pod odpowiedzią. 👍/👎 — informacja zwrotna; 🔊 — odczytaj; ✍️ — zaproponuj poprawkę (trafia do kolejki propozycji); 📍 — pokaż na mapie, jeśli w odpowiedzi jest polski adres; 🔔 — zapisz się na listę oczekujących, jeśli dla Twojego województwa nie ma jeszcze lokalnej praktyki; 📋 — utwórz listę kontrolną, jeśli odpowiedź wymienia punkty.

Komendy. /topics — przegląd działów bazy z przykładowymi pytaniami; /checklist i /checklists — osobiste, edytowalne listy (np. «Ja» i «Żona»); /region — wybór województwa; /lang — język interfejsu i odpowiedzi; /new, /chats, /reset i inne — pamięć wielu równoległych czatów.

Osobno o językach: interfejs i odpowiedzi są dostępne w pięciu — rosyjskim, ukraińskim, białoruskim, polskim i angielskim. Wybór języka jest «trwały»: raz ustawiony, nie zostanie zmieniony przez przypadkową wiadomość w innym języku. Sama baza pozostaje rosyjskojęzyczna, a model tłumaczy każdą odpowiedź na wybrany język już na etapie odpowiedzi.

Osobiste listy kontrolne to raczej notatnik niż część bazy: edycja listy nigdy nie dotyka samej bazy wiedzy ani wyszukiwania. Usunięcie pozycji, która pochodzi z odpowiedzi bota, usuwa ją tylko z Twojej listy.

Skąd bierze się praktyka

Warstwę normatywną pisze kurator na podstawie oficjalnych źródeł. Natomiast warstwa praktyczna wypełniana jest półautomatycznie — osobnym kolektorem opartym na LangGraph, który zamienia czaty diaspory w zanonimizowane, zdeduplikowane fakty.

flowchart LR
  A["Odbiór wiadomości"] --> B["Składanie rozmów"]
  B --> C["Ekstrakcja faktów (LLM)"]
  C --> D{"Filtr danych osobowych"}
  D -->|czysto| E["Klasyfikacja tematu"]
  D -->|są dane osobowe| X["Odrzuć"]
  E --> F["Deduplikacja"]
  F --> G["Przygotowanie faktów<br/>do recenzji"]

Liczby na dziś: przez kolektor przeszło około 2,4 mln wiadomości, z czego 28 091 uznano za istotne, a z nich wyodrębniono 17 284 fakty praktyczne. Ekstrakcją zajmuje się model gpt-4o-mini — wyłącznie zanonimizowane fakty, bez imion, nicków i cytatów.

Kluczowy moment — filtr danych osobowych działa według zasady «najpierw bezpieczeństwo»: najpierw automatyczne wyszukiwanie kontaktów, numerów dokumentów i długich cytatów, a w razie potrzeby dodatkowe sprawdzenie przez model; każdy «brudny» fakt jest odrzucany bez zapisu. Przeniesienie faktu do bazy to zawsze ręczny krok kuratora, nigdy automat.

Kolejny szczegół, o który trzeba było powalczyć, to klasyfikator tematów. Wcześniej wysyłał cały zestaw faktów w jednym zapytaniu do modelu, ten trafiał na limit czasu i po cichu przechodził na grubą heurystykę słów kluczowych, wrzucając przydatne fakty do «śmietnikowej» kategorii zbiorczej. Podzieliliśmy pracę na małe porcje — i udział «śmieci» spadł z 51% do 23%, a przydatnych, lecz źle poukładanych faktów zostało około 3%.

Ładowanie historyczne jest tak zbudowane, by można je było przerwać i wznowić: każdy kanał ma punkt kontrolny, a ponowne uruchomienie nie zaczyna od zera, lecz kontynuuje od miejsca zatrzymania.

Jak utrzymujemy bazę w aktualności

Zebranie faktów to połowa sukcesu. Dalej trzeba je sprawdzić, zredagować i zatwierdzić. Do tego kurator ma lokalny panel sterowania — działa on wyłącznie na jego komputerze i nie jest nigdzie wystawiony na zewnątrz.

flowchart LR
  subgraph UI["Panel sterowania (3 zakładki)"]
    COL["Zakładka «Zbieranie»"]
    REV["Zakładka «Recenzja»"]
    SIG["Zakładka «Sugestie»"]
  end
  subgraph API["Co robi panel"]
    S1["Status zbierania i fakty"]
    S2["Zarządzanie kanałami i uruchomieniem"]
    S3["Lista i treść stron"]
    S4["Zapytaj bota"]
    S5["Zatwierdź / zwróć stronę"]
    S6["Dialog-poprawka z AI (+ cofnij)"]
    S7["Sygnały: sugestie,<br/>opinie, oczekiwanie regionów"]
  end
  COL --> S1 & S2
  REV --> S3 & S4 & S5 & S6
  SIG --> S7
  S4 -->|uruchom wyszukiwanie| RAGcli["Bot"]
  S6 -->|uruchom poprawkę| REVcli["Agent poprawek"]
  S5 -->|zapisz zatwierdzenie| KBfiles["Pliki bazy"]
  S6 -->|pokaż zmiany| KBfiles
  S7 -->|"tylko odczyt, bez danych osobowych"| Signals["Przychodzące sygnały"]

Panel ma trzy zakładki: «Zbieranie» — kontrola zbierania faktów, «Recenzja» — przeglądanie, edycja i zatwierdzanie stron, oraz «Sugestie» — sygnały od użytkowników tylko do odczytu (propozycje poprawek, zestawienie 👍/👎, lista oczekujących dla regionów).

Zakładka «Zbieranie» pokazuje status ładowania historycznego i stan każdego kanału Telegram prostymi oznaczeniami — co jest już gotowe, co trwa, co zostało przerwane i wznowi się przy następnym uruchomieniu.

flowchart LR
  ST["Status ładowania<br/>stan · data · bieżący kanał ·<br/>pauza Telegram · postęp · log"]
  CH["Kanały<br/>✓ gotowy / ⏳ trwa / ◑ częściowo /<br/>○ oczekuje / — n/d"]
  CTL["Sterowanie<br/>data · ▶ start · ■ stop"]
  FACT["Magazyny i fakty<br/>miesiąc · temat ·<br/>ile wiadomości potwierdza fakt"]

Zakładka «Recenzja» to stanowisko recenzenta: lista stron z filtrami, szczegółowy podgląd ze źródłami i pytaniami kontrolnymi oraz akcje zatwierdzania.

flowchart LR
  L["Lista stron<br/>filtry: status / warstwa / temat + szukaj<br/>liczniki: szkice / zweryfikowane"]
  D["Szczegóły strony<br/>tekst · źródła · pytania kontrolne"]
  A["Akcje<br/>rola: kurator / prawnik<br/>Zapytaj bota · ✓ Zatwierdź ·<br/>↩ Zwróć · Popraw z AI"]
  L --> D --> A

Sam proces zatwierdzania wygląda tak: recenzent otwiera stronę, w razie chęci przepuszcza jej pytania kontrolne przez działającego bota, może poprawić tekst z pomocą AI, a następnie — w roli kuratora lub prawnika — zatwierdza. Zatwierdzenie oznacza stronę jako zweryfikowaną, zapisuje, kto ją sprawdził, oraz dodaje wpis do historii zmian.

sequenceDiagram
  actor Reviewer as Recenzent
  participant UI as Panel recenzji
  participant API as Serwer
  participant RAGcli as Bot
  participant Agent as Agent poprawek
  participant FS as Pliki bazy (git)
  Reviewer->>UI: wybierz stronę
  UI->>API: poproś o stronę
  API-->>UI: tekst + źródła + pytania
  opt Zobacz odpowiedź bota
    UI->>API: zapytaj bota
    API->>RAGcli: uruchom wyszukiwanie
    RAGcli-->>UI: odpowiedź + linki
  end
  opt Poprawka AI
    Reviewer->>UI: komentarz + «Popraw z AI»
    UI->>API: uruchom poprawkę
    API->>Agent: przekaż zadanie
    Agent->>FS: zapisz przepisany tekst
    API-->>UI: pokaż zmiany
    alt zaakceptuj
      Reviewer->>UI: «Akceptuj»
    else wycofaj
      UI->>API: wycofaj
      API->>FS: przywróć poprzednią wersję
    end
  end
  Reviewer->>UI: rola (kurator/prawnik) + «Zatwierdź»
  UI->>API: zapisz zatwierdzenie
  API->>FS: oznaczenie «zweryfikowane» + wpis w historii

Najciekawsze jest tu poprawianie przez dialog z AI. Zamiast ręcznie edytować tekst, kurator po prostu pisze agentowi, czego potrzebuje. Agent sam rozpoznaje, czy to pytanie, czy polecenie poprawki.

flowchart LR
  S((wiadomość kuratora)) --> L["Wczytanie strony"]
  L --> C{"Co to jest:<br/>pytanie czy poprawka?"}
  C -->|pytanie| AN["Odpowiedź ze strony<br/>(bez zmiany pliku)"]
  C -->|poprawka| P["Minimalny plan<br/>zmian"]
  P --> RV["Przepisz tylko<br/>tekst strony"]
  RV --> V{"Kontrola: sekcje całe?<br/>tekst nieucięty?"}
  V -->|"wymaga poprawy<br/>(do 2 prób)"| RV
  V -->|ok| W["Zapis<br/>+ wpis w historii"]
  AN --> E((koniec))
  W --> E

Agent dotyka wyłącznie tekstu strony — pola służbowe, źródła i status szkicu pozostają nietknięte. Wymyślanie faktów jest mu zabronione: jeśli nie ma źródła, zostawia adnotację, że jest ono potrzebne, zamiast coś zmyślać. Po edycji następuje kontrola: czy nie zniknęły sekcje, czy tekst nie został ucięty; jeśli utracono zbyt wiele — do dwóch prób, a potem wycofanie bez zapisu.

Z punktu widzenia kuratora wygląda to jak zwykły czat z pamięcią — można dopowiadać «nie, krócej», «wspomnij też o tym», a każdą poprawkę cofnąć jednym przyciskiem.

sequenceDiagram
  actor You as Ty
  participant Chat as Dialog z AI
  participant Agent as Agent
  participant FS as Pliki bazy (git)
  You->>Chat: «co tu jest napisane o X?»
  Chat->>Agent: to jest pytanie
  Agent-->>Chat: odpowiedź (plik bez zmian)
  You->>Chat: «dodaj punkt o Y»
  Chat->>Agent: to jest poprawka
  Agent->>FS: przepisz tekst (pola służbowe nietknięte)
  Agent-->>Chat: podsumowanie + zmiany, strona się odświeża
  opt cofnięcie
    You->>Chat: «Cofnij» poprawkę
    Chat->>FS: przywróć wersję sprzed poprawki
  end

Jak mierzymy jakość

Jakość odpowiedzi jest u nas mierzona, a nie zakładana. Istnieje zestaw 109 «złotych» pytań, a każda nowa strona dodaje co najmniej jedno. Osobny model-sędzia przepuszcza ten zestaw i sprawdza dwie rzeczy: czy odpowiedź oddała istotę oczekiwanych faktów (znaczeniowo, nie dosłownie) i czy nie twierdzi jako fakt czegoś zakazanego. Sprawdzenie jest celowo zaostrzone, aby «zakazane» uruchamiało się tylko przy wyraźnym twierdzeniu, a nie przy samym wspomnieniu tematu.

Bieżące metryki: cytowalność około 99%, pokrycie faktów około 97%, wstrzymanie się przy pytaniach spoza bazy — 100%.

Własny serwer, własne modele

Nic z tego nie jest przywiązane do jednego dostawcy. Wszystkie modele — rozpoznawanie znaczenia, generowanie, rozpoznawanie i synteza mowy — można podmienić na lokalne (na przykład Ollama lub LM Studio) jednym ustawieniem, a sam kod pozostaje ten sam. W przypadku wrażliwych danych relokacyjnych oznacza to, że cały stos można uruchomić na własnym serwerze i nie wysyłać pytań użytkowników na zewnątrz.

Cały cykl w skrócie

Jeśli złożyć wszystko razem, życie jednego faktu wygląda tak: jest zbierany z czatów, kurator przenosi praktykę lub pisze normę (szkic), recenzent sprawdza i zatwierdza, zmiany zostają zapisane, a następnie wyszukiwanie jest przebudowywane i przed wydaniem uruchamiane są pytania kontrolne.

flowchart LR
  C["Zbieranie faktów<br/>(z czatów)"] --> P["Przenieś praktykę /<br/>napisz normę (szkic)"]
  P --> R["Recenzja<br/>czytaj · zapytaj bota · popraw z AI"]
  R -->|zatwierdź| V["Zweryfikowane"]
  R -->|zwróć| P
  V --> COMMIT["Zapisz zmiany"]
  COMMIT --> REINDEX["Ponowne indeksowanie<br/>i uruchomienie testów"]

Podsumowanie

Legalka KB pokazuje, że «inteligentny asystent» i «uczciwy asystent» to nie to samo. Sekret tkwi nie w rozmiarze modelu, lecz w dyscyplinie wokół niego: ścisłe powiązanie ze zweryfikowaną bazą, uczciwe «nie wiem» zamiast zgadywania, obowiązkowe źródła i daty, anonimizacja na wejściu i mierzalna jakość na wyjściu. To właśnie odróżnia przydatnego pomocnika w relokacji od elokwentnego generatora zmyśleń.

Samego bota można wypróbować od razu na Telegramie, za darmo — @legalka_pl_bot. A jeśli potrzebujesz podobnego asystenta, który odpowiada wyłącznie z Twoich danych i nie zmyśla — napisz do nas: development@mi-code.pl.

Który model za co odpowiada

Na koniec — zestawienie: który model realizuje które zadanie.