Ile danych potrzebuje asystent AI w biurze technicznym: realny sizing

Czas czytania: ok. 6 minut · Dla kogo: kierownicy biur technicznych, osoby szacujące zakres pilotażu asystenta AI, właściciele firm produkcyjnych zastanawiający się, ile dokumentacji trzeba zebrać.

Werdykt na górze: o jakości asystenta AI w biurze technicznym nie decyduje liczba gigabajtów, tylko liczba spójnych, aktualnych i jednoznacznych źródeł. Korpus na 300 czystych, ustrukturyzowanych stron potrafi dać lepszy retrieval niż 30 tysięcy stron pełnych duplikatów i starych wersji. Naiwna konfiguracja („wrzućmy cały dysk sieciowy”) zawodzi nie z powodu braku danych, tylko ich nadmiaru bez porządku.

Odpowiedź najpierw

Nie ma jednego „minimum dokumentów”, od którego asystent AI zaczyna działać. To pytanie zadane od złej strony. Retrieval augmented generation (RAG) nie uczy się waszej dokumentacji tak, jak człowiek. Za każdym pytaniem wyszukuje kilka najbardziej pasujących fragmentów i tylko na nich buduje odpowiedź. Jakość zależy więc od tego, czy właściwy fragment da się znaleźć i czy nie konkuruje z pięcioma nieaktualnymi wersjami tego samego dokumentu.

W praktyce już kilkaset dobrze przygotowanych stron wystarcza, by asystent sensownie odpowiadał na pytania o konkretny wyrób lub proces. Problem nie pojawia się przy zbyt małym korpusie, tylko wtedy, gdy korpus rośnie bez kontroli: duplikaty, skany bez warstwy tekstowej, dwadzieścia rewizji tej samej instrukcji. Poniżej pokazuję, jak czytać wolumen dokumentów przez pryzmat jakości retrievalu, a nie samej wielkości.

Sizing przez pryzmat retrievalu, nie objętości

Przydatna jednostka to nie „liczba plików” ani „rozmiar w GB”, tylko liczba fragmentów, czyli chunków. Dokument dzieli się na kawałki po kilkaset tokenów każdy, a to one trafiają do indeksu i to je wyszukiwarka porównuje z pytaniem. Instrukcja na 40 stron to kilkadziesiąt chunków. Dziesięć tysięcy stron dokumentacji to grubo ponad kilkanaście tysięcy chunków, a wraz z nimi rośnie ryzyko, że na jedno pytanie znajdzie się kilka podobnych, sprzecznych fragmentów.

Poniższa tabela to orientacyjne progi inżynierskie, nie wynik u konkretnego klienta. Traktuj je jako mapę ryzyka, nie jako obietnicę.

Wolumen korpusu	Rząd chunków	Główne ryzyko	Co realnie decyduje o jakości
do około 300 stron	setki	prawie żadne	poprawny podział na sekcje
300 do 3000 stron	tysiące	pierwsze duplikaty i stare wersje	metadane: wyrób, wersja, data
3000 do 30000 stron	kilkanaście do stu tysięcy	rozjazd wersji, skany bez OCR	filtrowanie po metadanych, reranking
powyżej 30000 stron	setki tysięcy plus	szum przytłacza sygnał	twarda kuracja korpusu przed indeksem

Wniosek z tabeli jest niewygodny dla intuicji: przejście z 3000 do 30000 stron nie poprawia asystenta liniowo. Często go pogarsza, jeśli te dodatkowe strony to kolejne wersje i kopie tego samego. Więcej danych bez porządku to więcej okazji, by retrieval wciągnął zły fragment.

Dlaczego naiwna konfiguracja się wykłada

Zespoły najczęściej zaczynają od „podłączmy cały dysk działu i zobaczmy”. Oto konkretne przyczyny, dla których to zwykle zawodzi:

1. Duplikaty i rewizje. Ta sama instrukcja w wersji 3, 4 i 5 leży w trzech folderach. Wyszukiwarka nie wie, która obowiązuje, i cytuje przypadkową. Odpowiedź brzmi wiarygodnie, a jest z wycofanej wersji.
2. Skany bez warstwy tekstowej. Duża część starszej dokumentacji technicznej to PDF ze zdjęć. Bez OCR to dla modelu pusta strona. Wolumen jest, treści w indeksie nie ma.
3. Brak metadanych. Jeśli chunk nie wie, do jakiego wyrobu, wersji i daty należy, nie da się go odfiltrować. Pytanie o wyrób A wciąga fragment o wyrobie B, bo brzmi podobnie.
4. Zbyt duże albo zbyt małe chunki. Za duże mieszają kilka tematów w jednym fragmencie i rozmywają trafienie. Za małe gubią kontekst, na przykład numer tabeli bez jej zawartości.
5. Brak rerankingu. Sama wyszukiwarka wektorowa zwraca „podobne”, niekoniecznie „właściwe”. Bez drugiego przejścia, które przesortuje kandydatów, model dostaje przeciętny materiał.

Wspólny mianownik: żadnego z tych problemów nie rozwiązuje dorzucanie danych. Rozwiązuje je porządek przed indeksowaniem i konfiguracja retrievalu po nim.

Praktyczny próg sensowności

Zamiast pytać „ile dokumentów potrzebuję”, zapytaj o cztery rzeczy:

• Czy mam jedno źródło prawdy na wyrób lub proces, czy kilka konkurujących wersji?
• Czy dokumenty mają warstwę tekstową (nie tylko skan)?
• Czy da się do każdego fragmentu dopiąć metadane: wyrób, wersja, data, dział?
• Czy ktoś utrzyma korpus po wdrożeniu, czy zamrozi się w dniu startu?

Jeśli odpowiedzi są na tak, sensowny pilot da się zbudować już na wąskim wycinku, na przykład na dokumentacji jednej linii wyrobów. Jeśli na nie, żaden wolumen tego nie nadrobi, a duży korpus tylko zwiększy szum. Lepszy jest mały, kuratorowany zakres niż wielki i zaśmiecony.

Footprint: co to znaczy dla infrastruktury

Sama baza wektorowa dla kilkudziesięciu tysięcy chunków to rząd pojedynczych gigabajtów, więc to nie storage jest wąskim gardłem. Realne koszty to moc na liczenie embeddingów przy każdej zmianie dokumentacji oraz pamięć modelu odpowiadającego. Dla asystenta na jeden dział, działającego lokalnie, wystarczy zwykle jedna karta GPU klasy serwerowej. Skok kosztu przychodzi nie od liczby stron, tylko od liczby równoczesnych użytkowników i od tego, jak często reindeksujecie korpus.

Czego ten post nie pokrywa

Nie wchodzę tu w wybór konkretnego modelu ani w benchmark embeddingów, bo to zależy od języka dokumentacji i sprzętu. Nie omawiam też kosztu wdrożenia w złotówkach ani ROI, bo to temat na osobną analizę biznesową. Pomijam bezpieczeństwo i kwestie on-prem kontra chmura, które opisujemy w osobnych postach. Skupiam się wyłącznie na relacji: ile i jakich danych wobec jakości odpowiedzi.

Powiązane

• RAG do dokumentacji technicznej: jak AI korzysta z DTR i instrukcji maszyn
• RAG bez halucynacji: chunking, retrieval i co decyduje o jakości
• AI do zarządzania wiedzą serwisową: jak zasilić system i gdzie są granice
• AI w biurze konstrukcyjnym: co realnie automatyzuje, a co tylko obiecuje
• AI w kontroli jakości dokumentacji technicznej: co wychwytuje, czego nie