RAG do polityki HR dostosowanej do procesu produkcji przy użyciu LangChain i LangGraph
Przełykanie, MMR, przepisywanie z uwzględnieniem historii, oparte na faktach odpowiedzi, zasady bezpieczeństwa, ocena, cytaty oraz orkiestracja grafów dla asystenta ds. polityk HR.
Wprowadzenie
Dla działów kadr w przedsiębiorstwach niewystarczające są jedynie płynne odpowiedzi generatywne. Asystent ds. polityk nie powinien sam wymyślać zasad urlopów na podstawie wstępnego szkolenia – powinien pobierać zatwierdzone dokumenty i opierać każde twierdzenie na tych źródłach. To właśnie jest zadaniem generatywnej sztucznej inteligencji wzbogaconej o wyszukiwanie informacji (RAG).
Modułowa platforma typu production do zarządzania polityką HR w formie pytań i odpowiedzi może łączyć Python, LangChain, LangGraph, model czatowy kompatybilny z OpenAI, ChromaDB, Streamlit, embeddingi, mechanizmy wyszukiwania typu MMR, przepisywanie zapytań z uwzględnieniem historii, projektowanie promptów, moderację wprowadzanych danych, sprawdzanie prób iniekcji promptów, ocenę wyników wyszukiwania, pamięć konwersacyjną, streszczanie oraz eksport do PDF. Celem nie jest zwykły bot czatowy — chodzi o system RAG, który traktuje poważnie jakość wyszukiwania informacji, kontekst rozmowy, bezpieczeństwo, ocenę oraz użyteczność.
1. Problem
Gdy ktoś pyta „Ile dni urlopu chorobowego jest dozwolonych?”, zwykły model LLM może wymyślić odpowiedź. Asystent ds. HR powinien natomiast:
- Zrozumieć pytanie
- Przeszukać organizacyjne dokumenty HR
- Znaleźć najbardziej istotne fragmenty
- P przekazać te fragmenty modelowi
- Stworzyć odpowiedź opartą na tych danych
Opis procesu na wyższym poziomie: dokumenty HR → przetwarzanie → dzielenie na fragmenty + metadane → wektory embeddingów → ChromaDB → mechanizm wyszukiwania → zapytanie uwzględniające historię → odpowiednie dokumenty → spersonalizowany prompt → odpowiedź → cytaty.
2. Przetwarzanie dokumentów
Surowe polityki stają się fragmentami nadającymi się do wyszukiwania. Pełne dokumenty są zbyt duże, by zostać włączone do każdego promptu, i mogą przekroczyć limity kontekstu. Fragmenty zawierają metadane takie jak nazwa pliku, ścieżka, folder, typ dokumentu oraz etykiety źródła — przydatne później do cytowania, debugowania oraz analizy wyników wyszukiwania.
3. Wektory embeddingów i przechowywanie wektorowe
Każdy fragment staje się wektorem embeddingu:
"Employees receive annual leave..."
↓
Embedding Model
↓
[0.12, -0.43, 0.87, ...]
Wektory oraz metadane trafiają do ChromaDB. Pytania użytkowników są również przekształcane w wektory w ten sam sposób, dzięki czemu polityki semantycznie podobne pojawiają się nawet wtedy, gdy sformułowanie jest inne („urlop z powodu choroby” vs „prawo do urlopu chorobowego”).
4. Wyświetlanie z użyciem MMR
Prosta metoda podobieństwa top-k może zwrócić cztery niemal identyczne fragmenty polityki urlopowej:
Chunk 1 → Leave policy
Chunk 2 → Leave policy
Chunk 3 → Leave policy
Chunk 4 → Leave policy
Maksymalna marginalna istotność równoważy istotność z różnorodnością. Większa grupa kandydatów fetch_k, a następnie selekcja końcowych k za pomocą MMR, zmniejsza redundancję:
10,000 chunks
↓
Similarity search
↓
20 candidate chunks
↓
MMR
↓
4 diverse + relevant chunks
↓
LLM
5. Wyświetlanie z uwzględnieniem historii
Zapytania takie jak „A co z menedżerami?” po odpowiedzi dotyczącej urlopu rocznego są same w sobie niejednoznaczne. Krok uwzględniający historię przepisuje zapytanie, korzystając z historii rozmowy przed wyświetleniem wyników:
Conversation History
+
Current Question
↓
LLM
↓
Standalone Search Query
To oddziela kontekstualizację zapytania (co miał na myśli użytkownik?) od generowania odpowiedzi (co powinna zawierać odpowiedź w oparciu o dostępne dokumenty?).
6. Generowanie odpowiedzi opartej na faktach
Pobrane fragmenty trafiają do promptu, który każe modelowi korzystać wyłącznie z dokumentów HR, unikać wymyślania polityk, uwzględniać wykluczenia, być zwięzłym oraz przyznawać się do braków. Architektura: pytanie → kontekstualizacja → narzędzie pobierania danych → dokumenty → prompt do weryfikacji → model językowy → odpowiedź oparta na faktach. Model pisze prozę; korpus dostarcza faktów.
7. Dlaczego LangGraph
Gdy liczba etapów rośnie — walidacja, moderacja, wykrywanie iniekcji, przetwarzanie zapytań, pobieranie danych, generowanie, pamięć, streszczanie — liniowa łańcuchowa struktura staje się krucha. LangGraph modeluje przepływ pracy jako stany i węzły:
User Input
↓
Validation
↓
Guardrails
↙ ↘
Safe Unsafe
↓ ↓
RAG Workflow Reject
↓
Final Response
↓
Conversation
Management
Graf jest łatwiejszy do rozszerzenia niż jedna megafunkcja.
8. Zasady bezpieczeństwa
Dane wejściowe do produkcji wymagają weryfikacji przed zastosowaniem RAG:
- Moderacja — wcześnie blokowanie treści naruszających zasady
- Wykrywanie iniekcji promptów — odrzucanie ataków typu „ignoruj poprzednie instrukcje…”
Kolejność ma znaczenie: dane od użytkownika → sprawdzenia bezpieczeństwa → RAG, a nie dane od użytkownika → surowy model LLM.
9. Pamięć konwersacyjna i streszczanie
Asystenci działające w wielu rundach potrzebują historii rozmów, ale nieograniczone transkrypcje zużywają wiele zasobów. Streszczanie starszych rund pozwala zachować istotne informacje, jednocześnie ograniczając aktywny kontekst – to kompromis pomiędzy zachowaniem danych a kosztami.
10. Ocena procesu wyszukiwania
Odpowiedź może wyglądać płynnie, mimo że wyszukiwanie nie powiodło się. Należy sprawdzić, czy dotarły właściwe fragmenty tekstu, a nie tylko to, czy tekst w ogóle został przywrócony. Ocena jakości wyszukiwania, generowania treści oraz zachowania aplikacji powinna odbywać się jako odrębne etapy.
11. Citaty źródłowe
Lepiej używać sformułowań takich jak „Pracownicy mają 20 dni urlopu rocznego (Polityka urlopów §3)” zamiast samych stwierdzeń. Citaty zwiększają zaufanie, ułatwiają debugowanie i umożliwiają śledzenie źródeł, gdy pracownicy mogą otworzyć oryginalny plik PDF.
12. Eksport rozmowy w formacie PDF
Eksport rozmowy do formatu PDF umożliwia pracownikom przechowywanie jej kopii do późniejszego użycia. Jest to detal dotyczący użyteczności, który wskazuje, że system jest przeznaczony do rzeczywistej pracy, a nie do chwilowego czatu.
Zakończenie
Prawdziwy asystent HR RAG to zbiór etapów obejmujących pobieranie danych, strategię wyszukiwania, przepisywanie rozmowy, uzasadnianie odpowiedzi, koordynację grafów, zasady bezpieczeństwa, ocenę jakości oraz cytowanie źródeł. LangChain i LangGraph pomagają w realizacji tych etapów; Chroma oraz MMR określają, co model może oglądać. Niepodważalną zasadą produktu pozostaje to, że odpowiedzi pochodzą z zatwierdzonych dokumentów, a nie z pamięci modelu zawierającej informacje z Internetu.
Wybory projektowe istotne w praktyce
Rozmiar fragmentów i ich nakładanie się nie są kwestią estetyczną. Zbyt duże fragmenty osłabiają sygnał embeddingu; zbyt małe tracą informacje o otaczających je ograniczeniach. Nakładanie się pomaga, gdy reguła obejmuje granicę między różnymi sekcjami. Metadane nie są opcjonalną dekoracją – bez nazwy pliku i wskazówek dotyczących sekcji cytaty stają się niejasne, a zestawy do oceny trudne do oceny.
Parametry MMR (fetch_k, k, lambda różnorodności) powinny być dostrojone na podstawie zaznaczonych zbiorów pytań, a nie intuicji. Zbyt mała grupa kandydatów nigdy nie ujawni różnorodnych fragmentów tekstu; zbyt duża grupa marnuje czas oczekiwania.
Przepisywanie z uwzględnieniem historii nie powinno wymyślać faktów. Krok przepisywania powinien jedynie rozwijać zaimki oraz niekompletne kontynuacje w samodzielne zapytania wyszukiwawcze. Jeśli model przepisywania zacznie odpowiadać na pytania, system wyszukiwania nigdy nie otrzyma czystego zapytania.
Zasady bezpieczeństwa muszą obowiązywać przed wykrywaniem danych. Moderacja oraz detekcja prób wstrzykiwania treści, które działają po tym, jak model już przeczytał tekst polityki prywatności, są zbyt późne. W przypadku podejrzenia wstrzykiwania treści należy natychmiast odmówić dostępu; dopuszcza się otwarte postępowanie tylko wtedy, gdy polityka produktu wyraźnie zezwala na łagodne blokowanie z rejestracją działań.
Ocena powinna uwzględniać zarówno proces wykrywania danych (recall@k oczekiwanych identyfikatorów dokumentów), jak i proces generowania odpowiedzi (wierność tekstowi wykrytemu). Piękna odpowiedź oparta na błędnej klauzuli nadal stanowi niepowodzenie. Należy przechowywać ślady: przepisany zapytanie, identyfikatory dokumentów, ostateczną odpowiedź oraz listę odniesień.
Streamlit (lub każde inne proste interfejsy użytkownika) powinien wyraźnie pokazywać odniesienia oraz stany „nieznane”. Pracownicy bardziej ufają systemom, które przyznają istnienie luki w funkcjonowaniu, niż tym, które wymyślają rozległe zasady dotyczące urlopów.
Eksport do PDF to funkcja służąca przechowywaniu danych: ludzie wklejają odpowiedzi z polityk do zgłoszeń. Tekst wyeksportowany należy traktować jako potencjalnie wrażliwy i stosować do niego te same kontrole dostępu co do sesji czatowej.
Najważniejsze jest, aby ścieżka realizacji zadania w grafie była oczywista. Nowi inżynierowie powinni móc narysować sekwencję: walidacja → przepisanie → pobranie → generowanie → odpowiedź, bez konieczności przeszukiwania opcjonalnych gałęzi. Opcjonalne gałęzie (streszczanie, eksport) są powiązane z wyraźnymi węzłami, a nie znajdują się wewnątrz procesu generowania.
Taka dyscyplina przekształca demo RAG na weekend w coś, co zespół HR może wypróbować bez obaw o niepożądane błędy wynikające z niewłaściwego stosowania zasad.
Układanie elementów w harmonogramie
HR DOCUMENTS
│
▼
DOCUMENT INGESTION
│
Chunking + Metadata
│
▼
EMBEDDINGS
│
▼
CHROMADB
│
▼
RETRIEVER
(MMR Search)
│
│
USER ──→ GUARDRAILS ─────┤
│
▼
HISTORY-AWARE QUERY
CONTEXTUALIZATION
│
▼
RETRIEVAL
│
▼
RELEVANT DOCUMENTS
│
▼
QA PROMPT + LLM
│
▼
GROUNDED ANSWER
│
┌────┴────┐
↓ ↓
Citations Memory
│
▼
Summarization
│
▼
PDF Export
Pierwszy dzień zazwyczaj skupia się na „wgrzewaniu plików PDF i czacie”. To właśnie od drugiego do dziesiątego dnia pojawiają się elementy kluczowe dla produkcji: schematy metadanych, dostrojenie MMR, polecenia do ponownego napisania tekstu, mechanizmy moderacji, klasyfikatory iniekcji, arkusze kalkulacyjne do oceny, formatowanie cytatów oraz podsumowywanie rozmów. Pominęcie tych kroków sprawia, że system dobrze funkcjonuje przy prostych zapytaniach, ale zawodzi przy drugiej próbie, w przypadku złośliwych polecenia lub przy wyszukiwaniu niemal identycznych treści.
LangChain pomaga połączyć obiekty modelu i mechanizmu wyszukiwania; LangGraph ułatwia sprawdzanie przepływu sterowania. Żaden z nich nie zastępuje decyzji biznesowych dotyczących tego, które foldery HR są autorytatywne, kto może pytać o określone zasady oraz jak wygląda „nieznana” treść w interfejsie użytkownika. Takie decyzje powinny znajdować się w dokumentacji projektowej obok diagramu grafu.
Gdy coś idzie nie tak w środowisku produkcyjnym, najszybszą drogą do debugowania jest zazwyczaj: sprawdzenie przepisanej zapytania, wylistowanie identyfikatorów pobranych fragmentów, odczytanie tych fragmentów, a następnie odczytanie odpowiedniego promptu. Jeśli ta ścieżka nie występuje w dziennikach, należy najpierw poprawić możliwości obserwacji, zanim dodano kolejny model.