บันทึกวิศวกรรมของ Naly: Polymarket Gamma ในฐานะชั้นสแนปช็อตตลาดที่ทำซ้ำได้

TL;DRการนำเข้า Polymarket Gamma ทำให้ Naly มีมุมมองสาธารณะที่มีโครงสร้างต่อเหตุการณ์ ตลาด ผลลัพธ์ ราคา แท็ก และเมทาดาทาการตัดสินผลของตลาดพยากรณ์ Naly ใช้ชั้นนี้เพื่อเลือกผู้สมัครบทความ ยึดโยงราวด์อัป mispricing รองรับเรื่องพยากรณ์ KBO เก็บรักษาการอ้างอิงแหล่งที่มา และสร้างสแนปช็อตตลาดที่คงทนสำหรับการตรวจสอบภายหลัง ข้ออ้างเชิงวิศวกรรมเรียบง่าย: ความน่าเชื่อถือด้านบรรณาธิการเริ่มจากอินพุตตลาดที่ทำซ้ำตรวจสอบได้ ไม่ใช่ร้อยแก้วที่ถูกสร้างขึ้น

บทคัดย่อ

Polymarket Gamma API ควรถูกมองเป็นแหล่งค้นพบตลาดและเมทาดาทาของ Naly ไม่ใช่อินเทอร์เฟซการเทรด เอกสารทางการของ Polymarket แยก Gamma ออกจาก Data และ CLOB APIs: Gamma ครอบคลุมเหตุการณ์ ตลาด แท็ก ซีรีส์ เมทาดาทากีฬา การค้นหา ความคิดเห็น และโปรไฟล์สาธารณะ ขณะที่ CLOB จัดการ order books ราคา spreads และการดำเนินการเทรดที่ต้องยืนยันตัวตน สำหรับบทความของ Naly เส้นแบ่งนั้นมีประโยชน์ เวิร์กโฟลว์บรรณาธิการส่วนใหญ่ต้องการข้อความคำถาม อัตลักษณ์ของตลาด ป้ายผลลัพธ์ ความน่าจะเป็นที่แสดง แท็กหมวดหมู่ กำหนดเวลา และบริบทการตัดสินผล ก่อนที่จะต้องการรายละเอียด order-book ระดับ tick

วิทยานิพนธ์ของบันทึกนี้คือ Naly ควรนำเข้า Gamma เข้าสู่ชั้นสแนปช็อตตลาดแบบมีเวอร์ชัน สแนปช็อตไม่ใช่ความจริง แต่เป็นสถานะตลาดสาธารณะที่สังเกตได้ ณ เวลาหนึ่ง ผูกกับ URL แหล่งที่มาและเก็บ payload ดิบไว้ สิ่งนี้ทำให้ Naly เผยแพร่สิ่งที่คนอื่นซ่อน: บริบทของตลาด ข้อจำกัดของสัญญาณ และหลักฐานที่แน่ชัดซึ่งใช้เมื่อบทความถูกสร้างขึ้น

ตำแหน่งของมันใน Naly

การนำเข้า Gamma อยู่ก่อนการสร้างบทความและหลังการค้นพบแหล่งข้อมูลภายนอก ในเส้นทางการเผยแพร่ของ Naly มันให้ด้านตลาดพยากรณ์ของชุดหลักฐานสำหรับการใช้งานปลายน้ำสี่อย่าง:

ราวด์อัป mispricing ต้องการผู้สมัครเหตุการณ์และตลาดปัจจุบัน พร้อมเมทาดาทามากพอที่จะเทียบความน่าจะเป็นที่ตลาดบ่งชี้กับเหตุผลที่มีแหล่งข้อมูลรองรับ
บทความพยากรณ์ KBO ต้องการตลาดกีฬา แท็กทีมหรือเหตุการณ์ กำหนดเวลาเหตุการณ์ และป้ายผลลัพธ์ที่สามารถเรนเดอร์ได้โดยไม่ต้องป้อนบริบทตลาดด้วยมือ
การอ้างอิงแหล่งข้อมูลต้องการ URL ตลาดที่เสถียร event slugs และตัวระบุตลาด เพื่อให้ผู้อ่านตรวจสอบได้ว่าทำไมบทความจึงกล่าวถึงสัญญาเฉพาะนั้น
การตรวจสอบคำพยากรณ์ต้องการสแนปช็อตย้อนหลัง เพื่อให้การตัดสินผลภายหลังสามารถให้คะแนนเทียบกับความน่าจะเป็นที่ Naly เห็นจริง ณ เวลาเผยแพร่

ข้อเท็จจริงของรันไทม์ภายในสำคัญต่อรูปทรงของระบบมากกว่าความแปลกใหม่ TypeScript 5.9 และ tsx เหมาะสมพอสำหรับสคริปต์ ingestion; drizzle-orm พร้อม @neondatabase/serverless สามารถบันทึกเรคอร์ดที่ normalize แล้วและ JSON ดิบ; Next.js 16 และ React 19 สามารถเรนเดอร์หน้าบทความที่ได้; แพ็กเกจ ai และ Claude SDK สามารถใช้ชุดหลักฐานที่เตรียมไว้ได้ก็ต่อเมื่อ ingestion ทำให้สถานะตลาดชัดเจนแล้ว

กลไกทางเทคนิค

ลูปการนำเข้า Gamma ที่แข็งแรงมีหกขั้นตอน

การค้นพบ ใช้เหตุการณ์ของ Gamma เมื่อ Naly ต้องการค้นพบตลาด active แบบกว้าง และใช้ market หรือ event slugs เมื่อบทความยึดโยงกับ URL Polymarket ที่ทราบแล้ว คู่มือ market-data ของ Polymarket แนะนำให้ใช้ events สำหรับการค้นพบ active ที่ครบถ้วน เพราะ events รวม markets ที่เกี่ยวข้องไว้ด้วย จึงลดจำนวน API calls สำหรับงานตามหมวดหมู่ เช่น กีฬา แท็กและเมทาดาทากีฬาควรจำกัดขอบเขตการ crawl ก่อนจัดอันดับผู้สมัคร
การแบ่งหน้า Gamma รองรับทั้ง endpoints แบบ offset และ endpoints แบบ keyset สำหรับการ crawl ขนาดใหญ่หรือซ้ำๆ keyset pagination ปลอดภัยกว่า เพราะ next_cursor กลายเป็น continuation token และ offset ถูกปฏิเสธอย่างชัดเจนบน keyset markets endpoint สำหรับงานบทความขนาดเล็กที่เจาะจง offset pagination ยังยอมรับได้เมื่อกรอบ query แคบและ output ถูก snapshot ทันที
การ normalize กฎหลักของการ normalize คือป้ายผลลัพธ์และราคาผลลัพธ์ต้องถูก map ตามตำแหน่ง ภาพรวม market-data ของ Polymarket ระบุ outcomes และ outcomePrices arrays เป็น arrays แบบหนึ่งต่อหนึ่ง ดังนั้นวินัยด้าน index จึงสำคัญ array ที่สลับกันไม่ใช่บั๊กเชิงความสวยงาม แต่มันพลิกความหมายการตีความตลาดของบทความ
การทำ snapshot เก็บทั้งคอลัมน์ที่ normalize แล้วและ JSON ดิบ คอลัมน์ที่ normalize แล้วควรรวม provider, fetched timestamp, event id หรือ slug, market id หรือ slug, ข้อความคำถาม, condition id เมื่อมี, token identifiers เมื่อมี, ป้ายผลลัพธ์, ราคาผลลัพธ์, flags active และ closed, end time, tags, source URL และ payload hash JSON ดิบช่วยป้องกัน Naly จาก schema drift และทำให้การตรวจสอบสามารถ replay artifact การ ingestion ที่แน่ชัดได้
การให้คะแนนผู้สมัคร งานบทความควรจัดอันดับตลาดด้วยเกณฑ์บรรณาธิการ ไม่ใช่เกณฑ์การดำเนินการเทรด: ความสดใหม่ volume หรือ liquidity เมื่อมี ความใกล้ถึงการตัดสินผล ความพร้อมของแหล่งข้อมูล ความเหมาะสมของหมวดหมู่ และตลาดนั้นสามารถสร้าง contrast ที่ชัดเจนต่อผู้อ่านได้หรือไม่ การให้คะแนนผู้สมัครไม่ควรสื่อโดยเด็ดขาดว่าราคาตลาดผิดโดยอัตโนมัติ แต่ควรทำเครื่องหมายว่าตลาดนั้นคุ้มค่าต่อการค้นคว้า
การผูกกับการเผยแพร่ เมื่อบทความที่สร้างขึ้นอ้างถึงตลาด บทความควรลิงก์ไปยัง stored snapshot id, Polymarket source URL และชุดหลักฐานภายนอกที่ผู้เขียนใช้ นี่คือความแตกต่างระหว่างหน้าที่บอกว่าตลาดอยู่ที่ 62 percent กับหน้าที่พิสูจน์ได้ว่า ค่านั้นมาจากเมื่อใด ที่ไหน และ payload ใด

Rate limits เป็นส่วนหนึ่งของกลไก Polymarket ระบุการ throttling ที่ Cloudflare บังคับใช้และขีดจำกัด Gamma เฉพาะสำหรับ /events, /markets, /tags, และ /public-search. Naly ไม่จำเป็นต้องเข้าใกล้ขีดจำกัดเหล่านั้นสำหรับการเผยแพร่รายวัน ดังนั้นท่าทีที่ถูกต้องคืออนุรักษ์นิยม: concurrency ที่มีขอบเขต, retry พร้อม jitter, payload hashes เพื่อ idempotency และ alerting เมื่องานได้รับ responses ที่ถูก throttle, ว่างเปล่า หรือมีโครงสร้างผิดจากที่คาด

วรรณกรรมกล่าวว่าอย่างไร

งาน arXiv ล่าสุดสนับสนุนการออกแบบแบบ snapshot-first Jia et al. อธิบายว่าข้อมูลตลาดพยากรณ์แบบ decentralized กระจัดกระจายอยู่ใน off-chain metadata, บันทึกการเทรดระดับ fill และเหตุการณ์ oracle-resolution จากนั้นเสนอระบบ relational แบบรวมศูนย์ที่มี identifier resolution, incremental updates และ consistency mechanisms ระบบเผยแพร่ที่เล็กกว่าของ Naly มีปัญหาในชนิดเดียวกัน: เมทาดาทาตลาดอย่างเดียวไม่พอ เว้นแต่มันจะสามารถ join กับราคา คำกล่าวอ้างในบทความ และผลการตัดสินภายหลังได้

งานศึกษาการ calibration ของ Le เกี่ยวข้องโดยตรงกับภาษาของบทความ โดยใช้ชุดข้อมูล Kalshi และ Polymarket ขนาดใหญ่ บทความวิจัยชี้ว่า calibration ขึ้นกับ domain, horizon และผลของ trade-size; ผู้บริโภคที่มองราคาเป็นความน่าจะเป็นตามมูลค่าหน้าตั๋วอาจตีความผิดอย่างเป็นระบบได้ สำหรับ Naly นี่หมายความว่าบทความควรพูดว่า market-implied probability, observed price หรือ public market signal ไม่ใช่ความจริง บทความสามารถอภิปราย mispricing ที่เป็นไปได้ได้ก็ต่อเมื่อแยกการสังเกตตลาดดิบออกจากโมเดลของ Naly หรือเหตุผลที่มีแหล่งข้อมูลรองรับแล้ว

บทความของ Dubach เกี่ยวกับ microstructure ของ Polymarket ส่วนใหญ่กล่าวถึงข้อมูล order-book แต่มันให้คำเตือนที่มีประโยชน์ต่อการออกแบบ ingestion: หลักฐานตลาดความถี่สูงมี error modes เฉพาะแหล่งที่มา ความล่าช้าในการ ingestion และ joins ที่สำคัญ Gamma มีความละเอียดน้อยกว่า order-book feeds แต่หลักการเดียวกันยังใช้ได้ แหล่งที่มาของตัวเลขต้องมองเห็นได้ Gamma snapshot, CLOB midpoint และ on-chain trade record เกี่ยวข้องกัน แต่ใช้แทนกันไม่ได้

Madrigal-Cianci, Monsalve Maya และ Breakey วางกรอบตลาดพยากรณ์เป็น Bayesian inverse problems ซึ่งประวัติความน่าจะเป็นและ volume ที่สังเกตได้มี noise, endogenous และถูกหล่อหลอมโดย trader types ที่หลากหลาย สิ่งนี้ย้ำจุดยืนด้านบรรณาธิการของ Naly สถานะตลาดที่นำเข้าเป็นหลักฐาน ไม่ใช่คำตัดสิน วิศวกรรมที่ดีทำให้ความไม่แน่นอนนั้นตรวจสอบได้ แทนที่จะชะล้างมันออกไประหว่างการสร้างเนื้อหา

Trade-offs ด้านการออกแบบ

Gamma เทียบกับ CLOB คือ trade-off แรก Gamma ให้ Naly ได้ discoverability, บริบทบทความ และเมทาดาทา CLOB ให้ pricing และกลไก order-book ที่คมกว่า สำหรับบทความวิศวกรรมรายวันและราวด์อัปตลาดพยากรณ์ Gamma ควรเป็นอินพุตค่าเริ่มต้น เพราะมันตอบว่าตลาดเกี่ยวกับอะไร CLOB สามารถเพิ่มได้เมื่อบทความต้องการ spread, midpoint หรือความแม่นยำของ price-history

การนำเข้าแบบ event-first เทียบกับ market-first คือ trade-off ที่สอง Event-first ถูกกว่าสำหรับการสแกนกว้าง เพราะ event หนึ่งสามารถมีหลาย markets และเมทาดาทาร่วม Market-first สะอาดกว่าสำหรับการตรวจสอบ เพราะคะแนนสุดท้ายผูกกับผลลัพธ์ไบนารีเฉพาะ Naly ควรนำเข้าทั้งสองรูปแบบ แต่ทำให้ลิงก์บทความชี้ไปยังคำกล่าวอ้างระดับ market เมื่อใดก็ตามที่กำลังประเมินผลลัพธ์เดี่ยว

Raw JSON เทียบกับ typed schema คือ trade-off ที่สาม Raw JSON อย่างเดียวเก็บง่าย แต่ query อย่างปลอดภัยได้ยาก typed columns อย่างเดียว query ง่าย แต่เปราะเมื่อ fields ของ provider เปลี่ยนแปลง รูปแบบที่คงทนคือใช้ทั้งคู่: typed fields สำหรับการจัดอันดับ การเรนเดอร์ และ joins; raw payloads สำหรับ audit, replay และ migration

Live render เทียบกับ frozen render คือ trade-off ที่สี่ widget ตลาดแบบ live อาจมีประโยชน์ แต่คำกล่าวอ้างในบทความต้องผูกกับ snapshot ณ เวลาเผยแพร่ ไม่เช่นนั้นบทความเก่าอาจเปลี่ยนความหมายอย่างเงียบๆ เมื่อ Polymarket เคลื่อนไหว ปิด หรือ resolve ตลาด สำหรับกลยุทธ์ความน่าเชื่อถือของ Naly หลักฐานแบบ frozen ดีกว่าความสดใหม่เมื่อหน้าหนึ่งแสดงคำกล่าวอ้างที่มีวันที่กำกับ

Failure modes

ความล้มเหลวที่อันตรายที่สุดคือการจัดแนว outcome-price ผิด หาก Yes และ No labels ถูก parse แยกจากราคา บทความอาจกลับทิศสัญญาณทั้งที่ยังดูน่าเชื่อ

ความล้มเหลวที่สองคือการใช้ตลาดเก่าซ้ำ ตลาดหนึ่งอาจ active ระหว่างการค้นพบและ closed เมื่อถึงเวลาเผยแพร่ งานบทความแต่ละงานควรตรวจสอบ fields active, closed, archived และ end-time อีกครั้งทันทีก่อนผูก snapshot

ความล้มเหลวที่สามคือความกำกวมแบบหลายตลาด Polymarket event หนึ่งอาจมีหลายตลาดที่เทรดได้ ราวด์อัปสามารถอ้างถึง event ได้ แต่เรคอร์ดการตรวจสอบต้องอ้างถึง market และ outcome เฉพาะที่ Naly ประเมิน

ความล้มเหลวที่สี่คือ schema drift Public APIs เปลี่ยน field names, defaults และ nested relations ได้ การจัดเก็บ snapshot ควรรวม payload hashes, parser version, provider URL และ validation errors เพื่อให้มองเห็น drift ได้

ความล้มเหลวที่ห้าคือการ overclaim calibration ราคาตลาดเป็นสัญญาณสาธารณะที่มีประโยชน์ แต่วรรณกรรมเตือนไม่ให้มองมันเป็นความน่าจะเป็นที่สะอาดในทุก domains และ horizons สำเนาของ Naly ควรรักษาความแตกต่างระหว่าง market-implied probability, Naly estimate และ realized outcome

ความล้มเหลวที่หกคือการสูญเสีย citation หากบทความเก็บไว้เพียง markdown ที่เรนเดอร์แล้ว การตรวจสอบภายหลังจะพิสูจน์ไม่ได้ว่าหน้าตลาดและ payload ใดรองรับคำกล่าวอ้าง Article-market joins ควรเป็นเรคอร์ดชั้นหนึ่ง ไม่ใช่ร้อยแก้วที่ฝังอยู่ในเนื้อหา

บันทึกการใช้งานจริง

การใช้งานจริงของ Naly สามารถทำให้ ingestion contract เล็กไว้ได้:

provider: polymarket-gamma.
provider_url: Gamma endpoint หรือ public market URL ที่แน่ชัดซึ่งใช้สำหรับการค้นพบ
fetched_at: server timestamp ใน UTC
event_key และ market_key: stable provider identifiers หรือ slugs
question: ข้อความคำถามตลาดแบบ canonical
outcomes: ป้ายที่มีลำดับ
outcome_prices: decimal strings ที่มีลำดับ ซึ่ง normalize เป็นค่าตัวเลขหลังผ่าน validation เท่านั้น
status: flags active, closed, archived และ publishability
raw_payload: provider response ฉบับเต็ม
payload_hash: deterministic hash สำหรับ idempotency และ replay
parser_version: code contract ที่ตีความ payload

Article generator ควรได้รับสิ่งนี้เป็นหลักฐานที่มีโครงสร้าง ไม่ใช่ prompt text แบบหลวมๆ จากนั้นมันสามารถสร้าง markdown ผ่าน AI stack ที่มีอยู่ เรนเดอร์ด้วย site pipeline และเก็บ citations ให้ผูกกับ source records ได้ ภายหลัง verification worker สามารถ join market snapshot ของบทความกับ resolution data และให้คะแนนว่าคำกล่าวอ้างที่เผยแพร่นั้นผ่านกาลเวลาได้ดีหรือไม่

หลักการวิศวกรรมนี้ตั้งใจให้อนุรักษ์นิยม: ingest, normalize, snapshot, cite แล้วจึง write ลำดับนี้ช้ากว่าการขอให้โมเดล browse และ summarize หน้าตลาด แต่มันสร้าง artifact ที่ Naly ต้องการจริงๆ สำหรับ acquisition และ retention: บทความสาธารณะที่หลักฐานตลาดสามารถ replay ได้หลังทราบผลแล้ว