Budujemy RAG (retrieval-augmented generation) na Waszych dokumentach i danych strukturalnych — z cytatami, logiem audytowym i pilnowaniem halucynacji. Nie demo z konferencji, tylko wdrożenie produkcyjne: guardraile przeciwko prompt injection, cost gate przeciwko uciekającym kosztom i obserwowalność każdego wywołania LLM.
Prototyp RAG zbudujecie w popołudnie z tutorialem z YouTube. Wdrożenie produkcyjne, które nie halucynuje, nie wynosi cudzych danych i nie ucieka w kosztach, to zupełnie inna dyscyplina — i tam większość dostawców się zatrzymuje.
Na pięciu testowych pytaniach odpowiedź się zgadza. W produkcji, przy tysiącach realnych zapytań, model zaczyna zmyślać to, czego nie ma w danych, albo odpowiada pewnie źle — i nikt tego nie wyłapuje, bo brakuje logu audytowego i monitoringu pewności.
Prompt injection z wejścia użytkownika albo z zaindeksowanego dokumentu potrafi obejść instrukcje i wyciągnąć dane, do których odpowiedź nie powinna mieć dostępu. Bez jawnych guardraili i niskiej temperatury dla zapytań faktograficznych to nie jest pytanie czy, tylko kiedy.
Bez cost gate i bez przemyślenia, kiedy wywołać drogi model, a kiedy wystarczy tańszy, koszty wywołań LLM rosną liniowo z ruchem i nikt ich nie pilnuje — dopóki nie przyjdzie faktura, która boli.
Retrieval, generowanie i utrzymanie traktujemy jako system produkcyjny od pierwszej linii — nie jako proof-of-concept, który potem trzeba przebudować, żeby w ogóle dało się go wdrożyć.
Wyszukiwanie semantyczne (embeddings + baza wektorowa) połączone z klasycznym dopasowaniem słów kluczowych, żeby odpowiedź znalazła też to, co czysto semantycznie nie pasuje — dokładne liczby, kody, nazwiska.
Tam, gdzie dane są strukturalne (bazy danych, tabele), generujemy zapytania bezpośrednio, z automatyczną naprawą, gdy zapytanie zawiedzie albo zwróci pusty wynik — zamiast żeby asystent "zgadywał" na podstawie tekstowego opisu danych.
Niska temperatura dla dokładności faktograficznej, jawna granica między instrukcjami a danymi oraz human-in-the-loop na granicznych przypadkach, gdzie system nie jest pewny — ta sama zasada co przy naszej ekstrakcji danych z faktur.
Każde wywołanie LLM jest logowane — co weszło, co wyszło, z jakiego źródła pochodziła odpowiedź. Użytkownik widzi cytat, Wy macie ślad audytowy, gdy trzeba wstecz sprawdzić, dlaczego asystent odpowiedział tak, jak odpowiedział.
Wybieramy model zależnie od złożoności zapytania, używamy prompt cachingu (Anthropic) dla powtarzającego się kontekstu i pilnujemy kosztów, żeby nie uciekały wraz z rosnącym ruchem — zamiast jednego drogiego modelu do wszystkiego.
W bardziej złożonych systemach multi-agentowych (jak miejski chatbot dla Zlína) flow i agenci są zdefiniowani jako wiersze w bazie danych, nie w kodzie — logikę można zmienić bez redeployu, co skraca cykl iteracji z miesięcy do tygodni.
Dla miasta Zlín zbudowaliśmy multi-agentowy silnik swarm z self-healing zapytaniami text-to-SQL — jeden z pierwszych działających chatbotów AI dla obywateli tego typu w Czechach, który wygrał regionalny hackathon AI. Do przetwarzania faktur wdrożyliśmy ekstrakcję danych AI z weryfikacją human-in-the-loop na granicznych przypadkach. Dla Continero (Robootec) zbudowaliśmy własne wyszukiwanie wektorowe na embeddingach OpenAI i pgvector, orkiestrację multi-provider LLM (Claude/OpenAI/Gemini/Grok) z prompt cachingiem Anthropic, własny serwer MCP i lokalny inferencing ONNX tam, gdzie chmura się nie sprawdza.
Powiedzcie nam, jakie dane asystent ma znać i do czego ma służyć — wsparcie, wewnętrzna baza wiedzy, czy coś w rodzaju chatbota dla obywateli. Zaproponujemy architekturę (retrieval, guardraile, cost gate) i szczerze powiemy, co jest realne w jakim czasie i budżecie.
Zapytaj o asystenta RAG →