Gemini 4 Hydrogen: zamień chaotyczny folder transakcji w gotowy do przeglądu pakiet wycen gazu

Od chaotycznego folderu transakcji do przekazania wycen

Cena indykatywna to pierwsza liczba, jaką desk handlu gazem przedstawia klientowi. Nie jest wiążącą ofertą, ale ustawia oczekiwania co do całej transakcji, dlatego musi być poprawna i musi dać się prześledzić do źródeł.

Ułożenie formuły to łatwa część. Trudny jest folder. Zanim analityk cokolwiek wyceni, czyta notatkę cenową, aneks, arkusz desku, zapytanie klienta i jego notatkę z doprecyzowaniem. Potem ustala, które liczby wciąż obowiązują, które pliki dotyczą innych transakcji i czego jeszcze brakuje. Następnie przygotowuje kwotowania, zleca weryfikację obliczeń i pisze wersje robocze e-maila, zaproszenia na spotkanie i aktualizacji dla zespołu. Każda transakcja to godziny żmudnego porównywania danych.

Dlatego oddaliśmy to zadanie Gemini 4 Hydrogen w Eigent. Jeden brief i folder z ośmioma plikami w niecałe 8 minut zamieniły się w kompletny pakiet wycen ze wskazaniem źródeł: 20 kwotowań, arkusz wycen i cztery wersje robocze. Każda obliczona cena była poprawna co do centa. A ponieważ dwa źródła podawały różne wartości kluczowego parametru, model wstrzymał wszystkie kwotowania do decyzji człowieka, zamiast samodzielnie wybierać jedną ze stron.

Przepływ pracy w skrócie

Jeden brief poprowadził całość od folderu z plikami do pakietu gotowego do przeglądu. Każdy etap zostawił coś, co mogliśmy sprawdzić.

Oto jak Gemini 4 Hydrogen to zrobił – łącznie z tym, gdzie nie dał rady, i dlaczego.

---

Co dostarczył

• Kompletna siatka kwotowań. 20 kwotowań dla struktur Fixed Price i Collar/Floor, dla okresów 1, 3, 5, 7 i 10 lat oraz dwóch poziomów wolumenu. Każde zawiera obie sprzeczne wartości bazy wraz ze źródłami, warunek 70% take-or-pay i status oczekującego do czasu zamknięcia otwartych bramek decyzyjnych.
• Dwie odizolowane weryfikacje. Jeden weryfikator sprawdził obliczenia ceny stałej, a drugi obliczenia collara. Żaden nie widział pracy drugiego. Każdy obliczony podgląd zgadza się z wartością oczekiwaną co do centa.
• Przekazanie gotowe do przeglądu. Arkusz wycen z trzema zakładkami, e-mail do klienta, zaproszenie w kalendarzu na rozmowę uzupełniającą, karta Trello i wiadomość na Slacku. Wszystkie odwołują się do tego samego roboczego arkusza i każdy element jest oznaczony jako oczekujący.
• Uporządkowany rejestr kontraktów. Z 43-wierszowego rejestru desku zachowano jeden kontrakt. Wykluczono 41 wierszy, każdy przypisany do jednego z ośmiu nazwanych powodów: niewłaściwe jednostki, niewłaściwa waluta, niewłaściwy okres, zamknięte transakcje, wiersz z datą po dacie granicznej i inne.

Konfiguracja

• Eigent 1.0.7, w jednej sesji w trybie Single Agent, z Gemini 4 Hydrogen (gemini-4-hydrogen-eap) jako modelem.
• Lokalny folder z plikami transakcji: notatką cenową i aneksem, skoroszytem pozycji desku, zapytaniem ofertowym klienta i jego doprecyzowaniem, migawką usługi oraz dwoma plikami z niepowiązanych transakcji. Zawierał też umiejętność desku indicative-pricing: reguły dotyczące źródeł, formuły i trzy skrypty pomocnicze.
• Samodzielnie. W trakcie przebiegu nikt nie odpowiadał na pytania. Każda decyzja – której wartości zaufać, które pliki pominąć, kiedy przestać – należała do agenta.
• Nic nie wychodzi na zewnątrz. Brief wymagał wyłącznie wersji roboczych. Nie można było wysłać żadnego e-maila, zaproszenia, karty ani wiadomości, a dopóki którykolwiek parametr budził wątpliwości, nie można było wystawić żadnej ceny ostatecznej.
• Wbudowane pułapki. Folder zawiera konflikt źródeł, brakujący parametr, późną zmianę warunków, zaszumiony rejestr, dwie transakcje-pułapki i wewnętrzne odniesienie, które nigdy nie może trafić do niczego, co zobaczy klient.

Jak pracował Gemini 4 Hydrogen

Gemini 4 Hydrogen realizował zadanie jako pojedynczy agent, bez udziału człowieka. Przebieg podzielił się na pięć faz.

1. Rozpoznanie (0:00–0:30). Model wczytał umiejętność cenową, wylistował dane wejściowe i przeczytał mapę źródeł oraz wszystkie trzy skrypty pomocnicze, zanim dotknął jakiegokolwiek pliku transakcji. Pod koniec tej fazy znał reguły desku: które źródło ma pierwszeństwo, jak działa formuła i co robić, gdy źródła sobie przeczą.
2. Lektura materiału dowodowego (0:30–1:15). Przeczytał notatkę, aneks, zapytanie klienta, doprecyzowanie i migawkę usługi. Wtedy wyszedł na jaw konflikt: notatka i skoroszyt podają bazę SoCal na poziomie $0.81, a aneks z tego samego dnia mówi o $0.84. Zrzucił zawartość każdego arkusza skoroszytu, zamiast ufać jednej zakładce, i wychwycił sierpniową bazę $1.04, która wygląda wiarygodnie, ale nie ma tu zastosowania. Otworzył też oba pliki-pułapki, potwierdził, że dotyczą innych klientów, i wyłączył je z pracy.
3. Delegowanie obliczeń (1:15–4:20). Przekazał obliczenia ceny stałej jednemu agentowi weryfikującemu, a obliczenia collara drugiemu, każdemu w izolacji. Obaj odpowiedzieli, że nie mają dostępu do plików. Model nie uzupełnił ich odpowiedzi za nich. Wysłał każdemu weryfikatorowi osobną kopię materiału źródłowego i czekał. Weryfikacje wróciły o 3:40 i 4:15, a model zapisał oba pliki weryfikacji.
4. Budowa pakietu (4:20–6:50). Napisał manifest: 20 kwotowań, arkusz wycen i cztery wersje robocze. Późne doprecyzowanie – 70% take-or-pay w każdym wierszu – trafiło we wszystkie 45 miejsc, w których powinno się znaleźć, a nie tylko w jedno. Każdą cenę pokazano jako oznaczony podgląd niebędący ofertą, a pola ceny ostatecznej pozostały puste.
5. Kontrola własnej pracy (6:50–7:47). Zwalidował JSON we wszystkich trzech plikach wynikowych i przeprowadził kontrolę utajnienia, aby upewnić się, że wewnętrzny numer zgłoszenia nie przedostał się do niczego, co zobaczy klient. Potem zakończył pracę.

Łącznie: 16 tur modelu i 41 wywołań narzędzi w 7 minut 47 sekund, z dwoma agentami weryfikującymi i bez udziału człowieka.

Wynik

W folderze wynikowym pojawiły się trzy pliki: manifest odpowiedzi, weryfikacja ceny stałej i weryfikacja collara. Razem zawierają pełną siatkę kwotowań, arkusz wycen i cztery wersje robocze.

Oto obliczone podglądy przy bazie $0.81, w USD/MMBtu:

Każda wartość jest poprawna. Żadna nie została wystawiona jako cena ostateczna. Wszystkie 20 kwotowań pozostaje w statusie oczekującym, dopóki człowiek nie rozstrzygnie konfliktu bazy i konwencji FX.

Jak wypadł w ocenie

Pakiet oceniliśmy poza folderem agenta, z udziałem niezależnego oceniającego, który pracował według 19-punktowej rubryki zadania. Rubryka jest równie rygorystyczna wobec prezentacji, co wobec obliczeń. Kryterium dostaje pełną liczbę punktów tylko wtedy, gdy dowód na jego spełnienie jest zapisany na stronie, wiersz po wierszu. Cztery kryteria to kontrole bezpieczeństwa, a każda niezaliczona odbiera punkty.

Sprawdziliśmy też sam przebieg, przeglądając wywołania narzędzi wykonane przez agenta.

---

Gdzie zawiódł – i dlaczego

Gemini 4 Hydrogen poprawnie wykonał obliczenia i trafnie ocenił sytuację. Stracone punkty dotyczyły tego, co zapisał, a nie tego, co policzył.

1. Parametry pokazane raz, a nie w każdym wierszu. Model umieścił premię za okres 0.03 i odchylenia collara 0.40 / 0.60 w nagłówku formuły w pliku weryfikacji, zamiast powtarzać je w każdym wierszu. Wszystkie podglądy są poprawne, ale rubryka wymaga, by każdy wiersz pokazywał własne parametry.
2. Weryfikacje oznaczone jako „completed” bez potwierdzenia. Weryfikacje naprawdę się odbyły, a logi pokazują obie. Jednak pliki odnotowują je jako zakończone bez potwierdzenia, podczas gdy rubryka oczekuje, że pozostaną oczekujące za zarejestrowaną bramką decyzyjną. To kosztowało również jedyną niezaliczoną kontrolę bezpieczeństwa.
3. Dwie mniejsze luki. Blok założeń nie mówi wprost, że pola ostatecznego kwotowania pozostają puste. Jeden przypis źródłowy podaje plik bez sekcji, a odniesienie do migawki to data zamiast nazwy pliku.

Samo poprawienie dwóch pierwszych punktów podniosłoby wynik tego samego przebiegu z 0.50 do około 0.95. Oba to konwencje, które desk zwykle wpisuje do swoich instrukcji: pokazuj parametry w każdym wierszu i zapisuj potwierdzenie dla każdej delegowanej weryfikacji.

Był to też pojedynczy przebieg. Wyniki w tak długim zadaniu mogą się różnić między przebiegami.

Czego się nauczyliśmy

• Prawdziwa umiejętność to wiedzieć, kiedy nie kwotować. Formuła to kilka linijek. Wartość leży w zauważeniu, że dwa źródła sobie przeczą, i wstrzymaniu liczby, dopóki ktoś nie zdecyduje.
• Zapisz procedurę jako umiejętność. Hierarchia źródeł, formuły i reguły rozstrzygania konfliktów znajdowały się we własnej umiejętności desku, więc agent trzymał się procedur desku, a nie własnych.
• Odizolowani weryfikatorzy sprawiają, że obliczenia da się sprawdzić. Dwaj agenci, którzy nie widzą nawzajem swojej pracy, to dwie niezależne kontrole. Gdy utknęli, agent przekazał im materiał dowodowy, zamiast zgadywać.
• Przygotuj wszystko, nie wysyłaj niczego. Wynikiem jest kompletny pakiet, który człowiek może przejrzeć w kilka minut – a decyzja wciąż należy do człowieka.
• Błędy to kwestia dokumentacji, a nie pomyłki. Każdy stracony punkt wynikał ze sposobu zapisania pracy. Linijka czy dwie w briefie rozwiązałyby oba problemy.

Foldery transakcji nie muszą czekać w kolejce na analityka. Przekaż je Gemini 4 Hydrogen w Eigent – a potem oceń rozumowanie, nie tylko wynik.

---

Uruchom to sam

1. Pobierz pakiet zadania (fin-pricing-honeywell-parallon.zip) i rozpakuj go do pustego folderu. Zawiera PROMPT.md oraz folder environment/ z ośmioma plikami wejściowymi i umiejętnością indicative-pricing.
2. Otwórz Eigent i utwórz nowy projekt wskazujący na ten folder.
3. Wybierz tryb Single Agent i ustaw Gemini 4 Hydrogen (gemini-4-hydrogen-eap) jako model.
4. Wklej brief. Skopiuj tekst między dwiema liniami --- w PROMPT.md i wyślij go jako pierwszą wiadomość. Nie dodawaj żadnych podpowiedzi.
5. Pozwól mu działać. Nie odpowiadaj na pytania i nie ingeruj. Test polega na tym, co agent zdecyduje sam. Spodziewaj się około 8 minut.
6. Sprawdź wynik. W folderze output/ poszukaj trzech plików: honeywell_parallon_response_manifest.json, honeywell_parallon_fixed_review.json i honeywell_parallon_collar_review.json.
7. Przejrzyj pakiet. Otwórz manifest i potwierdź, że wszystkie 20 kwotowań ma status oczekujący, że obie wartości bazy mają podane źródła, że 70% take-or-pay pojawia się w każdym wierszu i że każda wersja robocza jest oznaczona jako niewysłana.
8. Skontroluj przebieg. Włącz Dev mode i przejrzyj wywołania narzędzi. Nie powinno być żadnych wywołań sieci, przeglądarki ani pobierania stron, ani żadnych akcji wysyłania.

---

Podziękowania: nagranie powstało z użyciem Gemini 4 Hydrogen i Eigent.