Kiedy mówię komuś, że „model językowy to w gruncie rzeczy tablica liczb”, zwykle patrzy na mnie tak, jakbym właśnie zepsuł mu magię. I dobrze, bo o to mi chodzi.
Jeśli masz w kancelarii wdrażać narzędzie oparte na AI, do przeglądania akt czy researchu orzecznictwa, to zanim ocenisz, czy odpowiedzi są sensowne, warto wiedzieć, co dzieje się pod maską. Bo część problemów, które zobaczysz w praktyce (model „głupieje” przy dłuższym dokumencie, zmyśla sygnatury, jeden program lata, a drugi się dłuży), nie bierze się z tego, że AI jest „słaba”. Bierze się z fizyki i architektury, które da się prosto wytłumaczyć.
Nie będę Cię uczył budować modeli. Chcę Ci dać tyle, żebyś rozumiał, dlaczego dostawca narzędzia mówi Ci akurat to, co mówi, i żebyś umiał zadać mu niewygodne pytanie.
CPU i GPU, dwa różne sposoby liczenia
W komputerze siedzą dwa rodzaje „mózgu”. Procesor główny, CPU, to kilka bardzo sprytnych rdzeni, świetnych w logice typu „jeśli A, to zrób B, inaczej C”. Dokładnie to robi wyszukiwanie po sygnaturze w bazie orzeczeń albo zapytanie SQL: zawsze ten sam wynik dla tego samego pytania.
Karta graficzna, GPU, działa inaczej. Ma tysiące prostych rdzeni, z których żaden pojedynczo nie zrobi nic mądrego, ale razem wykonują tę samą operację na ogromnej ilości danych naraz. GPU powstało do gier, do liczenia milionów pikseli jednocześnie, i przypadkiem okazało się, że dokładnie tę samą operację, mnożenie macierzy, wykonuje się w sieciach neuronowych. Dlatego modele AI liczy się na kartach graficznych.
Stąd prosty podział, który warto zapamiętać: klasyczne wyszukiwanie w bazie prawniczej to robota CPU, zawsze deterministyczna. Model, który „rozumie” pytanie i podsuwa podobne stany faktyczne, to robota GPU, więc tu wyniki mogą się nieznacznie różnić za każdym razem.
RAM kontra VRAM, czyli dlaczego model musi się zmieścić w całości
Pamięć w komputerze to nie jeden zbiornik. RAM siedzi obok CPU: jest duża, względnie tania, ale wolna. VRAM siedzi na samej karcie graficznej: mała, droga, za to bardzo szybka. Żeby model liczył z pełną prędkością karty, musi zmieścić się w całości w VRAM.
I tu haczyk, który ludzie często ignorują. To nie jest miękka granica, tylko klif. Model, który mieści się na karcie, działa płynnie. Ten sam model powiększony o kilka procent za dużo potrafi zwolnić kilkanaście razy, bo brakujące kawałki muszą jeździć tam i z powrotem wąskim łączem między RAM-em a kartą. Przy każdym pojedynczym słowie odpowiedzi.
Zamawiałeś kiedyś meble do kuchni?
Wyobraź sobie, że topowy meblarz montuje Twoją kuchnię. Skręca i wiesza szafki szybko i precyzyjnie, ale po każdą część musi jechać na drugi koniec miasta. Dokładnie tak zachowuje się model, który nie mieści się w pamięci karty: formalnie „działa”, w praktyce jest nieużywalny przy dłuższym dokumencie. Dlatego czasami warto wybrać młodszego stolarza, który zabierze ze sobą wszystkie części. Zrobi to mniej dokładnie, za to znacznie szybciej.
Z czego zrobiony jest model: parametry i kwantyzacja
Rozmiar modelu, ten dopisek w rodzaju „11B” czy „120B”, to liczba parametrów, miliardów pojedynczych liczb, które model wykształcił podczas treningu. Cała „wiedza” modelu siedzi wyłącznie w wartościach tych liczb. Nie ma tam żadnej osobnej bazy faktów ani słownika, do którego model zagląda. Model nie uczy się też podczas rozmowy z Tobą, bo po treningu jest zamkniętym tworem. Wszystko, co „wie” o Twojej sprawie, pochodzi z tego, co podałeś mu w bieżącym zapytaniu, i znika, gdy je zamkniesz.
I tu ostrzeżenie, bo z tego zdania łatwo wyciągnąć błędny wniosek. To, że model niczego nie zapamiętuje, nie znaczy, że Twoje akta nigdzie nie zostają. Sam model faktycznie ich nie wchłonie, ale zanim do niego dotrą, przechodzą przez infrastrukturę dostawcy, gdzie mogą trafić do logów, kopii zapasowych albo zbioru danych na kolejną wersję modelu. To dwie różne sprawy: architektura modelu i polityka firmy, która go serwuje. O pierwszej decyduje matematyka, o drugiej regulamin i umowa powierzenia. Jako prawnik masz obowiązek sprawdzić tę drugą, bo pierwsza nie da Ci tu żadnej ochrony.
Każdą taką liczbę trzeba gdzieś zapisać, a sposób zapisu decyduje, ile miejsca zajmie. Kwantyzacja (oznaczenia Q8, Q4, które widzisz w popularnych narzędziach) to zapisanie tych samych wag z mniejszą precyzją. Model nie traci wiedzy, tylko odtwarza ją z lekką nieostrością, podobnie jak zdjęcie skompresowane do JPEG-a. Przy rzeczach dobrze wydeptanych, jak treść często cytowanego przepisu, prawie nie szkodzi. Przy danych rzadkich i precyzyjnych, jak dokładna sygnatura niszowego wyroku, ta nieostrość zaczyna być widoczna.
Modele gęste a MoE, czyli dlaczego 120 miliardów nie zawsze znaczy 120 miliardów
Tu robi się ciekawie, bo pojawia się kolejna decyzja architektoniczna, o której twórcy narzędzi rzadko mówią wprost.
W modelu gęstym każdy parametr bierze udział w liczeniu każdego słowa. Cały model trzeba przeczytać z pamięci przy każdym tokenie, bez wyjątku.
Model typu MoE (Mixture of Experts) składa się z wielu mniejszych podsieci, „ekspertów”, z których przy każdym słowie aktywuje się tylko część. Dobry przykład to gpt-oss-120b: ma w sumie około 117 miliardów parametrów, ale do policzenia jednego tokena używa realnie około 5,1 miliarda, bo router wybiera 4 z 128 dostępnych ekspertów. Brzmi jak oszustwo w nazwie, ale to celowy kompromis. W pamięci trzymasz ogromną, pojemną wiedzę, a płacisz w czasie liczenia tylko za jej aktywny ułamek.
Haczyk jest ten sam co wcześniej: VRAM nie obchodzi, ile parametrów jest „aktywnych”. Cały model, wszyscy eksperci, muszą zmieścić się w pamięci karty naraz. MoE bywa szybszy, ale wcale nie tańszy pamięciowo.
Za to samo wdrożenie takiego modelu wychodzi zwykle taniej niż wdrożenie porównywalnie zdolnego modelu gęstego. Skoro do policzenia jednego słowa angażujesz ułamek parametrów, to i mocy obliczeniowej potrzebujesz mniej, a to ona, obok VRAM-u, kosztuje w chmurze najwięcej. Dostawca płaci za realnie zużyte obliczenia, nie za cały rozmiar modelu, więc na tym samym sprzęcie obsłuży więcej zapytań naraz. Dlatego duży model MoE bywa w praktyce tańszy i szybszy w serwowaniu niż dużo mniejszy, ale w pełni gęsty model o podobnych możliwościach.
Nie piszę o tym przypadkiem, bo to właśnie gpt-oss-120b pracuje w chmurowej części beDocs. Wybrałem go świadomie z dwóch powodów. Pierwszy to koszt: architektura MoE pozwala mi przewidzieć i utrzymać w ryzach opłaty za API, dzięki czemu mogę sprzedawać program na licencji jednorazowej z rocznym limitem tokenów, zamiast comiesięcznego abonamentu. Drugi jest ważniejszy: gpt-oss ma otwarte wagi. To znaczy, że ten sam model, którego używasz przez naszą chmurę, można postawić na serwerze w kancelarii przy wdrożeniu on-premise. Nie zmienia się model, nie trzeba przepisywać promptów ani presetów, zmienia się tylko miejsce, w którym stoi karta graficzna. Przy modelach zamkniętych taka przeprowadzka nie jest możliwa.
Model to rachunek prawdopodobieństwa, nie wyszukiwarka
Tu dochodzimy do rzeczy, którą najłatwiej pomylić. Model nie „wie”, co odpowiedzieć, w sensie sprawdzenia faktu w bazie. Dla każdego kolejnego słowa liczy rozkład prawdopodobieństwa po całym słowniku, sprawdza, jak dobrze tysiące możliwych kontynuacji pasuje do dotychczasowego kontekstu, i wybiera jedną z najbardziej prawdopodobnych. Cały tekst na ekranie to seria takich losowań, jedno po drugim.
Dlatego ten sam model zapytany dwa razy o to samo może odpowiedzieć nieco inaczej. I dlatego brzmi tak samo pewnie, gdy ma rację, jak wtedy, gdy się myli. Płynność językowa i prawdziwość faktu to dla niego dwie różne sprawy, a model optymalizuje wprost tylko tę pierwszą.
Halucynacje: dlaczego model zmyśla z tą samą pewnością siebie
Halucynacja to nie usterka, którą ktoś kiedyś załata. To naturalna konsekwencja tego, jak model działa. Skoro każde słowo to wybór najbardziej prawdopodobnej kontynuacji, a nie odpytanie bazy faktów, to gdy model trafia na pytanie o coś, czego dobrze się nie nauczył (rzadki wyrok, niszowy przepis, nowelizację sprzed miesiąca), i tak wygeneruje odpowiedź. Bo generowanie kontynuacji to jedyne, co potrafi robić. Lukę w wiedzy wypełnia najbardziej prawdopodobnie brzmiącym tekstem, na przykład sygnaturą, która wygląda idealnie, tylko nie istnieje.
To dokładnie powód, dla którego zmyślony wyrok brzmi tak samo pewnie jak prawdziwy. Model nie ma wbudowanego czujnika „nie jestem pewien”, chyba że ktoś świadomie go tego nauczył albo dobudował to z zewnątrz. Im rzadszy fakt i im mocniej skwantowany model, tym większe ryzyko, że dostaniesz ładnie brzmiącą fikcję.
Halucynacji nie da się wyeliminować, ale da się je mocno ograniczyć. Klucz leży w tym, co model dostaje na wejściu. Jeśli podasz mu precyzyjny prompt i dobrej jakości kontekst, konkretny przepis, fragment akt, treść orzeczenia, model przestaje zgadywać, bo ma na czym się oprzeć. Zamiast wypełniać lukę własnym przypuszczeniem, po prostu czyta to, co dostał. Ryzyko nie znika, ale spada drastycznie. Dobry wsad obudowany bezpiecznikami to najprostszy sposób, żeby model przestał zmyślać.
RAG: jak trzymać model przy faktach
Pytanie brzmi: jak w praktyce dostarczyć modelowi ten dobry kontekst?
Można to zrobić samemu, wklejając do zapytania konkretny artykuł, fragment akt, treść wyroku istotnego dla sprawy. Ty decydujesz, co dokładnie model widzi.
Można też zautomatyzować ten proces i tu wchodzi RAG (Retrieval-Augmented Generation). Działa w trzech krokach. Twoje pytanie trafia najpierw do wyszukiwarki, która przeszukuje bazę (akta, orzecznictwo, przepisy) i sama wyciąga kilka najbardziej trafnych fragmentów, często na podstawie podobieństwa znaczeniowego, nie samych słów kluczowych. Te fragmenty lądują razem z Twoim pytaniem w jednym zapytaniu do modelu. A model już nie zgaduje z pamięci, tylko streszcza, porównuje albo cytuje to, co dostał podane wprost. W tym akurat jest naprawdę dobry.
Wygoda automatycznego RAG-u ma jednak swoją cenę i to jest sedno całego tekstu: nie wiesz dokładnie, które fragmenty wyszukiwarka wybrała i co realnie zobaczył model. Spójrz, jak wygląda typowy przebieg w narzędziu z wielką bazą przepisów:
- wysyłasz pytanie,
- pytanie trafia do RAG (zwykle w chmurze dostawcy), gdzie, całkowicie poza Twoją kontrolą, model dostaje „jakieś” fragmenty aktów prawnych, raz lepsze, raz gorsze,
- pytanie razem z tymi fragmentami leci do API modelu,
- wraca do Ciebie gotowa odpowiedź.
Krok drugi jest tu kluczowy i jednocześnie niewidoczny. Jeśli wyszukiwarka pominęła istotny dokument albo podała trzy podobne, lecz nie ten właściwy, odpowiedź nadal będzie brzmiała pewnie i spójnie. Nie masz jak tego wychwycić, bo widzisz tylko wynik, nie drogę do niego. Do tego dochodzi kwestia kosztów: samo przeszukiwanie ogromnej bazy kosztuje dostawcę, więc bywa robione oszczędnie, czyli mniej dokładnie, niż sugeruje marketing.
Nikt tego nie zepsuł, tak po prostu działa to podejście. Automat wybiera za Ciebie, szybko, ale bez pokazywania, na czym oparł wybór.
Dlatego budując beDocs świadomie zrezygnowałem z automatycznego przeszukiwania wielkiej bazy przepisów i orzeczeń. Zamiast tego kontekst budujesz sam: wybierasz, co dokładnie trafia do modelu, i widzisz to przed wysłaniem. Wolniej, ale bez niespodzianek, i z odpowiedzią, którą da się zweryfikować, bo wiesz, z czego powstała. Tak samo wyleciał z programu gotowy już moduł czatu, o czym pisałem tutaj.
Ta sama logika stoi za brakiem własnej bazy aktów prawnych. To Ty jako prawnik najlepiej wiesz, który artykuł i które orzeczenie ma znaczenie w Twojej sprawie. Program podpowie artykuły z kodeksów na podstawie treści dokumentu, a w module Szukaj sięgnie do API Sejmu i SAOS, ale przepis nigdy nie trafia do modelu sam z siebie. Dodajesz go Ty. Szerzej rozpisałem te decyzje w tekście o trzech obawach prawników wobec AI.
RAG, manualny czy automatyczny, nie eliminuje halucynacji całkowicie, bo model wciąż może błędnie zinterpretować dostarczony fragment. Ale radykalnie zmniejsza ryzyko przy faktach, bo źródłem prawdy przestaje być rozmyta pamięć wag, a staje się konkretny, sprawdzalny tekst, do którego można dopisać cytat i odnośnik.
Co z tego wynika dla Twojej kancelarii
Wybór narzędzia AI do pracy z aktami to najpierw decyzja inżynierska, dopiero potem merytoryczna. Ile pamięci ma karta, jak duży jest model, w jakiej precyzji jest zapisany, czy architektura jest gęsta, czy MoE. To wszystko z góry przesądza, czy narzędzie obsłuży stustronicową umowę płynnie, czy zacznie się krztusić już przy dłuższym piśmie procesowym. I to zanim jeszcze zaczniesz oceniać jakość odpowiedzi.
Druga decyzja jest czysto merytoryczna: czy narzędzie opiera się wyłącznie na „pamięci” modelu, czy sięga po mechanizm dostarczania kontekstu, automatyczny RAG, ręczne budowanie kontekstu albo połączenie obu. Poleganie na samej pamięci jest szybsze i tańsze, ale przy konkretnych faktach, sygnaturach, datach, treści przepisów, niesie realne ryzyko halucynacji. Podejście oparte na kontekście jest wolniejsze, za to jako jedyne pozwala zweryfikować odpowiedź, bo stoi za nią konkretny fragment tekstu, a nie samo prawdopodobieństwo.
A między automatycznym RAG-iem, a ręcznym budowaniem kontekstu wybierasz w gruncie rzeczy między wygodą, a kontrolą nad tym, co model zobaczył. Ja wybrałem kontrolę i wiem, że to kompromis: w beDocs pracuje się wolniej i bardziej ręcznie, za to zawsze wiesz, co model dostał.
I to jest test, który warto zrobić każdemu dostawcy. Jeśli ktoś sprzedaje Ci narzędzie AI do kancelarii i nie potrafi powiedzieć, w jaki sposób model dostaje kontekst, skąd wiesz, co dokładnie w nim wylądowało, i dlaczego akurat tak to zaprojektowano, to pytanie warto zadać, zanim podpiszesz umowę.
