Notatki inżynierskie Naly: ingestowanie API Polymarket Gamma dla artykułów o rynkach predykcyjnych

TL;DRNaly importuje Gamma API Polymarket jako deterministyczną warstwę wykrywania i wyceny dla wszystkich przepływów związanych z rynkami predykcyjnymi, zastępując ad hoc scrapowanie wiadomości uporządkowanymi jednostkami rynkowymi. W każdym cyklu przekształca wydarzenia i rynki „na żywo” w sygnały gotowe do artykułu dla przeglądów niedoszacowania, zapowiedzi KBO, pakietów cytowań oraz późniejszej weryfikacji wyników, dzięki czemu generowanie treści zawsze zaczyna się od publicznie obserwowalnych prawdopodobieństw i struktury rynku, a nie z domniemanych opinii.

Streszczenie

Naly używa danych rynków predykcyjnych jako infrastruktury, nie jako nakładki, dlatego artefakty redakcyjne są bezpośrednio powiązane z zewnętrznym stanem rynku, który można później audytować. Gamma API dostarcza ścieżkę odczytu dla wydarzeń, rynków, tagów i cen bez konieczności kluczy na poziomie portfela. Wyzwanie projektowe polega na tym, by warstwę importu utrzymać wystarczająco ścisłą dla niezawodności, a jednocześnie na tyle elastyczną, by zespoły treści mogły szybko odkrywać tematy.

Miejsce w Naly

Ingestia Polymarket Gamma znajduje się na górnej granicy pomiędzy surowymi prymitywami rynku a aktywami redakcyjnymi możliwymi do opublikowania. Jest to pierwszy krok szerszego pipeline'u:

Warstwa wejściowa: pobierz wydarzenia, rynki, tagi i statusy rynków z Gamma.
Warstwa interpretacji: normalizuj do wewnętrznego schematu Naly (event_id, market_id, identyfikatory tokenów, wyniki, prawdopodobieństwa, znaczniki czasu, flagi aktywne/zamknięte).
Warstwa narracyjna: przekaż znormalizowane wejścia do przepływów tworzenia przeglądów niedoszacowania i projektowania przewidywań KBO.
Warstwa walidacji: zachowuj rozliczone/zamknięte stany rynku do późniejszego sprawdzania prawdziwości artykułów i retrospektywnych kart wyników.

Na dzień 10 czerwca 2026 r. jest to szczególnie spójne z aktywnymi taktykami wymagającymi wiarygodnych, gotowych do cytowania dowodów prognostycznych: widoczności kalibracji predykcji, powtarzalnego pozyskiwania treści i późniejszych przepływów weryfikacyjnych.

Mechanizm techniczny

Polymarket definiuje trzy API, przy czym Gamma jest publiczną płaszczyzną odkrywania do przeglądania zdarzeń/rynków i metadanych, podczas gdy dane z księgi zleceń i stylu handlu są udostępniane przez CLOB, a dane użytkownika/pozycji przez Data API (dokumentację). Gamma i Data są publiczne zgodnie z dokumentacją Polymarket, podczas gdy CLOB ma prywatne/tradingowe interfejsy wymagające uwierzytelnienia do operacji zleceń.

Naly może wdrożyć solidny, dzienny przepływ korzystając wyłącznie z publicznych endpointów:

Odkrywaj aktywne rynki kandydackie poprzez GET /events z active=true, closed=false, paginację (limit, offset), oraz opcjonalne filtry sortowania.
Rozszerz do rynków składowych przy użyciu ładunków na poziomie wydarzenia, ponieważ wydarzenia zawierają powiązane rynki i redukują liczbę wywołań API w porównaniu z oddzielnym wyszukiwaniem rynku.
Docelowe dokładne jednostki przy użyciu wywołań opartych na slug, gdy znane wydarzenie lub rynek jest już zidentyfikowane.
Normalizacja wyceny poprzez mapowanie outcomes i outcomePrices tablic indeks-po-indeksu na nazwane prawdopodobieństwa.
Zachowuj artefakty audytu zarówno jako znormalizowane wiersze, jak i surowe migawki, aby każdy artykuł mógł prześledzić każde źródłowe źródło liczb.
Ustaw blokowanie generacji dalej na podstawie świeżości + kontroli schematu; nieświeże lub niekompletne migawki są oznaczane do odświeżenia przed użyciem.

Dokumentacja Gamma opisuje dokładnie ten operacyjny układ: publiczne endpointy, takie jak /events, /markets, /public-search, /tags, i /series są dostępne do odkrywania, podczas gdy paginacja i filtrowanie są obsługiwane przez limit/offset, oraz powiązane filtry. Zawiera też bezpośrednie rekomendacje trzech wzorców pobierania: odczyt po slug, odkrywanie na podstawie tagów oraz enumeracja wydarzeń do szerokich skanów. Dla Naly wzorzec event-first jest najbardziej opłacalny przy budowie dużej liczby dziennych kandydatów, ponieważ każde wydarzenie może ujawnić wiele rekordów rynkowych. tag_idw praktyce minimalny rekord źródła prawdy dla Naly powinien obejmować:

identyfikatory wydarzeń i rynków

rynek
(do późniejszej rekonsyliacji cen z CLOB tam, gdzie to potrzebne) question
clobTokenIds oraz
outcomes , outcomePrices
enableOrderBook
active, i pola czasowe (znaczniki czasu startu/zakończenia) closedznacznik czasu pobrania i źródłowy URL
Chociaż Gamma może już dostarczać mocną bazę probabilistyczną, opcjonalna ścieżka drugiego doprecyzowania jest dostępna: gdy Naly potrzebuje krótszych, intraday aktualizacji, endpointy CLOB, takie jak

, /price, lub /pricesmogą zostać scalone później. /book Co mówią badania

Badania nad rynkami predykcyjnymi wspierają to podejście data-first, ale dodają bezpieczniki wokół interpretacji.

Model danych rynkowych w rynkach predykcyjnych jest użyteczny tylko wtedy, gdy jest skalibrowany i poprawnie interpretowany; ceny nie są uniwersalnymi prawdopodobieństwami bez kontekstu. Badanie z 2026 r. dotyczące Polymarket i Kalshi ujawniło systematyczne wzorce kalibracji, które różnią się w zależności od domeny i horyzontu, w tym mierzalną niedowiarność w określonych obszarach.

Inne badanie z 2026 r. koncentrujące się na cyklu życia podkreśla, że sensowna analiza rynkowa wymaga zsynchronizowanego, wielowarstwowego inżynierstwa danych: metadane rynkowe, zdarzenia transakcyjne i sygnały rozliczenia muszą mieć jawne połączenie i okresowe kontrole spójności, zamiast izolowanych pobrań.
Wcześniejsze prace nad mikrostrukturą rynku pokazują, że ceny rynkowe transmitują informacje traderów w trybie przypominającym aukcję ciągłą, dlatego Naly może traktować ceny jako sygnały prognoz zbiorowych, jednocześnie weryfikując wyniki w czasie.
Literatura prognostyczna porównująca ceny rynkowe z innymi metodami (np. prognozami opartymi na ankietach) pokazuje, że rynki predykcyjne mogą być silnie predykcyjne, ale tylko wtedy, gdy zachowana jest dyscyplina weryfikacji wyników i modelu.
Praktyczna konsekwencja dla Naly jest prosta: pobieraj wszystko z udokumentowanym pochodzeniem, nigdy nie traktuj pojedynczej migawki ceny jako ostatecznej prawdy oraz rozdzielaj

(aktualność danych + integralność) od readiness (oprawy redakcyjnej). story quality Kompromisy projektowe

Naly celowo optymalizuje niezawodność ponad szybkość w warstwie ingesta.

Gamma-only vs Gamma+CLOB:

Gamma zapewnia szybkie, stabilne odkrywanie i publiczny kontekst; dodanie CLOB poprawia bogactwo mikrostruktury, ale zwiększa złożoność uwierzytelniania i endpointów. Dzienne migawki vs strumieniowanie ciągłe:
deterministyczne, harmonogramowane pobieranie jest łatwiejsze do audytu i odtworzenia niż ciągłe strumienie, ale pomija zmianę trybu w skali poniżej minuty. Pobieranie event-first vs market-first:
event-first redukuje duplikaty wywołań i poprawia pokrycie kontekstowe; market-first daje nieco mniejszy rozmiar ładunku przy wąskich zadaniach. Szeroki schemat vs ścisły schemat:
szeroki schemat typu JSON-first przyspiesza integrację, ale zwiększa ryzyko dryfu schematu; ścisła normalizacja wychwytuje dryf wcześniej, ale zwiększa koszt migracji. Pola uogólnione vs pola domenowo-specyficzne:
wspólne pola poprawiają ponowne wykorzystanie w różnych artykułach; dodawanie rozszerzeń specyficznych dla domeny (np. okna ufności specyficzne dla sportu) zwiększa bieżącą precyzję, ale może rozbić długoterminowe utrzymanie. Biorąc pod uwagę cel Naly w obszarze zaufania użytkowników i retencji, ścisła reprodukowalność oraz jakość cytowań powinny dominować nad natychmiastową optymalizacją opóźnień.

Tryby awarii

Największe tryby awarii są operacyjne, a nie algorytmiczne.

Brak danych spowodowany błędami paginacji:

jeśli i limit okna zmieniają się pomiędzy odpytywaniami, mogą pojawić się duplikaty lub luki. Działanie naprawcze: oznaczaj kursory paginacji i egzekwuj idempotentne upserty. offset Domyślnie
pomijanie kontekstu historycznego: closed=false pobrania otwartych rynków pomijają rozliczone pozycje, chyba że jest jawnie wymagane. Działanie naprawcze: uruchamiaj dedykowaną ścieżkę historycznego dopełnienia dla zadań weryfikacyjnych. closed=true Niestabilność slug:
adresy produktów i slugi przyjazne człowiekowi mogą dryfować. Działanie naprawcze: wewną nazwę używaj jako głównego identyfikatora, a slug zachowaj jako klucz pomocniczy. Dryf pól semantycznych:
/ outcomesinterpretacja może się załamać, jeśli założenia co do kolejności pól w schemacie są błędne. Działanie naprawcze: wymuszaj wyrównanie tablic i kontrole długości podczas ingesta.outcomePrices Przejściowa dostępność API lub limitowanie:
publiczne endpointy mogą zawieść lub zwrócić częściowe payloady. Działanie naprawcze: ponawiaj z wykładniczym opóźnieniem, używaj kolejki z błędami (poison queue) przy powtarzających się porażkach i zachowuj poprzednie migawki. Późna rozliczalność i przestarzałe narracje:
artykuły weryfikacyjne mogą zostać opublikowane przed pełnym rozliczeniem rynku. Działanie naprawcze: przechowuj status rozliczenia jako część stanu publikacji i aktualizuj post factum z niezmiennym dziennikiem korekt. Biorąc pod uwagę strategię pierwszeństwa zaufania, pipeline powinien działać w trybie fail-closed: lepiej opóźnić artykuł niż publikować przy nieweryfikowalnym stanie rynku.

Uwagi implementacyjne

Przy zadanym stosie runtime praktyczna implementacja pozostaje prosta:

Używaj handlerów serwera Next.js (

), aby hostować endpointy ingesta i zadania zaplanowane.next@16.0.7Zapisuj znormalizowane wiersze w Neon, używając
oraz drizzle-orm@^0.44.7 z wyraźnymi ograniczeniami unikalności na identyfikatorach rynków. @neondatabase/serverless@^1.0.2 Przechowuj surowe snapshoty ładunku w Vercel Blob (
) dla audytowalności i porównań post-mortem.@vercel/blob@^2.0.0Przechowuj generowanie źródła Markdown i składanie artykułów poza rdzeniem ingesta; używaj
do bezpiecznej transformacji i marked@^17.0.1 oraz ai@6.0.0-beta.105 dopiero po przejściu kontroli integralności danych. @anthropic-ai/claude-agent-sdk@^0.2.15 Użyj
/ tsx@^4.21.0do odtwarzalnych jednorazowych odtworzeń przy dogrywaniu historycznych okien.typescript@^5.9.3 Na dzień 10 czerwca 2026 r. architektura powinna priorytetowo traktować trzy twarde rezultaty: niezmienność surowych snapshotów, deterministyczną projekcję do wewnętrznego schematu oraz ścieżkę audytu ukierunkowaną na weryfikację od źródłowego URL API do końcowego cytowania artykułu.

Referencje