Polski model językowy w zamkniętej sieci: Bielik i PLLuM

Polski model językowy uruchomiony we własnej infrastrukturze wystarczy do wielu zadań: streszczania pism, odpowiadania na pytania z dokumentów, porządkowania korespondencji czy pierwszej wersji odpowiedzi. Nie wystarczy tam, gdzie trzeba długiego kontekstu, wieloetapowego rozumowania albo bardzo specjalistycznej polszczyzny. Instytucje, które rozważają Bielika albo PLLuM w zamkniętej sieci, najczęściej rozczarowują się nie samym modelem, tylko wymaganiami, które go nie uwzględniały. Poniżej opisuję, skąd bierze się potrzeba takiego wdrożenia, jakie są realne ograniczenia, jaki wariant awaryjny warto przewidzieć i jak to zapisać.

Dlaczego instytucje chcą modelu we własnej infrastrukturze

Powód jest zwykle jeden: dane nie mogą opuścić sieci organizacji. Chodzi o dane osobowe obywateli lub klientów, tajemnicę przedsiębiorstwa, dokumenty wewnętrzne albo po prostu politykę bezpieczeństwa, która nie przewiduje wysyłania treści do usług w chmurze. W takiej sytuacji publiczne API dużego dostawcy odpada niezależnie od jakości modelu.

Polskie modele są tu naturalnym kandydatem. Bielik jest rozwijany przez społeczność SpeakLeash razem z ACK Cyfronet AGH, a PLLuM powstał w konsorcjum polskich instytucji naukowych na zlecenie Ministerstwa Cyfryzacji. Oba są trenowane z myślą o polszczyźnie, mają otwarte wagi i dają się uruchomić na własnym serwerze z GPU, bez połączenia z internetem. To ważny argument przy zamówieniach, w których liczy się pochodzenie i przejrzystość rozwiązania.

Trzeba przy tym pamiętać, że model to tylko część systemu. Ogólne zasady korzystania z narzędzi AI na danych firmy opisałem w tekście o tym, jak chronić dane firmowe w narzędziach AI.

Realne ograniczenia małych modeli

Modele, które mieszczą się na jednym serwerze z GPU, są mniejsze od tych udostępnianych przez API największych dostawców. To ma konsekwencje, które warto znać przed podpisaniem umowy, a nie po pierwszych testach z użytkownikami.

• Długi kontekst. Model może deklarować obsługę długich dokumentów, ale jakość odpowiedzi przy bardzo długim wejściu zwykle spada. Przy obszernych aktach lepiej dzielić dokumenty i wyszukiwać fragmenty, niż wklejać wszystko naraz.
• Rozumowanie wieloetapowe. Zadania wymagające zestawienia kilku przepisów, policzenia terminów albo porównania wariantów wychodzą słabiej niż w dużych modelach. Takie zadania lepiej rozbić na kroki albo zostawić człowiekowi.
• Polszczyzna specjalistyczna. Dobra polszczyzna ogólna nie oznacza znajomości języka prawniczego, medycznego czy technicznego danej branży. Terminologię trzeba sprawdzić na prawdziwych dokumentach organizacji.
• Infrastruktura. Własny serwer oznacza własny monitoring, aktualizacje i plan na awarię GPU.

Nie podaję tu wyników benchmarków, bo dla decyzji liczy się co innego: jak model radzi sobie z Twoimi dokumentami i Twoimi pytaniami. Sprawdza się to na zestawie pytań od przyszłych użytkowników, tak jak opisywałem przy wdrożeniu asystenta na dokumentach.

Jak sprawdzić model przed decyzją

Zanim wybierzesz model, sprawdź go na własnym materiale. Test nie musi być rozbudowany, ale musi być powtarzalny, żeby dało się nim porównać dwa modele albo dwie wersje tego samego modelu.

1. Zbierz prawdziwe dokumenty, najlepiej różnego rodzaju: pisma, procedury, notatki, tabele.
2. Poproś przyszłych użytkowników o pytania, które naprawdę zadają w pracy, razem z oczekiwaną odpowiedzią i jej źródłem.
3. Dodaj zadania trudne: długi dokument, porównanie kilku pism, branżowe słownictwo. To tam widać różnice między modelami.
4. Oceniaj odpowiedzi według tych samych kryteriów: poprawność, zgodność ze źródłem, poprawność języka, przyznanie się do niewiedzy.
5. Zapisz wyniki i warunki testu, czyli model, wersję, ustawienia i sprzęt, żeby test dało się powtórzyć po aktualizacji.

Taki test pokazuje też, które zadania warto od razu przenieść do wariantu awaryjnego albo zostawić człowiekowi.

Wariant awaryjny: model w chmurze dla zadań bez danych wrażliwych

Rozsądnym uzupełnieniem lokalnego modelu jest model w chmurze, używany tylko do zadań, w których nie ma danych wrażliwych. Przykłady: redakcja ogólnych komunikatów, tłumaczenie treści publicznych, pomoc przy kodzie albo analiza dokumentów, które i tak są jawne.

Żeby to działało bezpiecznie, podział musi wynikać z reguł, a nie z decyzji użytkownika w danej chwili:

1. Spisz kategorie danych i przypisz każdej dozwolone miejsce przetwarzania.
2. Domyślnie kieruj wszystko do modelu lokalnego.
3. Dopuść model w chmurze tylko dla wskazanych zastosowań i z wybranym regionem centrum danych.
4. Loguj, które zapytanie trafiło do którego modelu.

O tym, jak wygląda uruchomienie modelu na GPU w chmurze, w tym region i zimny start, pisałem w tekście o tym, kiedy własny model językowy w chmurze ma sens.

Jak zapisać polski model językowy w wymaganiach

Wymagania powinny opisywać zadania i sposób sprawdzenia jakości, a nie tylko nazwę modelu. Zapis „system wykorzysta polski model językowy działający lokalnie” nie mówi nic o tym, czy użytkownicy będą zadowoleni.

• Lista zadań, które model ma wykonywać, z przykładowymi dokumentami i pytaniami.
• Zadania, których model nie wykonuje, albo wykonuje tylko jako propozycję dla człowieka.
• Sposób odbioru: zestaw pytań testowych, kto go przygotowuje i kto ocenia odpowiedzi.
• Zasady zmiany modelu na nowszą wersję i ponownego testu.
• Wymagania sprzętowe po stronie zamawiającego albo wykonawcy, zapisane jednoznacznie.
• Warunki użycia modelu w chmurze, jeśli w ogóle jest dopuszczony.

Taki opis chroni obie strony. Zamawiający wie, co dostanie, a wykonawca nie odpowiada za oczekiwania, których nikt nie zapisał.

Polski model językowy w zamkniętej sieci to dobry wybór, gdy dane muszą zostać na miejscu, a zadania są dobrze opisane i sprawdzone na prawdziwych dokumentach. Jeśli przygotowujesz takie wymagania i chcesz je skonsultować przed ogłoszeniem, napisz do mnie przez formularz.