Model ekstrakcji Cloudflare Clairic jest przeznaczony do zadań, które nie wymagają generowanego tekstu
Cloudflare przedstawiło model ekstrakcji Cloudflare Clairic, podważając założenie, że oprogramowanie potrzebuje generowanego tekstu za każdym razem, gdy prosi AI o wartość. Zapowiedziana 19 października wersja zapoznawcza Workers AI jest ukierunkowana na ekstrakcję, obliczenia, szacowanie i prognozowanie. Cloudflare nazywa go modelem System One, czyli modelem zaprojektowanym do szybkich, ograniczonych odpowiedzi zamiast rozbudowanych generowanych odpowiedzi.
Naturalnym punktem odniesienia są modele językowe ogólnego przeznaczenia, których deweloperzy już używają do przekształcania dokumentów w ustrukturyzowane rekordy. Modele te mogą wydobywać informacje i wyjaśniać swoje odpowiedzi w ramach tej samej interakcji. Clairic oddziela zadanie wytwarzania wartości od zadania pisania, zmuszając deweloperów do wyboru, której zdolności rzeczywiście potrzebuje dany przepływ pracy.
To rozróżnienie wywiera większą presję na projektowanie aplikacji, niż zagraża jakiemukolwiek konkretnemu chatbotowi. Jev od TypeSafe stanowi użyteczny punkt odniesienia: to wyspecjalizowany model stworzony do podejmowania decyzji wewnątrz oprogramowania. Clairic rozwija wersję tego podejścia proponowaną przez Cloudflare w kierunku wartości, których deweloperzy nie mogą wcześniej wyliczyć. Pytanie brzmi, czy specjalizacja usprawnia cały przepływ pracy, gdy pojawiają się w nim weryfikacja, wyjątki i kontrola człowieka.
Model ekstrakcji Cloudflare Clairic wyprowadza wartości poza pętlę generowania tekstu
Wersja zapoznawcza modelu ekstrakcji Cloudflare udostępnia Clairic za pośrednictwem Workers AI jako @cf/cloudflare/clairic. Firma twierdzi, że zwraca on wartości typowane bez generowania tokenów. Wartości typowane są zgodne z zadeklarowanymi formatami, takimi jak liczby lub daty, dzięki czemu kod aplikacji otrzymuje przewidywalny rodzaj odpowiedzi.
Zmiana polega na innym kontrakcie wyjściowym między modelem a aplikacją.
Ten kontrakt ma znaczenie, ponieważ oprogramowanie zwykle potrzebuje czegoś bardziej konkretnego niż pomocnej odpowiedzi. Aplikacja do przetwarzania faktur potrzebuje identyfikatora dostawcy, terminu płatności lub kwoty. Wyjaśnienie w formie konwersacyjnej może towarzyszyć tym polom, ale nie może ich zastąpić. Każde pole musi trafić do właściwego miejsca, zanim aplikacja będzie mogła kontynuować pracę.
Rozważmy przykładowy proces obsługi zobowiązań. Przychodzi dokument, aplikacja identyfikuje odpowiednie pola, a recenzent rozstrzyga rozbieżności przed zatwierdzeniem. Jakość tekstu pośredniej odpowiedzi ma niewielkie znaczenie, jeśli końcowym miejscem docelowym jest baza danych. Liczy się to, czy prawidłowa informacja trafia do właściwego pola wraz z wystarczającymi dowodami do jej sprawdzenia.
Interfejs modelu zorganizowany wokół wartości czyni ten wymóg jawnym. Deweloperzy muszą określić, czego potrzebują, zamiast pozostawiać aplikacji odzyskanie tego z prozy. Zmienia to miejsce, w którym widoczna staje się niejednoznaczność. Źle zdefiniowane pole jest problemem projektu aplikacji, zanim stanie się problemem jakości modelu.
Na przykład „data płatności” może oznaczać termin płatności faktury, obiecaną datę przelewu albo szacowaną datę rozliczenia. Wszystkie mogą być prawidłowymi datami. Tylko właściciel aplikacji może ustalić, które znaczenie powinno znaleźć się w rekordzie. Przewidywalne formatowanie pomaga oprogramowaniu przyjąć odpowiedź, a jasne definicje pomagają mu zadać właściwe pytanie.
Dlatego ustrukturyzowana ekstrakcja Clairic zasługuje na uwagę wykraczającą poza nazwę swojej kategorii. Oferuje sposób traktowania żądanej informacji jako głównego interfejsu. Model staje się komponentem odpowiedzialnym za wypełnianie zdefiniowanych pól, a nie asystentem, od którego oczekuje się wyjaśniania wszystkiego.
Nie dowodzi to, że Clairic jest najlepszym komponentem dla każdego przepływu pracy z dokumentami. Istniejące systemy mogą już łączyć przetwarzanie dokumentów, modele językowe i zwykły kod. Premiera tworzy kolejny wybór architektoniczny. Jego wartość zależy od tego, czy upraszcza rzeczywistą aplikację bez ukrywania błędów w innych miejscach.
Dla kupujących praktyczną konsekwencją jest bardziej konkretne pytanie zakupowe. Zamiast pytać, który model jest ogólnie najinteligentniejszy, mogą pytać, który komponent najpewniej obsługuje zdefiniowane zadanie. To węższe pytanie łatwiej ocenić, pod warunkiem że zadanie i warunki jego niepowodzenia są jasne.
Aplikacje intensywnie wykorzystujące ekstrakcję stają przed bardziej konkretną decyzją zakupową
Zespoły najbardziej bezpośrednio dotknięte zmianą budują aplikacje, które wielokrotnie przekształcają nieuporządkowane informacje w rekordy. Ich wyzwanie obejmuje wybór modelu, ale także przygotowanie dokumentów, walidację, obsługę wyjątków i integrację. Wyspecjalizowany model zasługuje na swoje miejsce tylko wtedy, gdy usprawnia ten połączony proces.
Istotną jednostką wartości jest zaakceptowany rekord, wraz z pracą potrzebną, by mu zaufać.
Niedroga odpowiedź modelu nadal może prowadzić do kosztownego przepływu pracy. Recenzenci mogą poświęcać czas na wyjaśnianie niejednoznacznych pól, odnajdywanie dowodów źródłowych lub korygowanie niezgodnych rekordów. Z drugiej strony odpowiedź, która zajmuje więcej czasu, może być wartościowa, jeśli ogranicza późniejsze interwencje. Ocena samego wywołania modelu czyni te kompromisy niewidocznymi.
Wywiera to presję na zespoły wykorzystujące generowanie ogólnego przeznaczenia jako domyślnego pośrednika dla każdego zadania. Mają teraz powód, by odróżnić pisanie od przekazywania informacji. Jeśli aplikacja nigdy nie wyświetla wygenerowanej odpowiedzi, zespół powinien zbadać, jaki wkład generowanie wnosi do tego kroku.
Odpowiedź będzie zależeć od przypadku. Niektóre dokumenty zawierają proste pola o spójnych znaczeniach. Inne wymagają uzgadniania sprzecznych stwierdzeń, interpretowania wyjątków lub rozstrzygania, które źródło ma autorytet. Interfejs ekstrakcji może wyrażać pola docelowe bez automatycznego rozstrzygania każdej rozbieżności w źródle.
Ta różnica wpływa na sposób podziału pracy w organizacjach. Wyspecjalizowany komponent może obsługiwać rutynowe rekordy, podczas gdy szerszy model analizuje nietypowe przypadki. Alternatywnie model językowy może najpierw identyfikować istotny kontekst dokumentu, zanim inny komponent wypełni pola. Rozsądna granica wynika z zadania, a nie z preferencji wobec konkretnej kategorii modeli.
Nabywcy korporacyjni powinni również oddzielać wykazywalne zachowanie od obietnic architektonicznych. Czysty format odpowiedzi można zaobserwować w małym teście. Niezawodne działanie w zmieniających się układach dokumentów wymaga szerszych dowodów. Twierdzenia dotyczące oszczędności operacyjnych wymagają dowodów z otaczającego procesu, w tym wysiłku koniecznego do jego utrzymania.
Podobne rozróżnienie dotyczy pracowników wiedzy. Ustrukturyzowany rekord może ułatwić filtrowanie, porównywanie i ponowne wykorzystywanie informacji. Zwięzłe pole może jednak usuwać istotne zastrzeżenia. Termin projektu wyodrębniony z notatek ze spotkania może zależeć od nierozstrzygniętej decyzji wspomnianej w innym miejscu.
Dla zespołów budujących przeszukiwalną bazę wiedzy rodzi to użyteczne pytanie projektowe: które fakty powinny stać się polami, a które wymagają otaczającego kontekstu? Wyszukiwanie i ustrukturyzowana ekstrakcja służą pokrewnym celom, ale zachowują różne aspekty oryginalnego materiału.
Presja w najbliższym czasie spada więc na właścicieli aplikacji i integratorów. Muszą oni wyjaśnić, dlaczego każdy etap potrzebuje wybranego modelu. To konkretna decyzja zakupowa i inżynieryjna, jeszcze zanim pojawi się wystarczająco dużo niezależnych dowodów, by klasyfikować Clairic względem alternatyw w różnych branżach.
Clairic a modele językowe to pytanie o to, gdzie powinno znajdować się generowanie
Najmocniejsza wersja porównania Clairic z modelami językowymi uwzględnia to, co systemy ogólnego przeznaczenia już oferują. Dokumentacja Anthropic dotycząca ustrukturyzowanych wyników opisuje odpowiedzi ograniczone schematem, czyli odpowiedzi ograniczone do zadeklarowanej struktury danych. Takie funkcje już rozwiązują wiele problemów z formatowaniem i parsowaniem.
Argument konkurencyjny Clairic musi wykraczać poza zwracanie danych, które oprogramowanie potrafi sparsować.
Schemat, który definiuje dozwoloną strukturę i typy odpowiedzi, daje modelowi generatywnemu węższy cel wyjściowy. Sprawia to, że ustrukturyzowane generowanie staje się poważnym punktem porównania. Porównywanie wyspecjalizowanego ekstraktora wyłącznie z nieograniczonym żądaniem prozy pomijałoby ugruntowaną alternatywę.
Rozróżnienie architektoniczne pozostaje istotne. Cloudflare opisuje Clairic jako model zwracający wartości bez generowania tokenów. Modele ogólnego przeznaczenia generują odpowiedzi, oferując jednocześnie możliwości wykraczające poza wypełnianie pól. Porównanie powinno badać wkład każdego podejścia, gdy oba otrzymują jasno zdefiniowane zadanie.
Przepływ pracy z dokumentami pokazuje, dlaczego to ma znaczenie. Odczytanie identyfikatora zamówienia i przygotowanie odpowiedzi dla klienta to różne zadania. Pierwsze ma konkretny cel w źródle. Drugie wymaga sformułowań, tonu i oceny, jakich informacji potrzebuje klient.
Połączenie tych zadań w jednym wywołaniu może być wygodne. Ich rozdzielenie może ułatwić kontrolę każdego etapu. Żaden układ nie wygrywa automatycznie, ponieważ przekazanie danych wprowadza własne obowiązki. Aplikacja musi zachować właściwy kontekst i unikać traktowania pośredniej wartości jako niepodważalnej prawdy.
Premiera modeli System One TypeSafe stanowi wcześniejszy punkt odniesienia dla tego podziału. Założyciel Diogo Almeida przedstawił Jev jako model do podejmowania ustrukturyzowanych decyzji wewnątrz oprogramowania. Jego rola różni się od ekstrakcji wartości o otwartym zakresie, ale oba podejścia podkreślają wyniki, z których logika aplikacji może korzystać bezpośrednio.
Użytecznym rozwojem dla branży jest szerszy wybór komponentów. Aplikacja może przydzielać ekstrakcję pól, podejmowanie decyzji i pisanie różnym systemom. Daje to deweloperom większą kontrolę nad tym, gdzie wykorzystują możliwości modeli, jednocześnie zwiększając znaczenie jasnych interfejsów między etapami.
Istnieje również uzasadniony argument za utrzymaniem większej roli modelu ogólnego przeznaczenia. Przepływ pracy z częstymi wyjątkami może zyskać na jednoczesnym interpretowaniu dokumentu i wyjaśnianiu rozbieżności. Zbyt agresywne rozdzielenie tego procesu może zmusić aplikację do odtwarzania kontekstu, który szerszy model już posiadał.
Właściwe porównanie obejmuje więc złożoność integracji. Model działający dobrze w izolacji może wymagać dodatkowego routingu, przechowywania lub monitorowania po wdrożeniu. Szerszy model może być łatwiejszy do zintegrowania, wykonując jednocześnie niepotrzebną pracę przy rutynowych żądaniach. Są to konkurujące koszty operacyjne.
Clairic a modele językowe najlepiej traktować jako kwestię obciążenia roboczego. Zadanie determinuje, czy generowanie jest niezbędne, użyteczne czy uboczne. Takie ujęcie pozwala uniknąć fałszywej prognozy, że wyspecjalizowane modele wyeliminują systemy ogólnego przeznaczenia. Unika także założenia, że znane interfejsy czatowe należą do każdego zautomatyzowanego procesu.
Ustrukturyzowana ekstrakcja Clairic sprawia, że dowody źródłowe stają się częścią interfejsu
Referencja modelu Clairic dokumentuje wejścia tekstowe i obrazowe, informacje o pewności oraz definicje pól z typami. Wyodrębniony tekst może zawierać przesunięcia znakowe, które wskazują jego położenie w danych wejściowych. Referencja opisuje również równoległe przebiegi, gdy definicje pól nie mieszczą się obok siebie wraz ze stanem.
Możliwość operacyjna polega na ułatwieniu sprawdzania i przekazywania zwróconej wartości dalej.
Dla osoby weryfikującej odpowiedź i jej lokalizacja w źródle służą różnym celom. Odpowiedź wskazuje, co wybrał system. Lokalizacja pomaga sprawdzić, dlaczego ten wybór może być właściwy. Zachowanie obu tych informacji może ułatwić rozstrzyganie sporów.
Wyobraźmy sobie wiadomość do wsparcia zawierającą pierwotny adres wysyłki i adres zastępczy. Oba są rzeczywistym tekstem źródłowym. Pole może zawierać wiernie skopiowany adres, a mimo to wskazywać niewłaściwy adres dla bieżącego zgłoszenia. Weryfikacja wymaga kontekstu dotyczącego intencji klienta i reguł aplikacji.
W tym miejscu ustrukturyzowane wyodrębnianie Clairic staje się czymś więcej niż dyskusją o formatowaniu. Użyteczny rekord powinien zawierać wystarczająco dużo informacji, by wesprzeć kolejne działanie. W zależności od aplikacji może to obejmować oryginalny dokument, definicję pola albo status weryfikacji. Odpowiedź modelu jest jedną częścią tego rekordu.
Deweloperzy muszą również rozróżniać kilka znaczeń słowa „pochodna”. Odczytanie podanej wartości różni się od obliczenia sumy. Przewidywanie przyszłego wyniku różni się od obu tych czynności. Wspólny interfejs może sprawiać, że takie wyniki wyglądają podobnie, choć ich podstawy dowodowe są odmienne.
Wyodrębniony termin można sprawdzić względem zdania w umowie. Obliczony termin zależy od prawidłowej daty początkowej i reguły. Szacowana data ukończenia zależy od założeń dotyczących przyszłych zachowań. Aplikacje powinny zachowywać te rozróżnienia podczas prezentowania wyników użytkownikom.
W przeciwnym razie wygoda wspólnego formatu danych może tworzyć nieuzasadnioną pewność. Wyświetlona data wygląda precyzyjnie niezależnie od tego, jak ją uzyskano. Osoby weryfikujące muszą wiedzieć, czy potwierdzają stwierdzenie ze źródła, sprawdzają obliczenie, czy oceniają prognozę.
Ma to konsekwencje dla projektowania produktów. Interfejs może pokazywać wyodrębnione fakty obok ich oryginalnego kontekstu, jednocześnie prezentując szacunki jako niepewne dane wejściowe do planowania. Takie różnice pomagają użytkownikom stosować właściwy rodzaj kontroli. Zapobiegają też cichemu trafieniu prognozy do systemu, który oczekuje udokumentowanego faktu.
Ta sama zasada obowiązuje, gdy informacje przemieszczają się między narzędziami. Gdy niepewna wartość trafia do dalszego rekordu bez swojego statusu, późniejsi użytkownicy mogą uznać ją za ustaloną. Zachowanie znaczenia pola jest równie ważne jak zachowanie jego typu danych.
Interfejs modelu dostarcza składników do tego procesu. Zespoły aplikacyjne nadal odpowiadają za decyzje dotyczące tego, jakie dowody zachować, jak pokazywać niepewność i kiedy wymagać weryfikacji. To te decyzje określą, czy specjalizacja poprawi doświadczenie użytkownika.
Prawidłowe pola nadal nie rozwiązują problemów arytmetyki, niejednoznaczności i prognoz
Analiza premiery Clairic firmy Cloudflare określa endpoint jako wczesny punkt kontrolny. Firma wskazuje słabości w wieloetapowej arytmetyce i agregacji, opisuje prognozowanie jako podstawowe oraz ostrzega, że przedziały niepewności mogą stać się zbyt wąskie dla nieznanych danych. Informuje też, że otwarte wagi są planowane, a nie już udostępnione.
Prawidłowy wynik określa swoją formę; poprawność wymaga odrębnych dowodów.
Ograniczenia modeli ekstrakcyjnych Cloudflare jasno przedstawiają to rozróżnienie. Dokumentacja stwierdza, że typy i ograniczenia nie gwarantują poprawnej odpowiedzi. Ostrzega również, że szacunki i prognozy mogą zwracać przewidywania, gdy dane wejściowe dostarczają niewiele informacji.
Te zastrzeżenia zawężają właściwą interpretację premiery. Wyspecjalizowany interfejs nie usuwa niepewności z podstawowego zadania. Daje aplikacji bardziej przewidywalny sposób odbierania wyniku, pozostawiając deweloperowi decyzję, co ten wynik uzasadnia.
Arytmetyka stanowi szczególnie jasny przykład. Jeśli aplikacja dysponuje wiarygodnymi wartościami i określoną formułą, zwykły kod zapewnia możliwe do skontrolowania obliczenie. Proszenie modelu o wywnioskowanie wyniku może być przydatne, gdy dane wejściowe są nieuporządkowane. Jednak po ich zidentyfikowaniu dokładne obliczenie zasługuje na odrębne traktowanie.
Trudniejsze pytanie często dotyczy tego, czy wybrano właściwe dane wejściowe. Dokument może zawierać kwotę pierwotną, kwotę zmienioną i uznanie. Idealna arytmetyka zastosowana do niewłaściwej kombinacji nadal daje błędną odpowiedź. Ocena musi badać interpretację i obliczenie niezależnie.
Prognozowanie wprowadza kolejną warstwę. Model może zwrócić starannie sformatowane przewidywanie, nie dysponując dowodami wystarczająco silnymi, by wesprzeć decyzję operacyjną. Nabywca powinien zapytać, jakie informacje zmieniają prognozę i jak błędy wpływają na zamierzone zastosowanie.
Na przykład poglądowa prognoza zatrudnienia może wspierać dyskusję planistyczną bez bezpośredniego przydzielania zmian. To samo przewidywanie staje się istotniejsze, gdy automatycznie zmienia harmonogramy pracowników. Wynik się nie zmienił, lecz wymagany przez aplikację poziom pewności już tak.
Wyniki pewności wymagają podobnej ostrożności. Kalibracja oznacza, że zgłaszana niepewność w rozsądny sposób odpowiada obserwowanym wynikom w porównywalnych przypadkach. Przekonujący wynik dla jednego zbioru danych nie potwierdza równoważnego zachowania po zmianie formatów dokumentów, języków lub warunków biznesowych.
Żadna niezależna ocena Clairic zweryfikowana na potrzeby tego artykułu nie potwierdza działania w tych warunkach. Dostępne oficjalne materiały wyjaśniają produkt i jego zamierzone działanie. Nie rozstrzygają, jak sprawdzi się on w pełnym potoku dokumentów nabywcy.
Pozostawia to miejsce zarówno na optymizm, jak i sceptycyzm, bez wymyślania kontrowersji. Wyspecjalizowane wyodrębnianie rozwiązuje rozpoznawalny problem programistyczny. Nierozstrzygnięte pozostaje pytanie, jak duża część tego problemu znika po wdrożeniu, a jak duża przenosi się do projektowania pól, oceny i weryfikacji.
Zespoły rozważające model ekstrakcyjny Cloudflare Clairic powinny zatem odróżniać czystsze interfejsy od potwierdzonej niezawodności. Oba aspekty są ważne, lecz wymagają innych dowodów. Demonstracja może od razu pokazać interfejs. Niezawodność operacyjna wyłania się w toku powtarzalnego użycia na reprezentatywnych, niezależnie sprawdzonych rekordach.
Obserwuj niezależne oceny, otwarte wagi i użycie produkcyjne
Najbardziej użyteczne kolejne sygnały dotyczą niezależnych testów, obiecanego wydania wag oraz dowodów z wdrożonych aplikacji. Każdy z nich odnosi się do innej luki między hostowanym podglądem a ugruntowanym wyborem infrastrukturalnym. Razem mogą pokazać, czy ta kategoria modeli zapewnia praktyczne korzyści.
Kolejne dowody powinny łączyć zachowanie modelu z pracą, którą aplikacje rzeczywiście muszą wykonać.
Na pierwszym miejscu są niezależne oceny. Użyteczne testy porównywałyby równoważne zadania w wyspecjalizowanych systemach ekstrakcji i systemach ustrukturyzowanego generowania. Powinny ujawniać definicje pól, warunki dokumentów i zasady punktacji. W przeciwnym razie porównanie może nagradzać różne interpretacje tego samego żądania.
Ocena powinna także odróżniać łatwe rekordy od niejednoznacznych. Łączna dokładność może ukryć, czy błędy skupiają się wokół istotnych pól. System, który zwykle prawidłowo odczytuje tytuły dokumentów, może nadal mieć trudności ze zmienionymi terminami lub sprzecznymi kwotami. Nabywcy potrzebują wyników odzwierciedlających ich rzeczywistą ekspozycję.
Dowody silnej wydajności na nieznanych dokumentach wzmocniłyby argument za szerszym wdrożeniem. Dowody, że zyski zależą od wąskich układów, przemawiałyby za bardziej ograniczoną rolą. Każdy z tych wyników pomógłby deweloperom wybrać odpowiednią granicę zastosowania modelu.
Kolejnym sygnałem jest obiecane wydanie otwartych wag. Otwarte wagi to parametry modelu dostępne do pobrania, które mogą umożliwić wdrożenie poza pierwotną usługą hostowaną, z zastrzeżeniem wymogów licencyjnych i technicznych. Ich wydanie stworzyłoby dodatkowe możliwości niezależnej kontroli i eksperymentowania.
Istotne szczegóły obejmowałyby licencję, wymagania sprzętowe, narzędzia wdrożeniowe oraz zgodność z wersją hostowaną. Sama dostępność nie potwierdzałaby, że samodzielne uruchamianie modelu jest praktyczne. Te otaczające szczegóły określają, które organizacje mogą z niego sensownie korzystać.
Wydanie z jasną dokumentacją zwiększyłoby dostępność tej kategorii. Przedłużone opóźnienie sprawiłoby, że ocena byłaby bardziej zależna od hostowanego endpointu. Żaden z tych wyników sam w sobie nie określałby jakości ekstrakcji, ale oba wpłynęłyby na to, kto może ją badać.
Użycie produkcyjne jest ostatnim sygnałem. Najmocniejsze relacje wyjaśniałyby, który przepływ pracy się zmienił, jak obsługiwano weryfikację i co działo się z wyjątkami. Obejmowałyby wysiłek wymagany do utrzymywania definicji pól w miarę zmiany napływających dokumentów.
Zgłaszane skrócenie czasu przetwarzania byłoby bardziej przekonujące wraz z dowodami dotyczącymi zaakceptowanych rekordów i wysiłku osób weryfikujących. Szybsza odpowiedź pośrednia ma mniejsze znaczenie, jeśli praca związana z korektą wzrasta gdzie indziej. Z kolei konsekwentne ograniczenie ręcznej interwencji wspierałoby praktyczną wartość specjalizacji.
Dla deweloperów następnym krokiem jest wskazanie ograniczonego przepływu pracy, w którym oczekiwana odpowiedź i konsekwencje błędów są jasne. Porównaj wyspecjalizowane wyodrębnianie z podejściem ustrukturyzowanego generowania już dostępnym dla aplikacji. Zachowaj reprezentatywne trudne dokumenty w procesie oceny i przechowuj wystarczający kontekst źródłowy, by badać rozbieżności. Nabywcy powinni prosić dostawców o połączenie twierdzeń dotyczących modelu z zaakceptowanymi rekordami, wysiłkiem weryfikacyjnym i obsługą wyjątków. Model ekstrakcyjny Cloudflare Clairic wyraźniej przedstawia wybór interfejsu wyjściowego, ale ten wybór nadal wymaga dowodów z otaczającego systemu. Zbadaj, gdzie Twoja aplikacja potrzebuje wartości, gdzie potrzebuje wyjaśnienia oraz czy te zadania powinny należeć do siebie. Który etap skorzystałby na węższym modelu bez utrudniania zaufania do końcowego wyniku?
