5. Wybór działania: reguły i model

Lokalne chatboty, agenci i systemy RAG z własną bazą wiedzy

Praktyka po kursie · bez GUI

Asystent dokumentów w konsoli

Od działającego RAG do rozmowy i kontrolowanych narzędzi

Orientacyjny czas: 30 min · Tryb pracy: najpierw własna próba, potem przykład

Uzupełnij wybierz_reguly i wybierz_model w decyzja.py. W pierwszym wariancie program wybiera narzędzie na podstawie prostych warunków. W drugim model proponuje obiekt JSON. Oba warianty przechodzą potem przez ten sam walidator wykonania.

Wariant porównawczy: podstawową ścieżkę uruchamiaj w trybie reguly. Selektor modelowy może pomylić narzędzie lub argumenty; jego odrzucenie jest wynikiem do analizy. W końcowej próbie autorskiej reguły spełniły oczekiwania w 18/18 tur, a model w 15/18. To pomiar przebiegu na małym zestawie ćwiczeniowym, nie ocena jakości odpowiedzi ani gwarancja na nowych pytaniach.

Zacznij od reguł

  1. Dla obsługiwanej prośby o źródła zwróć show_last_sources z pustymi arguments.
  2. Dla słowa odnoszącego się do metadanych wyszukaj jedno jawne ID i zaproponuj get_document_metadata.
  3. Inne pełne pytanie skieruj do answer_from_documents z pustymi arguments. Pełne pytanie dopisze aplikacja po sprawdzeniu propozycji.
  4. Każda propozycja musi mieć dokładnie cztery pola pokazane poniżej.
{
  "decision": "tool_call",
  "action": "answer_from_documents",
  "arguments": {},
  "message": null
}

Następnie dołącz selektor LLM

  1. Zbuduj opis trzech narzędzi i oczekiwanego JSON. Model ma wybierać, a nie odpowiadać użytkownikowi ani wykonywać kod.
  2. Przekaż bieżącą wiadomość, pełne pytanie, wcześniejsze pytania, informację o zapisanych źródłach i znane ID dokumentów.
  3. Wywołaj /api/chat z stream=false i format="json". Zachowaj całe żądanie oraz surową odpowiedź do diagnostyki.
  4. Odczytaj message.content przy użyciu scisly_json, a potem sprawdz_propozycje. Jeśli generacja została ucięta albo struktura jest błędna, zwróć brak propozycji i opis błędu. Nie przełączaj automatycznie na reguły.

Dwie walidacje: poprawny składniowo JSON nie musi mieć poprawnego schematu; poprawny schemat nie gwarantuje dozwolonej nazwy narzędzia ani poprawnych argumentów. Format JSON w Ollama pomaga uzyskać obiekt, lecz nie zastępuje kontroli w aplikacji.

Dla decyzji clarification_needed, rejected lub no_suitable_tool przyjmij action=null, arguments={} i krótki message. Nie pobieraj „naprawionego JSON” z kolejnego wywołania modelu — w tym projekcie błąd ma pozostać widoczny.

python -m unittest sprawdz.Decyzja -v

Grupa Decyzja sprawdza parser i schemat. Własny selektor sprawdzisz również w przepływie i w scenariuszach z modelem. Wybór przez model może trwać dłużej: pytanie do dokumentów wymaga wtedy wywołania selektora, embeddingu pytania i osobnej generacji odpowiedzi RAG.

Materiał uzupełniający do modułów 1–6 · wersja 1.0 · 30.09.2026