Przejdź do treści

Skills

chimera-when-two-results-contradict-suspect-the-apparatus

Gdy dwa twoje własne pomiary rozchodzą się o margines, którego nie wytworzyłby żaden mechanizm, defekt tkwi w przyrządzie. Zaudytuj harness, zanim zbudujesz na nim teorię.

WzorzecPochodzenie: cleanStatus: activev0.1.0 · Apache-2.0

Nadane przez osobę, która przeczytała kartę, a nie deklarowane przez sam plik. Karta, którą agent destyluje podczas przebiegu z niezaufaną treścią, rodzi się skażona i czeka na recenzję, zanim kiedykolwiek zostanie pobrana.

Kiedy przychodzi na myśl

  • dwa przebiegi drastycznie się różnią
  • mniejszy przebieg wypadł lepiej
  • metryka ruszyła w niemożliwą stronę
  • tłumaczenie zaskakującego wyniku benchmarku

Wartość zwykle kryje się w Unikaj i Sprawdź. Rób to sekcja, którą pisze każdy.

Treść karty powyżej to tłumaczenie. Angielski oryginał jest tym, co importuje CLI, co agent czyta w czasie działania i czego dotyczy hasz poniżej.

Wyzwalacz

Dwa pomiary, które sam wyprodukowałeś, różnią się o wielkość, której nie potrafisz wyjaśnić: uruchomienie na ułamku danych wypada lepiej niż to duże; komponent pokazuje 0% na zadaniu, przy którym sąsiedni pomiar pokazuje, że robi to rutynowo; zmiana przesuwa liczbę w kierunku, który sama czyni niemożliwym.

Wyzwalaczem jest rozmiar luki, nie jej istnienie. Dwa uruchomienia różniące się w granicach swojego pasma szumu to kwestia próbkowania, a ta karta nie ma o tym nic do powiedzenia. Nie dotyczy też twojej liczby wobec czyjejś opublikowanej — inne dane, prompty, ziarna i wersje tłumaczą takie różnice cały dzień, a potraktowanie tego jako alarmu przyrządu skończy się audytem harnessu, z którym wszystko jest w porządku. Przypadek tutaj brzmi: obie strony sprzeczności są twoje i obie nie mogą być prawdziwe.

Rób

  1. Zapisz sprzeczność najpierw, jako dwie linie: dwie liczby oraz dokładne polecenia i commity, które je wyprodukowały. Przestań teoretyzować, dopóki tego nie ma na papierze — niezapisana sprzeczność zostaje w mniej więcej akapicie złagodzona do zagadki.
  2. Zdiffuj oba uruchomienia, zanim zaczniesz o nich rozumować: konfiguracja, commit, ścieżka kodu, hash pliku wejściowego, wersja scorera. Wybieraj diff, który da się przeczytać, ponad wyjaśnienie, które da się skonstruować.
  3. Przepuść znane odpowiedzi przez sam pomiar. Uruchom rozwiązania referencyjne/wzorcowe przez swój grader zanim zaufasz jakiemukolwiek wynikowi modelu. Jeśli odpowiedź znana jako poprawna jest oceniana jako porażka, defekt jest w graderze, a każda liczba, którą wyprodukował, jest nieważna — włącznie z tą, która ci się podobała.
  4. Dopiero gdy przyrząd przetrwa krok 3, wydawaj wysiłek na wyjaśnianie zjawiska.
  5. Jeśli winny był przyrząd, wycofaj liczby, zamiast je reinterpretować. Wynik ze zepsutego scorera nie jest zaszumionym oszacowaniem prawdy; jest z nią niezwiązany.

Unikaj

Budowanie kilku starannych hipotez wyjaśniających obie liczby, a potem rygorystyczne ich testowanie. To jest droga wersja tego błędu: rygor jest prawdziwy, wysiłek jest prawdziwy, a wszystko to jest mierzone na artefakcie. Jakość metody poniżej zepsutego przyrządu doprowadza cię tylko do złej odpowiedzi z lepszymi słupkami błędu.

Unikaj godzenia tego arytmetyką — uśredniania obu albo cichego zachowania tej, która pasuje do oczekiwań. Unikaj gradera zamkniętego świata, czyli konkretnie tego błędu, który ten kształt produkuje najczęściej:


# and the score then reads as "the model cannot do this at all"
CITIES = {"lisbon", "porto"}
ok = answer.lower() in CITIES

# yes — grade against a rule that the real world can satisfy
ok = geocode(answer) == geocode(expected)

I unikaj frazy "to musi być przypadek" jako punktu zatrzymania. To hipoteza o przyrządzie, więc jest testowalna — przetestuj ją albo porzuć.

Sprawdź

Jedno zdanie, na głos, z wielkością w środku: "X produkuje różnicę tej wielkości, ponieważ …". Jeśli nie potrafisz go dokończyć — "dziesięć razy mniej danych produkuje lepszy wynik, ponieważ …" — podejrzanym jest przyrząd, a krok 3 jest tym, dokąd idziesz dalej.

Potem to zero-jedynkowe: czy wzorcowe odpowiedzi przeszły grader? Każdy element wzorcowy, który grader oznacza jako błędny, jest sufitem tego, co pomiar mógł kiedykolwiek znaczyć, a ułamek takich, które zawodzą, jest pierwszą liczbą do zaraportowania.

Ryzyko

Czasem sprzeczność jest prawdziwa, a zaskakujący wynik jest odkryciem. Odruch obwiniania harnessu wyrzuca takie przypadki — i, co gorsza, jest to dokładnie ten ruch, który ma do dyspozycji każdy, kto chce, by niewygodny pomiar zniknął. Więc ogranicz go: sprawdzenie przyrządu to ustalona, krótka lista (zdiffuj uruchomienia, wzorce przez grader, potwierdź hashe wejść). Jeśli ta lista wraca czysta, uwierz w sprzeczność i idź badać zjawisko. Ta karta porządkuje pracę; nie wybiera odpowiedzi.

Drugi koszt jest rekurencyjny. Nowy kod napisany, by sprawdzić stary kod, to jeszcze jedna rzecz, która może być zła, a błędny skrypt audytowy wyprodukował właśnie trzecią liczbę. Wybieraj sprawdzenia korzystające z artefaktów, które już masz, i z wejść o znanych odpowiedziach, zamiast świeżego harnessu pisanego pod presją anomalii.

Jak użyć

Karta to dane. Sklonuj repozytorium i zaimportuj ją ścieżką — to, co przychodzi przez sieć, jest traktowane jako skażone i wstrzymywane do zatwierdzenia. Taki jest pożądany sposób działania i dlatego nie ma tu instalatora w jednej linijce.

git clone https://github.com/brcampidelli/chimera-agent.git
chimera skills-import chimera-agent/skills/chimera-when-two-results-contradict-suspect-the-apparatus/SKILL.md

Integralność

SHA-256 pliku w postaci opublikowanej. Importujący może sprawdzić, że otrzymał dokładnie to, co pokazała ta strona.

c33d19c446e5da887d8aee039d0e58690472bd2db3c6d8322497b6cebfbb62bf

Przeczytaj kartę w repozytorium