RAG na kartach technicznych: porządek w danych przed promptem

Twoi doradcy techniczni codziennie szukają odpowiedzi w kartach technicznych, deklaracjach i certyfikatach, a klienci czekają? Asystent oparty na RAG na kartach technicznych potrafi skrócić to szukanie, ale tylko wtedy, gdy dokumenty są uporządkowane. Z mojego doświadczenia przy projektach RAG wynika, że jakość odpowiedzi zależy bardziej od porządku w danych niż od dopracowanego promptu. Na przykładzie producenta chemii budowlanej pokazuję, do czego taki asystent się nadaje, jakie dwie zasady przy danych stosuję i jak zacząć od jednego procesu.

Czym jest RAG na kartach technicznych produktów

RAG to sposób działania asystenta AI, w którym model najpierw wyszukuje fragmenty twoich dokumentów, a dopiero potem na ich podstawie formułuje odpowiedź. Model nie odpowiada z pamięci, tylko z tego, co znalazł, i może wskazać źródło.

Karty techniczne są do tego dobrym materiałem, bo mają powtarzalną strukturę: zastosowanie, przygotowanie podłoża, sposób użycia, zużycie, czas schnięcia, warunki stosowania, przechowywanie. Kłopot zaczyna się wtedy, gdy ta sama karta istnieje w kilku wersjach, w kilku miejscach, a część informacji jest tylko w katalogu albo w odpowiedziach działu technicznego wysłanych mailem. Szerzej o tym, czego od RAG nie oczekiwać, pisałem w tekście o tym, czego nie obiecywać przy wdrożeniu asystenta RAG.

Do czego asystent na kartach technicznych się przydaje

Weźmy producenta chemii budowlanej, który ma szeroką ofertę zapraw, klejów, gruntów i hydroizolacji. Asystent oparty na jego dokumentach może obsłużyć kilka typowych pytań:

• Dobór produktu: jaki klej do płytek na ogrzewanie podłogowe na zewnątrz, jaki grunt pod dany system.
• Wyliczenie zużycia: ile materiału potrzeba na daną powierzchnię przy podanej grubości warstwy.
• Zamienniki: co zamiast produktu wycofanego albo chwilowo niedostępnego.
• Deklaracje i certyfikaty: szybkie odnalezienie właściwego dokumentu dla produktu.
• Wsparcie projektantów: odpowiedzi na pytania o parametry i warunki stosowania, ze wskazaniem karty.

Przy wyliczeniu zużycia warto zachować ostrożność. Model powinien odczytać z karty normę zużycia, ale samo mnożenie lepiej zrobić zwykłym kodem. Wtedy wynik jest powtarzalny, a model tylko podaje dane wejściowe i źródło.

Równie ważne jest to, czego asystent robić nie powinien. Jeśli w dokumentach nie ma odpowiedzi, ma to powiedzieć wprost i skierować pytanie do działu technicznego, zamiast zgadywać. W branży budowlanej zgadywanie jest kosztowne: zły dobór produktu wychodzi na jaw dopiero na budowie, po położeniu materiału. Dlatego już na starcie projektu warto ustalić, jakie pytania asystent ma odrzucać, na przykład te o odpowiedzialność za wykonanie albo o warunki gwarancji.

Zasada pierwsza: osobne bazy wiedzy dla każdego źródła

Karty techniczne, deklaracje, certyfikaty, katalog handlowy i wewnętrzne notatki działu technicznego powinny trafić do osobnych baz wiedzy. Każde z tych źródeł ma innego właściciela, inny cykl zmian i inną wiarygodność.

Gdy wszystko trafia do jednego worka, asystent potrafi połączyć zdanie z katalogu marketingowego z parametrem z karty i podać to jako fakt techniczny. Osobne bazy pozwalają ustalić, które źródło wygrywa przy sprzeczności, na przykład karta techniczna przed katalogiem. Pozwalają też pokazać użytkownikowi, skąd pochodzi odpowiedź, i wyłączyć jedno źródło bez przebudowy całości.

W praktyce oznacza to też, że każda baza ma osobę odpowiedzialną za jej aktualność. Bez tego po kilku miesiącach nikt nie wie, czy dokument w asystencie jest tym samym, który leży na stronie producenta.

Zasada druga: wersjonowanie dokumentów

Karty techniczne się zmieniają: zmienia się receptura, warunki stosowania, normy, zużycie. Jeśli asystent ma w bazie dwie wersje tej samej karty bez oznaczenia, która jest aktualna, może odpowiedzieć na podstawie starszej. To najczęstsze źródło błędnych odpowiedzi, które wyglądają przekonująco.

Wersjonowanie w praktyce oznacza:

• jednoznaczny identyfikator produktu i numer wersji przy każdym dokumencie,
• datę obowiązywania i informację, która wersja jest bieżąca,
• usuwanie albo archiwizowanie starej wersji przy wgraniu nowej,
• osobną ścieżkę dla produktów wycofanych, bo pytania o nie nadal padają,
• datę wersji widoczną w odpowiedzi asystenta.

Dlatego przy problemach z jakością odpowiedzi najpierw sprawdzam dane, a dopiero potem prompt. Poprawianie instrukcji dla modelu nie naprawi sytuacji, w której w bazie leżą dwie sprzeczne karty tego samego produktu.

Te dwie zasady to w większości praca porządkowa po stronie firmy, a nie programowanie. Podobny wniosek opisałem przy automatyzacji obiegu dokumentów z AI: najpierw porządek w dokumentach, potem automatyzacja.

Jak zacząć od jednego procesu

Najlepszy start to jeden proces, jedna grupa użytkowników i jedno źródło dokumentów. Zamiast budować asystenta do wszystkiego, wybierz pytania, które najczęściej trafiają do działu technicznego, i sprawdź, czy da się na nie odpowiedzieć z kart technicznych.

1. Zbierz prawdziwe pytania z maili i zgłoszeń, bez danych klientów.
2. Wybierz jedną grupę produktów i uporządkuj jej karty: aktualne wersje, identyfikatory, daty.
3. Przygotuj zestaw pytań testowych z poprawnymi odpowiedziami ustalonymi przez dział techniczny.
4. Uruchom asystenta wewnętrznie dla doradców, zanim pokażesz go klientom albo projektantom.
5. Mierz trafność i braki: pytania bez odpowiedzi pokazują, których dokumentów brakuje.

Dopiero gdy wewnętrzny asystent działa dobrze, warto myśleć o udostępnieniu go na zewnątrz. Różnice między narzędziem dla pracowników a chatbotem w obsłudze klienta są większe, niż się wydaje, głównie w zakresie odpowiedzialności za odpowiedź.

Jeśli rozważasz RAG na kartach technicznych, zacznij od przeglądu dokumentów jednej grupy produktów i sprawdzenia, ile ma wersji i kto je aktualizuje. Ta jedna lista powie więcej o szansach projektu niż porównanie modeli. Jeśli chcesz przejść przez nią razem ze mną, sprawdź zasady współpracy.