Modele i Providerzy

Cel

Warstwa modeli dostarcza zdolności poznawcze bez wiązania produktu z jedną nazwą, firmą lub formatem uruchomieniowym. Model jest zasobem o profilu możliwości; Provider Adapter jest wersjonowanym interfejsem do jego uruchomienia. Agent wybiera rolę i wymagania, a Router dopasowuje dostępnego providera według polityki.

Karta modułu

Pole	Kontrakt
Odpowiedzialności	rejestracja, health, routing, budżety, minimalizacja kontekstu, normalizacja odpowiedzi, ewaluacja jakości.
Wejścia	ModelRequest, context envelope, profil roli, klasyfikacja danych, koszt/latency ceiling.
Wyjścia	ProviderProposal, usage metrics, confidence hints, citations/evidence refs, błędy.
Zależności	Model Registry, provider adapters, Resource Scheduler, Context Builder, Artifact Store.
Uprawnienia	provider może zwrócić dane propozycji; nie dostaje capability wykonawczych ani approval credentials.
Autonomia	Router może zmienić model w obrębie zatwierdzonego profilu; wyjście poza lokalną granicę wymaga polityki.
Walidacja	schema, rozmiar, źródła, safety filters domenowe, benchmark roli, porównanie z testami.
Awaria	fallback lokalny, degradacja funkcji, kolejka oczekująca albo jawny brak wykonawcy.

Model Registry

Rekord modelu zawiera rodzinę, wersję, format, licencję, źródło i hash wag, wymagania sprzętowe, długość kontekstu, języki, modalności, profile jakości, podatność na kwantyzację, przewidywane zużycie VRAM/RAM, obsługę tool calling, ograniczenia oraz wyniki zatwierdzonych benchmarków. Nazwa marketingowa nie wystarcza do aktywacji.

Profile ról obejmują: orchestrator, coding, reasoning, vision, voice, fast oraz embedding/reranker. Model znakomity w kodzie może być słaby w rozmowie telefonicznej, a wersja o wysokiej jakości może być nieprzydatna do alarmu wymagającego odpowiedzi w 300 ms.

Provider Adapter

Adapter normalizuje różne runtime'y: lokalny serwer modeli, bibliotekę inference, urządzenie brzegowe lub API zewnętrzne. Obsługuje health, listę możliwości, request, streaming, anulowanie i metryki. Nie interpretuje uprawnień z tekstu. Wyjście zawsze jest ProviderProposal i pozostaje niezaufane, nawet gdy pochodzi z modelu lokalnego.

Routing wielokryterialny

Router ocenia zgodność z klasyfikacją i zakazami transmisji; wymagane modalności, język i format; minimalny poziom jakości z benchmarku roli; dostępność sprzętu i deadline; budżet energii, kosztu oraz latency; preferencję local-first; fallback i możliwość powtórzenia.

flowchart TD
    R["Wymagania roli"] --> D{"Dane mogą opuścić urządzenie?"}
    D -->|nie| L["Kandydaci lokalni"]
    D -->|tak| C["Lokalni + zatwierdzeni zewnętrzni"]
    L --> Q["Benchmark + zasoby + latency"]
    C --> Q
    Q --> S["Wybór + fallback chain"]
    S --> E["Wykonanie i ewaluacja"]
    E --> M["Metryki roli, bez samoczynnej aktywacji"]

Konsultacja wielu modeli

Dla zadania wysokiej wartości Planner może zamówić niezależne rozwiązania. Aggregator nie powinien łączyć ich stylistycznie bez weryfikacji. Najpierw normalizuje twierdzenia i dowody, wskazuje zgodność, konflikt oraz założenia. Następnie walidator deterministyczny lub domenowy ocenia elementy możliwe do sprawdzenia. Dopiero potem arbiter tworzy rekomendację. W przypadku nierozstrzygalności człowiek widzi alternatywy, a nie sztuczną pewność.

Przykładowe polecenia

• „Zrób prywatnie lokalną analizę tych umów; nie wysyłaj treści do zewnętrznego AI.”
• „Porównaj dwa modele vision na oznaczonym zestawie 500 klatek i nie aktywuj zwycięzcy.”
• „Użyj szybkiego modelu do klasyfikacji, a duży uruchom tylko dla przypadków niepewnych.”
• „Poproś zewnętrznego konsultanta wyłącznie o zanonimizowany schemat architektury.”

Pełny przebieg

W analizie poufnych umów Context Builder klasyfikuje dokumenty jako confidential i blokuje providerów zewnętrznych. Router wybiera lokalny model długiego kontekstu oraz deterministyczny parser sekcji. Model tworzy twierdzenia z odwołaniami do numerów klauzul. Drugi lokalny model sprawdza kompletność, a walidator wykrywa cytowania nieistniejących fragmentów. Wynik to candidate raport; decyzje prawne pozostają po stronie człowieka.

Certyfikacja i aktywacja

Nowy model przechodzi weryfikację pochodzenia i hash, skan formatu, test obciążenia, benchmark roli, test wycieku danych, prompt injection, structured output i zachowanie przy anulowaniu. Wynik benchmarku może utworzyć rekomendację rejestracyjną. Aktywacja do profilu produkcyjnego jest osobną decyzją. Model nie może dowieść własnej poprawności własną odpowiedzią.

Błędy, ryzyka i awaria

Ryzyka obejmują degradację jakości po kwantyzacji, zmianę zachowania przy nowym template, błędny tokenizer, przepełnienie VRAM, prompt injection, halucynacje źródeł i zależność od API. Registry wiąże wyniki z dokładnym artefaktem modelu, konfiguracją i sprzętem. Canary wykonuje cień bez skutków. Po wzroście błędów wersja może zostać automatycznie oznaczona jako degraded i wyłączona z routingu, ale reaktywacja wymaga kontrolowanej decyzji.

Przy awarii wszystkich modeli Core zachowuje status jobs i umożliwia operacje deterministyczne oraz odczyt. Zadania wymagające AI przechodzą do kolejki lub zwracają jawny błąd no_eligible_provider. System nie wysyła poufnych danych na zewnątrz „awaryjnie”.