Co tworzę
SovereignFlow wydzieliłem jako osobny kierunek po doświadczeniach z LocalAI-RAG. Założenia analizy kodu głęboko wpływają na architekturę systemu, więc samo usunięcie pojęć „C#” i „repozytorium” nie daje uniwersalnego silnika. Dlatego buduję osobny model DocumentChunk, kontrakty ingestii i retrieval oraz mechanizmy uruchamiania pipeline’ów niezależne od tematu dokumentów. Repozytorium zawiera kod infrastruktury, testy, migracje i dokumentację.
Neutralny rdzeń i rozwiązania domenowe
Silnik odpowiada za przebieg, wyszukiwanie, audyt, polityki i API. Osobne aplikacje mają własne importery, reguły biznesowe, schematy domenowe oraz prompty. Dzięki temu aplikacja taryfowa nie powinna wymuszać na rdzeniu wiedzy o taryfach, tak samo jak analiza kodu nie powinna definiować wszystkich pojęć RAG.
Ingestion i spójność danych
Import zapisuje wersję źródła, fragmenty, identyfikator idempotencji i zadanie indeksowania w PostgreSQL. Wektory trafiają do Weaviate, a wskaźnik aktualnej wersji zostaje zmieniony dopiero po poprawnym indeksowaniu. W dokumentacji jest też osobne narzędzie do dużych zestawów JSONL z wznawianiem pracy i kontrolą spójności.
Audyt i zasady bezpieczeństwa
Wykonania pipeline’u i kroków zapisuję w audycie PostgreSQL. Autoryzacja wiąże zweryfikowane uprawnienia z konkretnymi możliwościami i pipeline’ami, zamiast przyjmować ich nazwy od klienta. Wybór endpointu modelu jest jawny; brak cichego przełączenia na innego dostawcę po błędzie. To wybory architektoniczne, które weryfikuję przez kontrakty i testy.
Zakres projektu
- DocumentChunk i neutralne metadane domeny/tenantów
- YAML z wersjonowaniem zachowania akcji i walidacją grafu kroków
- PostgreSQL: audyt wykonania, migracje, trwałe zadania ingestion
- Weaviate: wyszukiwanie z ACL i klasyfikacją przed zbudowaniem kontekstu
- Jawne polityki autoryzacji oraz wybór lokalnego lub zewnętrznego LLM
- Graf relacji między fragmentami dokumentów i kontrolowana ekspansja