OpenAI Codex zyskał dostęp do internetu: pierwsze wrażenia

Co to w ogóle jest ten Codex?

Dobre pytanie, prawda? Chodzi o to, że do niedawna OpenAI miało model Codex, który był używany jako podstawa autouzupełniania w GitHub Copilot. Następnie OpenAI wypuściło konsolowego agenta do tworzenia oprogramowania, którego nazwali, żeby nikt nie pomylił, Codex. ¹ Wszyscy pośmiali się z umiejętności OpenAI do dobierania nazw ² i żyli dalej. Aż nadszedł pamiętny dzień, w którym na Twitterze pojawił się taki oto post od Sama Altmana:

Byłem zaintrygowany. Po pierwsze, nakręcaniem hajpu za pomocą frazy “low-key research preview” ³, a po drugie, właśnie tą nazwą. Jednak nie zawiodłem się:

Wraz z tym postem rodzina bytów o nazwie Codex powiększyła się o dwóch nowych przedstawicieli:

1. Wariant modelu o3, specjalnie dostosowany do programowania, o nazwie codex-1
2. Agent chmurowy, zdolny do autonomicznego wykonywania kilku różnych zadań na repozytorium w GitHubie ⁴.

I właśnie o tym ostatnim będzie dzisiaj mowa.

Jak to działa?

Sekwencja naszych działań, niezbędnych do korzystania z agenta, jest dość prosta:

Punkt 1. Wchodzimy na https://chatgpt.com/codex. Tam widzimy listę zadań, które agent wykonuje/wykonał, oraz okno do wprowadzania zadania, w którym możemy wybrać repozytorium, z którym chcemy pracować, oraz gałąź (branch). Są dwa przyciski – Ask, który analizuje kod przed automatycznym zaproponowaniem konkretnych podzadań, oraz Code, który będzie bezpośrednio modyfikował kod.

Punkt 2. Aby dodać nowe repozytorium, przechodzimy do menu Environments i tworzymy tam nowe środowisko. Tam możemy wskazać samo repo, określić ustawienia środowiska roboczego i wypróbować je w praktyce.

Punkt 3. Wracamy na główny ekran i wpisujemy nasze życzenie.

Punkt 4, najciekawszy. Środowisko uruchamia kontener oparty na Ubuntu, instaluje w nim niezbędne pakiety, stosuje niestandardowe ustawienia środowiska i klonuje repozytorium do środka. Następnie internet jest odłączany ⁵ (już nie zawsze, o tym właśnie jest ten post) i agent rozpoczyna swoją pracę. Robi to długo i starannie, ponieważ planer pochodzi z o3, i jest to dobry planer. Ten proces można obserwować w oknie Logs:

Punkt 5. Po kilku minutach pracy otrzymujemy diff, który możemy sprawdzić i albo utworzyć pull-request na GitHubie, albo skierować proces na właściwe tory i powtórzyć iterację.

Punkty 3-5 można uruchamiać równolegle i zajmować się swoimi sprawami, podczas gdy agent pracuje. Co więcej, diffy, które generuje, są bardzo kompaktowe i przyjemnie się je czyta, co zwiększa pewność co do poprawności wyniku.

Dostęp do internetu

Jeśli uważnie przyjrzeć się procesowi, można zauważyć pewne ograniczenie. Brak dostępu do internetu podczas wykonywania zadań psuje wiele procesów budowania i testowania, co ogranicza możliwości agenta. Prowadzi to zazwyczaj do poprawnych wyników z dopiskiem “Running tests: failed”. Dzieje się tak z różnych przyczyn, ale przede wszystkim dlatego, że często podczas budowania konieczne jest pobranie różnych bibliotek. Oczywiście, można to obejść na etapie konfiguracji środowiska, gdy dostęp jeszcze jest, ale proces ten nie zawsze jest trywialny.

Ograniczenie to było dość dotkliwe, dlatego niedawno OpenAI ogłosiło, że teraz można modelowi zostawić internet. Oczywiście, wpuszczanie modelu do internetu bez żadnych ograniczeń – niczym przysłowiowego lisa do kurnika – jest niebezpieczne, dlatego dano nam wybór trybów dostępu.

Po pierwsze, możemy zostawić wszystko tak, jak jest, i nie dawać dostępu do internetu. Po drugie, możemy dać dostęp, ale do ograniczonej liczby zasobów ⁶. Ponadto możemy pozwolić modelowi wykonywać tylko operacje odczytu. Najbardziej zdesperowanym i odważnym pozwala się dać agentowi pełny i nieograniczony dostęp i mieć nadzieję na najlepsze.

Bezpieczeństwo

Dlaczego mieć nadzieję? Ponieważ bezpośredni dostęp do niezweryfikowanych zasobów grozi całym szeregiem problemów, o czym OpenAI natrętnie ostrzega.

Przy czym w ostrzeżeniu wszystko się pomieszało (taki groch z kapustą) i na jednej liście wymieniono zarówno ataki, jak i ich konsekwencje:

• Prompt injection: Model pobiera stronę internetową, widzi tam tekst podobny do instrukcji i radośnie go wykonuje. Przy tym instrukcja może poprosić o…
• Exfiltration of code or secrets: …przesłanie zawartości repozytorium i sekretów na zewnętrzny zasób;
• Inclusion of malware or vulnerabilities: …lub użycie złośliwej biblioteki (malware) zamiast legalnej.
• Use content with license restriction: Model może jednak sam uznać, że kod znaleziony w repozytorium na licencji GPL to najlepsze, co można dodać do naszego repozytorium, co może prowadzić do pewnych problemów prawnych.

Dlatego zdecydowanie zaleca się ograniczanie dostępu modelu tylko do zweryfikowanych zasobów i tylko wtedy, gdy jest to konieczne.

Mały przykład i podsumowanie

Oczywiście dostęp do internetu otwiera masę ciekawych możliwości oprócz uproszczenia procesu budowania. Ja na przykład jako pierwsze poprosiłem model o sprawdzenie tej strony pod kątem możliwych problemów z SEO. Wynik można zobaczyć poniżej.

Podsumowując, mogę powiedzieć, że ogólnie narzędzie mi się podoba. Mały rozmiar diffów i możliwość uruchamiania kilku zadań równolegle pozwalają na dokonywanie małych refaktoryzacji i ulepszeń na zasadzie „fire-and-forget”, bez konieczności zagłębiania się bezpośrednio w kontekst i odrywania się od innych zadań. To znacznie oszczędza czas i zmniejsza obciążenie poznawcze.

Ciekawe będzie zobaczyć, co w odpowiedzi zaproponują konkurenci. ⁷