Premiera Thinking Machines Inkling 2 Small rzuca wyzwanie Muse Spark Open
Thinking Machines zaprezentowało Inkling 2 Small 5 listopada, łącząc 594 miliardy parametrów ogółem z 17 miliardami aktywnych parametrów i porównaniami z Muse Spark Open. Thinking Machines Inkling 2 Small trafia na rynek z przyciągającą uwagę deklaracją dotyczącą treningu, jednak rozróżnienie między jedną fazą treningu a pełnym procesem rozwoju ma znaczenie.
Firma podaje 68 godzin dla wstępnego pretreningu, etapu, na którym model uczy się wzorców z szerokich zbiorów danych. Liczba ta nie opisuje całego harmonogramu treningu. Nastąpiły po niej dodatkowe etapy szkolenia, dlatego stwierdzenie „wytrenowano w 68 godzin” jest niepełnym opisem premiery.
Porównanie konkurencyjne również wymaga precyzyjnej nazwy. Muse Spark Open pojawia się w tabelach benchmarków firmy, podczas gdy inne warianty Muse wymieniono osobno. Istotne pytanie brzmi: który model osiągnął lepszy wynik w której ocenie, w jakich warunkach i z jakim dostępem dla deweloperów.
Thinking Machines Inkling 2 Small debiutuje w modelu dostępu hostowanego
Premiera daje deweloperom model do oceny, podczas gdy wagi do pobrania pozostają osobnym, obiecanym kamieniem milowym.
Thinking Machines początkowo udostępniło model poprzez Tinker, swoją platformę do uruchamiania i dostosowywania modeli. Firma poinformowała, że wagi do pobrania, czyli wartości liczbowe definiujące wytrenowany model, pojawią się po zewnętrznych testach bezpieczeństwa. Ogłoszonym terminem był następny tydzień.
To rozróżnienie oddziela natychmiastowy dostęp do produktu od przyszłej elastyczności wdrożeniowej. Deweloper może oceniać model hostowany, nie posiadając plików potrzebnych do jego niezależnego uruchamiania. Oba rozwiązania wspierają eksperymentowanie, ale odpowiadają na różne pytania zakupowe i inżynieryjne.
Dostęp hostowany pozwala zespołom rozpocząć od zachowania aplikacji. Mogą analizować odpowiedzi, porównywać wyniki i sprawdzać, czy model pasuje do istniejącego procesu pracy. Niezależne wdrożenie rodzi dodatkowe pytania dotyczące infrastruktury, utrzymania, mechanizmów bezpieczeństwa i odpowiedzialności operacyjnej.
Właściwości modelu wskazują wejścia tekstowe i obrazowe oraz wyjścia tekstowe. Opisują architekturę mixture-of-experts, która kieruje każdy segment wejściowy do wybranych wyspecjalizowanych komponentów. To sprawia, że rozróżnienie między parametrami całkowitymi a aktywnymi jest kluczowe dla zrozumienia pozycjonowania modelu.
Parametry to wyuczone wartości liczbowe kształtujące zachowanie modelu. Parametry całkowite opisują szerszy model, natomiast parametry aktywne — część wykorzystywaną podczas określonego kroku przetwarzania. Żadna z tych wartości sama w sobie nie przesądza o jakości zastosowania.
Słowo „Small” wymaga więc kontekstu. Jest oznaczeniem produktu w rodzinie modeli, a nie dowodem, że cały model jest lekki. Kupujący powinni unikać przekładania tej nazwy na założenia dotyczące wymagań wdrożeniowych.
Model może wykorzystywać ograniczoną część parametrów podczas obliczeń, zachowując jednocześnie znacznie większy ich zbiór ogółem. Efektywność przetwarzania i wymagania dotyczące pamięci masowej są powiązane, lecz nie są wymiennymi miarami.
Dla twórców aplikacji różnica ta wpływa na znaczenie dostępności. Dostęp przez usługę nie oznacza, że organizacja może uruchomić ten sam model w swojej istniejącej infrastrukturze. Przyszłe udostępnienie wag stworzyłoby kolejną ścieżkę oceny.
Czas ma również znaczenie w porównaniach z uznanymi alternatywami. Model dostępny przez platformę hostowaną natychmiast konkuruje o uwagę deweloperów. Model do pobrania konkuruje o organizacje poszukujące większej kontroli nad działaniem i dostosowywaniem.
Thinking Machines Inkling 2 Small przy premierze należy do pierwszej kategorii, z zapowiedzianym zamiarem wejścia do drugiej. Relacje powinny zachować tę sekwencję, zamiast opisywać oczekiwaną premierę jako dokonaną.
Praktyczną zmianą jest nowy kandydat do oceny. Szersze twierdzenie strategiczne zależy od tego, czy dostęp rozszerzy się zgodnie z obietnicą i czy zewnętrzni użytkownicy odtworzą użyteczne wyniki. Są to obserwowalne wydarzenia, a nie wnioski wynikające z nazwy produktu.
Liczba 68 godzin obejmuje etap, a nie ukończony model
Krótki wstępny trening nie mierzy całego wysiłku potrzebnego do stworzenia wdrożonego asystenta.
Według opublikowanego przez firmę podziału treningu początkowa faza przetworzyła 8,4 biliona tokenów w 68 godzin. Tokeny to jednostki tekstu lub innych danych wejściowych przetwarzane przez model. Kolejna faza wykorzystała następne 3,8 biliona tokenów.
Liczby te wyjaśniają, dlaczego nagłówek łączący około 12 bilionów tokenów z 68 godzinami wymaga zastrzeżenia. Ilości danych pochodzą z odrębnych etapów. Przypisanie ich łącznej skali czasowi trwania początkowego etapu sugerowałoby coś, czego ujawniony harmonogram nie potwierdza.
Ogłoszenie opisuje również dalszą adaptację i uczenie ze wzmocnieniem, proces zmieniający zachowanie modelu na podstawie informacji zwrotnych o wykonywanych zadaniach. Główny cykl uczenia ze wzmocnieniem trwał dziewięć dni. To samo w sobie uniemożliwia uznanie czasu wstępnego pretreningu za pełną oś czasu treningu.
To kwestia rozliczenia o konsekwencjach konkurencyjnych. Szybkość treningu może oznaczać czas trwania, efektywność obliczeniową, przepustowość inżynieryjną lub czas potrzebny do osiągnięcia docelowej zdolności. Każda interpretacja wymaga innych dowodów.
Czas trwania mierzy, jak długo cykl trwa według zegara. Nie ujawnia pełnych zasobów zaangażowanych w ten cykl. Krótszy harmonogram może wynikać z szybszego sprzętu, większej równoległości, lepszego oprogramowania, innego obciążenia roboczego lub kombinacji tych czynników.
Efektywność stawia inne pytanie: jak wiele użytecznej wydajności modelu uzyskano z zużytych zasobów? Odpowiedź wymaga zdefiniowanego porównania. Podobne rozmiary modeli nie oznaczają automatycznie podobnych danych treningowych, konfiguracji sprzętowych ani celów wydajnościowych.
Tempo rozwoju jest jeszcze szerszym pojęciem. Obejmuje przygotowanie danych, walidację infrastruktury, testowanie punktów kontrolnych, analizowanie awarii oraz decyzję, czy wydanie jest gotowe. Opublikowany czas treningu rzadko obejmuje wszystkie te działania.
Deklaracja 68 godzin pozostaje warta odnotowania, gdy jest opisana dokładnie. Przedstawia konkretne stwierdzenie dotyczące jednego etapu procesu firmy. Staje się myląca, gdy jest używana jako skrót dla wszystkiego, co było potrzebne do zbudowania wydanego modelu.
Dla konkurentów wniosek jest warunkowy. Jeśli podejście przyniesie powtarzalne wyniki w kolejnych cyklach, będzie wspierać silniejszy argument dotyczący procesu treningowego firmy. Jeden ujawniony czas trwania nie może potwierdzić tej powtarzalności.
Dla nabywców korporacyjnych związek jest jeszcze bardziej pośredni. Szybszy trening nie tworzy automatycznie lepszego asystenta do przeglądu dokumentów, utrzymania oprogramowania czy badań wewnętrznych. Te rezultaty wymagają dowodów specyficznych dla zastosowania.
Użyteczne porównanie utrzymywałoby stałe zadanie docelowe i warunki oceny. Następnie analizowałoby jakość wykonania, zużycie zasobów, czas odpowiedzi i zachowanie w przypadku błędów. Bez takiej struktury nagłówek o treningu może stać się substytutem pomiaru produktu.
To rozróżnienie chroni również czytelników przed atrakcyjnym, lecz niepopartym wnioskiem. Ogłoszenie nie potwierdza, że jakakolwiek organizacja może odtworzyć wynik w tym samym czasie. Dostęp do infrastruktury i zgromadzona wiedza inżynieryjna nadal są częścią obrazu.
Thinking Machines ujawniło godny uwagi czas trwania etapu treningowego. Silniejsze twierdzenie, że pełny model powstał w tym czasie, nie wynika z tych danych. Rozdzielenie tych stwierdzeń czyni analizę konkurencyjną bardziej informacyjną.
Muse Spark Open to konkretny rywal, a nie uniwersalny punkt odniesienia
Przewaga nad Muse Spark Open w wybranych ocenach nie dowodzi wyższości nad każdym modelem Muse ani każdym konkurencyjnym systemem.
Nazewnictwo ma znaczenie, ponieważ porównania benchmarków zależą od dokładnej tożsamości modelu. Różne wydania mogą mieć odmienne możliwości, ustawienia operacyjne i zasady wdrażania. Pominięcie doprecyzowania w nazwie konkurenta może rozszerzyć twierdzenie poza zakres dowodów.
Opublikowane przez firmę porównania pokazują, że Inkling wyprzedza Muse Spark Open w kilku nazwanych ocenach. Pokazują również lepsze wyniki innych konkurentów w niektórych zadaniach. Powstały obraz jest konkurencyjny i nierówny, a nie stanowi zdecydowanego zwycięstwa.
Niezależną perspektywę oferują rankingi inteligencji modeli. Artificial Analysis podaje wynik 31 i uzależnia korzystne pozycjonowanie w kategorii otwartych wag od planowanego udostępnienia wag.
Warunek ten ma znaczenie. Ranking może opisywać zmierzone możliwości modelu, podczas gdy etykieta wdrożeniowa opisuje sposób, w jaki ludzie mogą go uzyskać. Żaden z tych aspektów nie powinien po cichu zastępować drugiego.
Nagłówkowe porównanie z Muse Spark Open najlepiej rozumieć zatem jako ukierunkowane twierdzenie konkurencyjne. Wskazuje punkt odniesienia dla wydania. Nie eliminuje potrzeby zbadania zestawu zadań stojących za porównaniem.
Benchmark to ustrukturyzowany zestaw testów wykorzystywany do pomiaru określonych zdolności. Jego użyteczność zależy od tego, na ile testy przypominają pracę, którą czytelnik chce wykonać. Model może wyróżniać się w jednym zbiorze, a mieć trudności w innym.
W programowaniu pozytywny wynik może mierzyć, czy proponowana zmiana przechodzi testy. Niekoniecznie odzwierciedla to łatwość utrzymania, przejrzystość lub zgodność z konwencjami zespołu. Te kwestie mają znaczenie, gdy wygenerowane zmiany trafiają do rzeczywistego repozytorium.
W badaniach płynna odpowiedź może nadal pomijać dowody zmieniające wniosek. Użyteczna ocena musi odróżniać czytelną prozę od uzasadnionego rozumowania. To samo rozróżnienie dotyczy streszczeń, analiz finansowych i syntezy dokumentów.
W zastosowaniach wizualnych atrakcyjny wynik i poprawność funkcjonalna to odrębne wymiary. Strona może wyglądać przekonująco, a jednocześnie nie spełniać wymogu interakcji. Porównanie modeli powinno jasno wskazywać, który wymiar nagradza ocena.
Te rozróżnienia nie unieważniają wyników benchmarków. Definiują granice twierdzeń, które wyniki te wspierają. Czytelnicy zyskują więcej dzięki wąskiemu, powtarzalnemu ustaleniu niż szerokiemu twierdzeniu bez porównywalnych dowodów.
Presja na Muse Spark Open jest w konsekwencji konkretna. Thinking Machines przedstawiło kolejnego kandydata dla deweloperów porównujących modele w zadaniach związanych z programowaniem i wiedzą. Premiera tworzy powód, by ponownie ocenić obecne wybory.
Taka ponowna ocena nie musi wskazać jednego zwycięzcy w całej organizacji. Zespół może preferować jeden model do analizy dokumentów, a inny do procesu programistycznego. Taka decyzja odzwierciedla wymagania zadania, a nie niekonsekwencję.
Najbardziej uzasadnione odczytanie Thinking Machines Inkling 2 Small jest takie, że wywiera wiarygodną presję konkurencyjną. To, czy wyprze Muse Spark Open, zależy od obciążenia roboczego, warunków oceny i wymagań operacyjnych.
Szeroki nagłówek „pokonuje Muse Spark” ukrywa te zmienne. Precyzyjne porównanie je ujawnia, dając czytelnikom jaśniejsze zrozumienie zarówno zgłaszanych zysków, jak i ich ograniczeń.
Niezależne wyniki wskazują na wyspecjalizowane mocne strony
Zewnętrzne oceny przemawiają za tym, by traktować model poważnie, ale zarazem pokazują, dlaczego pojedynczy wynik ogólny nie wystarcza.
Niezależne wyniki benchmarków Vals AI przyznają Inkling 2 Small 56,08% w ich indeksie ogólnym. Ta sama strona podaje 67,54% w Finance Agent v2.1 oraz 12,63% w Terminal-Bench 4.0.
Wyniki te pochodzą z różnych ewaluacji i nie należy ich porównywać tak, jak gdyby ich wartości procentowe dzieliły wspólną skalę trudności. Ich wartość polega na pokazaniu wydajności w odrębnych zbiorach zadań. Uzasadniają one bardziej zróżnicowaną ocenę niż ogólne stwierdzenie o jakości modelu.
Vals plasuje model na czwartym miejscu spośród 37 ocenianych systemów w Finance Agent v2.1. Jego pozycja w benchmarku terminalowym jest wyraźnie słabsza. Użyteczny wniosek jest taki, że obiecujący wynik w jednym obszarze nie niweluje słabszych dowodów w innym.
Dla zespołu finansowego tworzy to konkretny powód, by zbadać przepływy pracy związane z dokumentami i analizą. Nie uzasadnia to jednak przekazywania istotnych decyzji bez kontroli. Wynik benchmarku wskazuje okazję do testowania, a nie przyznaje uprawnień do podejmowania decyzji biznesowych.
Rozważmy przykładowy przepływ pracy analityka obejmujący raporty, transkrypcje rozmów o wynikach oraz wewnętrzne memorandum inwestycyjne. Model musi łączyć stwierdzenia z różnych dokumentów, zachowując daty, jednostki i atrybucję. Pozornie spójna narracja może mimo to zawierać istotny błąd.
Znacząca ewaluacja analizowałaby fragmenty źródłowe wspierające każdy wniosek. Sprawdzałaby, czy model odróżnia zgłoszone wyniki od prognoz kierownictwa. Weryfikowałaby także, czy sprzeczne dowody przetrwają proces podsumowywania.
Ten przykład jest scenariuszem ewaluacyjnym, a nie udokumentowanym wdrożeniem u klienta. Pokazuje, jak zgłoszony obszar siły może stać się praktycznym pytaniem testowym. Takie przełożenie jest niezbędne, zanim zainteresowanie benchmarkiem stanie się decyzją o wdrożeniu.
Dla programistów kontrastujący scenariusz obejmuje utrzymywanie repozytorium za pomocą narzędzi terminalowych. Model musi interpretować błędy, wybierać polecenia, sprawdzać zmiany i rozpoznawać, kiedy postęp utknął. Sukces zależy od całej sekwencji.
Asystent korzystający z narzędzi może wykonywać rozsądne pojedyncze kroki, a mimo to nie ukończyć zadania. Może także zakończyć zadanie poprzez działania, na które zespół nie udzieliłby zgody. Dlatego jakość ukończenia i akceptowalne zachowanie wymagają odrębnej oceny.
Nierówne wyniki zewnętrzne czynią to rozróżnienie bardziej istotnym. Sugerują, że zespoły powinny oprzeć się pokusie oceniania wydania wyłącznie przez pryzmat jego najmocniejszej demonstracji. Testowanie powinno obejmować zadania, które najprawdopodobniej ujawnią słabości.
Pracownicy wiedzy napotykają podobną kwestię, porównując ogólną inteligencję modelu z osobistą użytecznością. Wydajność asystenta zależy częściowo od dostępnych mu dowodów. Zdolny model nie może niezawodnie podsumowywać dokumentów, których nigdy nie otrzymał.
Dlatego łączenie wiedzy należy do odrębnej kategorii ewaluacji niż wybór modelu. Zgromadzenie istotnych informacji i poprawne rozumowanie na ich podstawie to powiązane obowiązki. Żadne nie zastępuje drugiego.
Organizacja analizująca to wydanie powinna zachować to rozdzielenie w swoich zapisach ewaluacyjnych. Zdolności modelu, dostęp do informacji, projekt przepływu pracy i kontrola człowieka wpływają na końcowy rezultat. Zmiana jednego komponentu nie wyjaśnia wszystkiego.
Najmocniejsza interpretacja biznesowa jest selektywna. Inkling 2 Small zasługuje na uwagę tam, gdzie niezależne wyniki są zgodne z zadaniami zespołu. Wymaga dodatkowej analizy tam, gdzie dostępne dowody wskazują na słabszą wydajność.
Jest to użyteczniejsza forma presji konkurencyjnej niż twierdzenie o uniwersalnym rankingu. Zachęca kupujących do pytania, która praca się poprawia, jakie awarie pozostają oraz czy poprawa utrzymuje się w zwykłych warunkach operacyjnych.
Etykiety dostępu i warunki ewaluacji pozostają istotnymi lukami
Dowody potwierdzają premierę i mierzalne możliwości, lecz niektóre opisy wymagają uzgodnienia, zanim kupujący będą mogli na nich polegać.
Jedna widoczna rozbieżność dotyczy dostępu. Vals oznacza model jako open-weight, podczas gdy komunikat dewelopera o premierze opisuje początkowo zamknięte wagi i planowane późniejsze wydanie. Zapowiedziana przez dewelopera dostępność powinna decydować o opisach tego, co użytkownicy mogą uzyskać w chwili premiery.
Ilustruje to szerszy problem raportowania. Serwis porównawczy może sklasyfikować model według planowanej ścieżki wydania, zanim wszystkie materiały pomocnicze staną się publicznie dostępne. Czytelnicy muszą odróżniać klasyfikację od zakończonej dystrybucji.
Rozbieżność nie dowodzi, że którakolwiek ze stron błędnie przedstawiła wydajność benchmarkową. Dostępność i wydajność to odrębne twierdzenia. Oznacza jednak, że kupujący powinien zweryfikować aktualne zasady dostępu przed podjęciem zobowiązania infrastrukturalnego.
Kolejne pytanie dotyczy warunków ewaluacji. Wynik modelu może zależeć od czasu i nakładu obliczeniowego dozwolonego dla zadania. Porównania stają się trudniejsze do interpretacji, gdy te limity się różnią.
Asystent, który ma więcej okazji do poprawienia odpowiedzi, może osiągnąć lepszy rezultat. Ta poprawa może być użyteczna, ale dodatkowa praca wpływa na responsywność i zużycie zasobów. Wynik bez kontekstu operacyjnego dostarcza niepełnego sygnału zakupowego.
To samo dotyczy narzędzi. Warstwa agenta, czyli oprogramowanie dostarczające narzędzia i zarządzające sekwencją pracy modelu, może wpływać na wyniki. Różne warstwy mogą udostępniać różne informacje, egzekwować inne ograniczenia i inaczej obsługiwać awarie.
W konsekwencji zgłoszony wynik modelu jest również wynikiem konfiguracji ewaluacyjnej. Odtworzenie wymaga wystarczającej liczby szczegółów, aby zrekonstruować tę konfigurację. Bez nich zespoły zewnętrzne mogą zweryfikować jedynie część twierdzenia.
Istnieje również różnica między średnią wydajnością a niezawodnym zachowaniem. Wynik zbiorczy może ukrywać awarie skoncentrowane w określonym typie zadań. Takie awarie mają znaczenie, gdy ten typ zadań stanowi główne obciążenie pracą kupującego.
Asystent dokumentowy może na przykład dobrze radzić sobie z prostym wydobywaniem informacji, a mieć trudności ze sprzecznymi źródłami. Wynik ogólny nie ujawniłby automatycznie kosztu tej słabości. Analiza na poziomie zadań pozostaje konieczna.
Ewaluacja bezpieczeństwa dodaje kolejny wymiar. Zaliczenie zadania i przestrzeganie granicy uprawnień to różne osiągnięcia. Kupujący oceniający autonomiczną pracę powinni zbadać oba aspekty przed rozszerzeniem dostępu do wrażliwych systemów.
Żadna z tych kwestii nie wymaga odrzucenia wydania. Określają one dowody potrzebne do przejścia od zainteresowania do wdrożenia. Premiera dostarczyła wystarczających informacji, by uzasadnić testowanie, pozostawiając jednocześnie praktyczne pytania do zewnętrznej oceny.
Sceptyczne stanowisko jest zatem precyzyjne. Thinking Machines Inkling 2 Small ma zgłoszone i niezależnie zmierzone możliwości warte zbadania. Jego szeroka użyteczność, elastyczność wdrożenia i zachowanie operacyjne wymagają dowodów wykraczających poza przychylny nagłówek.
Stanowisko to pozostawia również miejsce na wzmocnienie twierdzeń firmy. Publiczne materiały, odtwarzalne ewaluacje i szczegółowe raporty wdrożeniowe zmniejszyłyby niepewność. Właściwą odpowiedzią na niepełne dowody jest węższy wniosek, który może się zmienić.
Trzy wydarzenia wyjaśnią sytuację po premierze
Kolejny etap należy oceniać według udostępnionego dostępu, odtwarzalnych porównań i trwałych wyników zastosowań — w tej kolejności.
Pierwszym sygnałem jest obiecane wydanie wag. Pliki do pobrania i towarzysząca im licencja przekształciłyby zapowiedzianą opcję wdrożenia w dostępną. Wzmocniłoby to argumenty organizacji poszukujących kontroli wykraczającej poza dostęp hostowany.
Opóźnienie miałoby węższe konsekwencje. Odroczyłoby niezależne wdrożenie i niektóre formy zewnętrznego testowania. Samo w sobie nie unieważniłoby wyników uzyskanych przez model hostowany.
Czytelnicy powinni również odróżniać obecność plików od praktycznej funkcjonalności. Użyteczna dystrybucja obejmuje wystarczające informacje, aby wykwalifikowane zespoły rozumiały, jak artefakty współdziałają. Dostępność jest punktem wyjścia do wdrożenia, a nie jego zakończeniem.
Drugim sygnałem jest niezależne odtworzenie konkurencyjnych porównań. Najbardziej informacyjne wyniki wskazywałyby dokładne wersje modeli, ustawienia operacyjne, narzędzia i limity zadań. Taki poziom szczegółowości ułatwiłby ocenę porównania z Muse Spark Open.
Zgodne wyniki wzmocniłyby zgłoszoną pozycję konkurencyjną. Istotne różnice pomogłyby ustalić, które części pierwotnego porównania zależały od warunków ewaluacji. Każdy z tych rezultatów dostarczyłby informacji wykraczającej poza kolejne szerokie podsumowanie rankingu.
Odtworzenie powinno obejmować słabe obszary, a także mocne strony. Model zyskuje wiarygodność, gdy jego ograniczenia są przewidywalne i udokumentowane. Kupujący mogą łatwiej planować wokół znanej granicy niż niewyjaśnionego wzorca awarii.
Trzecim sygnałem jest trwała wydajność w rozpoznawalnych przepływach pracy aplikacji. Raporty publiczne powinny opisywać, jaką pracę próbował wykonać model, jak sprawdzano wyniki i gdzie nadal konieczna była interwencja człowieka. Udana demonstracja jest użyteczna, ale powtarzające się wyniki są bardziej informacyjne.
Dla zespołów programistycznych oznacza to analizę zaakceptowanych zmian i towarzyszącej im pracy przeglądowej. Dla analityków oznacza to śledzenie wniosków aż do dokumentów źródłowych. Dla pracowników wiedzy oznacza to mierzenie, czy odpowiedzi zachowują dowody potrzebne do podejmowania decyzji.
Te obserwacje wzmocniłyby narrację premiery, gdyby pokazały powtarzalne korzyści przy zwykłych ograniczeniach. Osłabiłyby szerokie twierdzenia, gdyby korzystna wydajność benchmarkowa nie przekładała się na niezawodną pracę.
Krótkoterminowa historia ma więc jasną sekwencję. Dostęp określa, kto może zbadać model. Odtworzenie testuje twierdzenia konkurencyjne, a dowody zastosowania ustalają, czy zmierzona zdolność ma znaczenie w praktyce.
Czytelnicy śledzący Thinking Machines Inkling 2 Small powinni rozdzielać te wydarzenia w swoich notatkach ewaluacyjnych. Zapisujcie faktycznie dostępny dostęp, dokładnie testowanego konkurenta oraz warunki stojące za każdym wynikiem. Porównajcie przepływ pracy, który rozumiecie, zanim przyjmiecie szerokie twierdzenie o wyższości modelu. Jeśli wasz zespół testuje to wydanie, zachowajcie zarówno udane wyniki, jak i awarie, w tym dowody użyte do ich oceny. Wróćcie do porównania po udostępnieniu wag do pobrania i pojawieniu się niezależnych wyników. Najbardziej użyteczne pytanie jest konkretne: czy ten model wykonuje waszą pracę bardziej niezawodnie w warunkach, które potraficie odtworzyć?
