Pokaz techniczny · Jak AI odczytuje czas
Pełny opis deterministycznych wskazówek dat, routowanej ekstrakcji LLM, terminów prawnych, aktualizacji SSE na żywo oraz eksportu DOCX/ICS.
Architektura
Oś czasu najpierw zbiera deterministyczne wskazówki dat, wysyła dokument przez jeden routowany przepływ strukturalnej ekstrakcji, a następnie PHP filtruje, ocenia, oblicza terminy i przygotowuje eksport.
Przed jakimkolwiek wywołaniem modelu PHP skanuje pełne wejście w poszukiwaniu dat pasujących do 12+ norweskich formatów i w miarę możliwości normalizuje je do ISO 8601:
dd.mm.yyyy → YYYY-MM-DDZnormalizowane kotwice są dodawane do promptu ekstrakcji, aby ograniczyć wymyślone lub błędnie odczytane daty. To wskazówki, a nie osobny wynik AI.
Wybrana trasa czyta dokument wraz ze wskazówkami dat. Dla każdego odniesienia czasowego zwraca strukturalny obiekt JSON wydarzenia z polami terminów:
date — resolved ISO date, or verbatim string if unresolvabledate_type — absolute | relative | recurring | conditional | periodconfidence — high | medium | lowactor — attributed entity (from source text, not inferred)description — one-sentence event summarysource_excerpt — verbatim text fragment (max 200 chars)is_deadline / deadline_kind — jawne znaczniki terminów prawnych, gdy występująPrompt wyraźnie instruuje model, aby nie wymyślał dat ani uczestników, których nie ma w źródle. Dłuższe wejścia są dzielone po stronie serwera i składane z powrotem w tym samym schemacie.
PHP stosuje aktywne filtry i pochodną logikę terminów przed zwróceniem wyniku:
Post-processor buduje też deadlines[], listę what_remains_uncertain oraz rekomendację next_practical_step.
Rozpoznawanie dat
Norweskie dokumenty prawne używają wielu notacji dat. Oś czasu rozpoznaje je deterministycznie, zanim model zobaczy tekst, a następnie prosi model o rozwiązanie pozostałych odniesień kontekstowych.
| Format | Przykład | Uwagi |
|---|---|---|
dd.mm.yyyy |
30.07.2015 | Standardowa norweska liczba |
dd.mm.yy |
09.04.25 | Dwu-cyfrowy rok → zawsze 20YY |
d. månedsnavn yyyy |
3. mars 2024 | Napisany miesiąc w bokmål/nynorsk |
d. månedsnavn |
15. januar | Rok wnioskowany na podstawie skanowania bliskości |
yyyy-mm-dd |
2024-03-12 | ISO 8601 |
månedsnavn yyyy |
mars 2024 | Tylko miesiąc + rok |
yyyy |
2024 | Odniesienie tylko do roku |
| Season + year | høsten 2023 | Odniesienie sezonowe → Q3/Q4 |
| Diary-format line | 18.09.2025: Møte avholdt | Data + dwukropek → automatycznie oznaczona jako wydarzenie |
| Relative reference | tre uker etter vedtaket | Przywiązana do najbliższego rozwiązania wydarzenia |
| Recurring pattern | hver mandag | Klasyfikowana jako powtarzająca się |
| Period / range | fra mars til juni 2024 | Generuje start_date + end_date |
Schemat klasyfikacji
| date_type | Definicja | Przykład |
|---|---|---|
absolute |
Specyficzna, rozwiązywalna data kalendarzowa | 30.07.2015 → 2015-07-30 |
relative |
Data wyrażona w odniesieniu do innego wydarzenia | tre uker etter vedtaket |
recurring |
Wzór, który powtarza się według harmonogramu | each Monday, every 6 months |
conditional |
Data uzależniona od spełnienia warunku | if no response within 14 days |
period |
Zakres dat lub czas trwania z początkiem i końcem | fra mars til juni 2024 |
| pewność | Znaczenie | Wizualizacja w osi czasu |
|---|---|---|
high |
Data jest wyraźnie i jednoznacznie podana w tekście źródłowym | Zielona odznaka |
medium |
Data jest wnioskowana, przybliżona lub podana z niewielką niejednoznacznością | Bursztynowa odznaka |
low |
Data jest sugerowana, niepodana lub wyciągnięta z zdegenerowanego/niejednoznacznego fragmentu | Szara odznaka |
| Zasada | Przykład |
|---|---|
| Nazwana jednostka w tym samym zdaniu | “Trude [saksbehandler] ringte 14. mars” → actor: Trude |
| Etykieta roli bez imienia | “Barnevernet fattet vedtak” → actor: Barnevernet |
| Brak wyraźnego przypisania w zdaniu | actor: [unattributed] |
| Domyślne na poziomie dokumentu | Jeśli brak aktora dla konkretnego zdarzenia, domyślnie przypisuje się nadawcę dokumentu/ciała wydającego |
Silniki
Szybki, Standard i Zaawansowany zwracają ten sam schemat JSON, więc post-processing obsługuje je tak samo. Wybór trasy wpływa na szybkość, jakość, koszt kredytów i raportowanie fallbacku.
| Trasa modelu | Model | Opóźnienie | Najlepszy dla |
|---|---|---|---|
| Szybki | nova-lite (własny GPU przez LiteLLM) |
~10-25 s | Szybkie szkice i krótsze dokumenty, gdy najważniejsza jest szybkość. |
| Standard ★ | Claude Haiku 4.5 (Amazon Bedrock EU; gpt-4o-mini tylko gdy Bedrock jest wyłączony) |
~20-45 s | Domyślna trasa dla większości dokumentów prawnych; równowaga szybkości, jakości i kosztu. |
| Zaawansowany | Claude Sonnet 4.6 (Amazon Bedrock EU) |
~45-90 s | Gęste lub złożone sprawy z wieloma uczestnikami, nakładającymi się wydarzeniami albo słabą jakością źródła. |
Aktualizacje na żywo i eksport
Oś czasu używa Server-Sent Events (SSE), aby przesyłać komunikaty stanu do przeglądarki podczas ekstrakcji: przygotowanie, ekstrakcja, parsowanie i końcowe składanie.
Po zakończeniu ekstrakcji możesz wyeksportować sformatowany .docx z oznaczonymi wydarzeniami i fragmentami źródeł albo pobrać plik kalendarza .ics dla datowanych wydarzeń i terminów.
Prywatność i bezpieczeństwo
Prywatność przez projekt
nova-lite przez LiteLLM; Standard i Zaawansowany używają Amazon Bedrock EU, gdy jest włączony, z istniejącym routowanym fallbackiem chmurowym, jeśli Bedrock jest wyłączony.Dostępne dla członków Do Better Norge z przejrzystym routingiem, szacowaniem kredytów i obsługą process-and-forget.