researcher: คลังงานวิจัยควอนต์ที่ค้นหาได้สำหรับมนุษย์และเอเจนต์ AI

งานวิจัยควอนต์อยู่ทุกที่และไม่อยู่ที่ไหนเลย เปเปอร์ที่คุณต้องการอยู่บน arXiv โค้ดอ้างอิงที่นำไปใช้จริงอยู่บน GitHub สัญชาตญาณเชิงลึกถูกฝังอยู่ในบล็อกโพสต์ที่ใครบางคนเขียนไว้เมื่อปี 2019 ส่วนตรรกะการเข้า/ออกออเดอร์จริง ๆ เป็นสคริปต์ Pine บน TradingView ที่มี 400 ไลก์โดยไม่มีเอกสารประกอบใด ๆ สี่คลังข้อมูล สี่ช่องค้นหา สี่ชุดแบบแผน และไม่มีการอ้างอิงข้ามกันเลยสักนิด เมื่อคุณกำลังตัดสินใจว่าไอเดียหนึ่งคุ้มค่ากับการทำ backtest ทั้งสัปดาห์หรือไม่ ความกระจัดกระจายนั้นคือต้นทุนที่แท้จริง — ไม่ใช่การอ่าน แต่เป็น การค้นหา

เราจึงสร้างของเราเองขึ้นมา researcher.marketmaker.cc คือคลังข้อมูลที่คัดสรรแล้วและเป็นเสิร์ชเอนจินสำหรับงานวิจัยด้านการเทรดเชิงปริมาณ มันรวบรวมเนื้อหาที่ปกติกระจัดกระจายอยู่ทั่ว arXiv, GitHub, บล็อกควอนต์ และ TradingView ให้มาอยู่ที่เดียว ทำดัชนีทั้งหมดสำหรับการค้นหาด้วยข้อความเต็ม และ — นี่คือส่วนที่เราใส่ใจมากที่สุด — เปิดให้เอเจนต์ AI เข้าถึงคลังข้อมูลทั้งหมดผ่านเอนด์พอยต์ Model Context Protocol (MCP) และ REST API สาธารณะ มันคือฐานรองงานวิจัยที่มนุษย์เปิดเรียกดูได้ด้วยคีย์บอร์ดและเอเจนต์สอบถามได้ด้วยการเรียก tool โดยทั้งคู่อ้างอิงดัชนีชุดเดียวกันเป๊ะ

โพสต์นี้พาทัวร์ว่าข้างในมีอะไร สร้างขึ้นมาอย่างไร และทำไมมันจึงอยู่ตรงตำแหน่งนั้นในสแต็กเอเจนต์ AI ของเรา

ในคลังข้อมูลมีอะไรบ้าง

researcher รวมชุดข้อมูลหลักสี่ชุด แต่ละชุดมีดัชนีค้นหาด้วยข้อความเต็มของตัวเอง ตัวเลขด้านล่างเป็นข้อมูล ณ วันที่ 2026-06-12 และตัวเลขเหล่านี้เปลี่ยนแปลงได้ — ไปป์ไลน์ arXiv ทำงานทุกวันและดัชนีถูกสร้างใหม่จากต้นทาง ตัวเลขจึงเพิ่มขึ้นเรื่อย ๆ

รวมแล้วราว ๆ กว่า 51,000 เอกสารกระจายอยู่ในดัชนีค้นหาได้ทั้งสี่ชุด ดัชนี papers เป็นคลังข้อมูลเดี่ยวที่ใหญ่ที่สุดและเป็นชุดที่เราทุ่มเทกับมันมากที่สุด มันคือสายธารงานวิจัยด้านการเงินเชิงปริมาณทั้งหมดของ arXiv (q-fin.*) ย้อนกลับไปถึงปี 1997 ไม่ใช่ชุดย่อยที่คัดเลือกมาด้วยมือ ก่อนหน้านี้เว็บไซต์ขนเปเปอร์ที่คัดสรรมาเพียงไม่กี่ร้อยฉบับ ส่วนดัชนีปัจจุบันคือคลัง q-fin ที่สมบูรณ์ โดยมีข้อมูลที่มาที่คัดสรรแล้วผสานทับลงไปด้านบน ดังนั้นเปเปอร์ที่ ยังถูก อ้างอิงโดยบล็อกควอนต์ฉบับใดฉบับหนึ่งด้วยจึงพ่วงข้อมูลการอ้างอิงนั้นมาด้วย

นอกเหนือจากดัชนีค้นหาทั้งสี่ชุดแล้ว เว็บไซต์ฝั่งที่หันเข้าหามนุษย์ยังเพิ่มชั้นเนื้อหาเข้าไปอีก: บันทึกงานวิจัยและสรุปข่าวรายวันที่เราเขียนเอง ไดเรกทอรีของ เว็บไซต์ และ ผู้เขียน ควอนต์ ส่วน วิดีโอ ที่ทำดัชนีช่อง YouTube ที่เกี่ยวข้อง และไดเรกทอรี กองทุน ดัชนีทั้งสี่ชุดเป็นกระดูกสันหลังที่ค้นหาได้ ส่วนอย่างอื่นคือการคัดสรรที่อยู่รายรอบมัน

แหล่งความจริงหนึ่งเดียว

สิ่งที่พังเงียบ ๆ สำหรับเราตั้งแต่ช่วงแรก ๆ — และสิ่งที่ตอนนี้เราออกแบบป้องกันอย่างหนักแน่น — คือ จำนวนไม่ตรงกัน หน้าแรกบอกตัวเลขหนึ่ง การค้นหาคืนค่าอีกตัวเลข API คืนค่าตัวเลขที่สาม ณ จุดหนึ่งหน้าแรกโฆษณาว่ามีเปเปอร์ 719 ฉบับขณะที่การค้นหาคืนค่ามากกว่า 18,000 ฉบับ ไม่มีอะไรกัดกร่อนความเชื่อมั่นในเครื่องมือวิจัยได้รุนแรงไปกว่าคลังข้อมูลที่ไม่อาจตกลงกับตัวเองได้ว่ามันใหญ่แค่ไหน

วิธีแก้คือทำให้ทุกพื้นผิวอ่านข้อมูลจากที่เดียว สำหรับคลัง papers นั้น Meilisearch คือแหล่งความจริง ไม่มีสำเนาเปเปอร์ชุดที่สองอาศัยอยู่ในแอปบันเดิล จำนวนบนหน้าแรก จำนวนบน /papers จำนวนที่ API คืนค่า และเอกสารที่คุณค้นหาจริง ๆ ล้วนมาจากดัชนีเดียวกันทั้งหมด ตัวคลังข้อมูลเองถูกสร้างขึ้นแบบ offline โดยขั้นตอนนำเข้าข้อมูลที่รับชุดเปเปอร์ที่คัดสรรแล้ว ยูเนียนเข้ากับสายธาร arXiv (กำจัดข้อมูลซ้ำด้วย arXiv id พร้อมผสานอาร์เรย์ข้อมูลที่มา) จัดเรียงใหม่สุดมาก่อน แล้วเขียนไฟล์เดียวขนาดราว ~25 MB ที่ตัว indexer นำไปใช้ ไฟล์นั้นมีประมาณ 15,000–18,000 เรกคอร์ดและจงใจ ไม่ บันเดิลเข้าไปในฝั่งไคลเอนต์ — คลังข้อมูลขนาดเท่านั้นไม่มีเหตุผลที่จะถูกส่งไปยังเบราว์เซอร์

ชุดข้อมูลอีกสามชุด (code, articles, สคริปต์ Pine) ถูกอ่านฝั่งเซิร์ฟเวอร์จากไฟล์ JSON ของมันและทำดัชนีจากไฟล์เดียวกัน โดยการย้ายไปใช้ Meili เป็นแหล่งความจริงคือก้าวถัดไปที่วางแผนไว้ กฎที่ใช้ทั่วทั้งระบบคือ: อ่านข้อมูลบนเซิร์ฟเวอร์ ห้าม import ชุดข้อมูลขนาดหลายเมกะไบต์เข้าไปในบันเดิลฝั่งไคลเอนต์ และให้ดัชนีกับจำนวนที่แสดงผลมาจากต้นกำเนิดเดียวกัน การไม่ซิงค์กันจึงเป็นไปไม่ได้เลยในเชิงโครงสร้าง

การค้นหา: ข้อความเต็ม ทนต่อการพิมพ์ผิด และมีฟาเซต

เสิร์ชเอนจินคือ Meilisearch ที่รันบนเซิร์ฟเวอร์เดียวกับแอปและผูกกับ localhost — มันไม่ถูกเปิดเผยสู่สาธารณะ เราใช้มันเป็น เสิร์ชเอนจินข้อความเต็ม ไม่ใช่ vector store ไม่มี embedding ไม่มีเวทมนตร์ความคล้ายเชิงความหมาย สำหรับโจทย์ "หาเปเปอร์และ repo ที่กล่าวถึง แนวคิดนี้ ให้หน่อย" การค้นหาแบบ lexical ที่ทนต่อการพิมพ์ผิดบนชื่อเรื่อง บทคัดย่อ คำอธิบาย ผู้เขียน และแท็กนั้นรวดเร็ว คาดเดาได้ และดีบักได้ในแบบที่ดัชนี embedding ทำไม่ได้ ดัชนีแต่ละชุดเก็บเอกสารต้นฉบับ ฉบับสมบูรณ์ บวกกับ _id ที่เพิ่มเข้ามา ดังนั้นการค้นหาจะคืนเรกคอร์ดที่เติมข้อมูลครบถ้วนซึ่งแอปสามารถเรนเดอร์ได้โดยตรง — ไม่ต้องดึงข้อมูลรอบสองเพื่อเติมข้อมูลให้ผลลัพธ์

รายละเอียดบางอย่างที่สำคัญในทางปฏิบัติ:

• การทนต่อการพิมพ์ผิดและการจัดอันดับความเกี่ยวข้อง ได้มาฟรีจาก Meilisearch ค้นหา momentm ก็ยังเจอเปเปอร์เกี่ยวกับ momentum ผลลัพธ์ถูกจัดอันดับ ไม่ใช่แค่ถูกกรอง

• การกรองแบบฟาเซต เปเปอร์กรองด้วย category ของ arXiv (q-fin.PM, q-fin.TR, …) repo กรองด้วย language และ stars บทความกรองด้วย source และ date สคริปต์ Pine กรองด้วย category หน้า /papers สร้างดรอปดาวน์หมวดหมู่จากการกระจายตัวฟาเซตสด ๆ ของดัชนี ดังนั้นตัวเลือกการกรองจึงสะท้อนสิ่งที่อยู่ในคลังข้อมูลจริง ๆ เสมอ

• การแยก camelCase Meilisearch แบ่งโทเคนที่ช่องว่างและเครื่องหมายวรรคตอน แต่ไม่แบ่งที่ camelCase นั่นหมายความว่า repo ที่ชื่อ TradingAgents ตรง ๆ จะกลายเป็นโทเคนเดียวที่คิวรีตามธรรมชาติอย่าง "trading agents" เข้าถึงไม่ได้ ระหว่างการทำดัชนีเราได้สร้างฟิลด์ name_split ขึ้นมา — TradingAgents → TradingAgents Trading Agents, ai-hedge-fund → ai-hedge-fund ai hedge fund — และเพิ่มมันเข้าไปในแอตทริบิวต์ที่ค้นหาได้ โทเคนต้นฉบับถูกเก็บไว้เป็นอันดับแรกเพื่อให้การจับคู่ชื่อแบบตรงเป๊ะยังคงได้อันดับสูงสุด และฟิลด์ที่สร้างขึ้นมานี้ไม่เคยถูกคืนค่าไปยังไคลเอนต์ มันเป็นเรื่องเล็ก ๆ ที่สร้างความแตกต่างระหว่างการเจอกับไม่เจอ repo ตัวเอก

• เปิดเรียกดู = ใหม่สุดมาก่อน คิวรีว่างเปล่าไม่ใช่ข้อผิดพลาด มันคือเส้นทางการเปิดเรียกดู บน /papers คิวรีว่างเปล่าจะจัดเรียงด้วย published จากมากไปน้อย ดังนั้นหน้านี้จึงทำหน้าที่เป็นฟีดเรียงตามเวลาย้อนหลังของงานวิจัย q-fin ล่าสุดไปในตัว

• ดัชนีเสริมสำหรับค่ารวม ตัวเลขบางอย่างที่ Meilisearch คำนวณตอนคิวรีได้ไม่คุ้มต้นทุน — ดาวรวมทั้งหมดข้าม repo ทั้งหมด จำนวนไฟล์ Python ทั้งหมด จำนวนโน้ตบุ๊กทั้งหมด แทนที่จะสแกนคลังข้อมูลทั้งหมดทุกครั้งที่โหลดหน้า indexer เขียนผลรวมเหล่านั้นครั้งเดียวตอนทำดัชนีลงในดัชนี researcher_meta ขนาดเล็กที่เก็บหนึ่งเอกสารต่อหนึ่งชุดข้อมูล เอนด์พอยต์ stats อ่านมันกลับมาตรง ๆ จำนวนที่เปลี่ยนแปลงเฉพาะตอนทำดัชนีใหม่จึงถูกคำนวณเฉพาะตอนทำดัชนีใหม่เท่านั้น

• เพดานเพจจิเนชันที่ใช้งานได้จริง ดัชนี papers ยก maxTotalHits ของ Meilisearch ขึ้นเป็น 50,000 และทำเครื่องหมาย published ให้จัดเรียงได้ ดังนั้นคุณจึงเปิดหน้าลึกลงไปในคลังข้อมูลขนาด ~18k เอกสารและจัดเรียงทั้งคลังให้ใหม่สุดมาก่อนได้ — ไม่ใช่แค่หน้าแรกของผลลัพธ์ตามความเกี่ยวข้อง

indexer เป็น idempotent: มันสร้างดัชนีแต่ละชุดหากยังไม่มี ใช้การตั้งค่าซ้ำ และ upsert ทุกเอกสารเป็นชุดละ 2,000 รายการโดยอิงคีย์ _id (papers ได้คีย์มาจาก arXiv id ส่วน repo และบทความได้มาจากแฮชของ URL) เนื่องจากดัชนีทั้งหมดสามารถสร้างใหม่ได้จากไฟล์ต้นทาง จึงไม่มีแบ็กอัปให้ต้องบริหารจัดการ — การย้อนกลับก็แค่ทำดัชนีใหม่ การรันมันซ้ำจึงปลอดภัยโดยโครงสร้าง

เข้าถึงได้ด้วยเอเจนต์: MCP และ API สาธารณะ

นี่คือส่วนที่ผูก researcher เข้ากับสิ่งอื่น ๆ ที่เราทำ คลังข้อมูลไม่ได้เป็นแค่เว็บไซต์ที่มีช่องค้นหา — มันคือ tool ที่เอเจนต์ AI เรียกใช้ได้

เอนด์พอยต์ MCP

researcher เปิดเซิร์ฟเวอร์ Model Context Protocol ที่ /api/mcp ผ่าน Streamable HTTP เอเจนต์ใด ๆ ที่รองรับ MCP — Claude, เอเจนต์แบบกำหนดเองในสแต็กของเราเอง หรืออะไรก็ตามที่พูดโปรโตคอลนี้ได้ — สามารถเชื่อมต่อและเรียก tool แบบอ่านอย่างเดียวกับคลังข้อมูลสดได้ มี tool ทั้งหมด 13 รายการ จัดกลุ่มตามชุดข้อมูล ตามรูปแบบ search / get / list ที่สอดคล้องกัน:

สคีมาของ tool ถูกเขียนขึ้นเพื่อประโยชน์ของเอเจนต์ ไม่ใช่ของมนุษย์ ยกตัวอย่างเช่น search_papers ประกาศตัวเองว่าเป็นการค้นหาที่ทนต่อการพิมพ์ผิดและจัดอันดับตามความเกี่ยวข้องบนชื่อเรื่อง บทคัดย่อ และผู้เขียน พร้อมตัวกรอง category เสริม (เช่น q-fin.PM) และการจำกัดจำนวนผลลัพธ์ — และบอกเอเจนต์ให้เรียก get_paper เพื่อดูบทคัดย่อฉบับเต็มเมื่อกรองผลลัพธ์ให้แคบลงแล้ว search คืนผลลัพธ์ขนาดกะทัดรัดเท่าสนิปเป็ตเพื่อให้เอเจนต์กวาดผลลัพธ์จำนวนมากได้ในต้นทุนต่ำ ส่วน get คืนเรกคอร์ดฉบับเต็มเมื่อเลือกได้แล้วหนึ่งรายการ รูปแบบสองขั้นตอนนั้นช่วยไม่ให้คอนเท็กซ์วินโดว์ของเอเจนต์จมไปกับบทคัดย่อที่มันไม่ต้องการ

ในเชิงรูปธรรม เอเจนต์ที่กำลังศึกษา เช่น optimal execution สามารถรัน search_papers("optimal execution", category: "q-fin.TR") เพื่อให้ได้รายชื่อเรื่องและสนิปเป็ตที่จัดอันดับแล้ว รัน search_repos("optimal execution", language: "Python") เพื่อหาโค้ดที่นำไปใช้จริงโดยจัดเรียงตามความเกี่ยวข้องและกรองได้ด้วยจำนวนดาว และรัน search_pine("VWAP") เพื่อดูว่าไอเดียเดียวกันปรากฏเป็นกลยุทธ์ที่เผยแพร่บน TradingView อย่างไร — การเรียก tool สามครั้งกับสามคลังข้อมูลที่เมื่อชั่วโมงก่อนยังเป็นเว็บไซต์สามแห่งที่แตกต่างกัน จากนั้น get_paper เพียงครั้งเดียวก็ดึงบทคัดย่อฉบับเต็มของรายการที่ดูมีแววออกมา เอเจนต์ไม่เคยออกจากโปรโตคอลเลย และทุกผลลัพธ์คือเรกคอร์ดจริงที่เติมข้อมูลครบถ้วน ไม่ใช่ stub ของผลการค้นหาที่ต้องไปดึงข้อมูลใหม่

REST API สาธารณะ

สำหรับผู้ใช้ที่ไม่ใช่ MCP มี REST แบบขนานอยู่ใต้ /api/v1/: papers, repos, articles, pine และค่ารวม stats มันพูด JSON ธรรมดาด้วยพารามิเตอร์ q, category, limit และ offset คืนค่ายอดรวมที่แท้จริงและการกระจายตัวฟาเซตควบคู่ไปกับแต่ละหน้า และเปิดใช้ CORS GET /api/v1/papers?q=optimal+execution&category=q-fin.TR เป็นคำสั่งบรรทัดเดียวจากที่ไหนก็ได้ เอนด์พอยต์เดียวกันนี้ขับเคลื่อนหน้า /papers ของเว็บไซต์เอง — เบราว์เซอร์ก็เป็นแค่ไคลเอนต์ API อีกตัวหนึ่ง

ล้มเหลวอย่างซื่อสัตย์

แบ็กเอนด์ค้นหาที่โกหกแย่ยิ่งกว่าตัวที่ล่ม เราจึงวางจุดยืนอย่างจงใจว่าจะเกิดอะไรขึ้นเมื่อ Meilisearch เข้าถึงไม่ได้ ชั้นข้อมูล โยน error เมื่อล้มเหลวแทนที่จะคืนผลลัพธ์ว่างเปล่าเงียบ ๆ — แล้วให้ผู้เรียกตัดสินใจว่าจะจัดการอย่างไร สำหรับชุดข้อมูลที่ยังคงเก็บสำเนาไว้ในหน่วยความจำ tool จะถอยกลับไปใช้ .filter() ธรรมดาบนสำเนานั้น เว็บไซต์จึงยังคงทำงานได้ ส่วน papers ที่ Meilisearch คือ แหล่งความจริงและไม่มีสำเนาชุดที่สอง tool และ API จะคืน error ที่ชัดเจน (API ตอบกลับด้วย 503) แทนที่จะให้บริการข้อมูลที่ล้าสมัยหรือไม่ครบถ้วน การเรียกค้นหาแต่ละครั้งมี timeout สั้น ๆ เพื่อไม่ให้ดัชนีที่ค้างทำให้ tool ค้างตามไปด้วย หลักการคือ: เสื่อมประสิทธิภาพอย่างดัง ๆ อย่าเงียบ ๆ แล้วคืนคำตอบที่ผิดกลับไป

ข้อมูลเข้ามาได้อย่างไร

คลังข้อมูลถูกป้อนด้วยไปป์ไลน์ของ scraper ที่ทั้งหมดรันกับแหล่งข้อมูลสาธารณะที่ใช้ได้ฟรี

• Papers มาจาก Atom API ของ arXiv ตัว harvester ดึงคลัง q-fin ทั้งหมดมาเป็น JSONL ขั้นตอน build ยูเนียนมันเข้ากับชุดที่คัดสรรแล้ว (กำจัดข้อมูลซ้ำด้วย arXiv id ผสานข้อมูลที่มา) และส่งผลลัพธ์ไปยัง indexer นอกจากนี้ harvester ยังมีโหมด "enrich id เฉพาะเหล่านี้" สำหรับเริ่มต้นจากรายการอ่านภายนอก
• Code คือการ crawl repository บน GitHub ที่เกี่ยวข้องกับควอนต์ จับข้อมูลพร้อม metadata ที่สำคัญต่อการกรอง — ดาว fork ภาษาหลัก topic และจำนวนไฟล์ Python กับโน้ตบุ๊ก
• Articles ถูก scrape จากบล็อกควอนต์และตัวรวบรวมข่าว โดยมิเรอร์ฉบับที่ดีกว่าไว้ในเครื่องเพื่อให้มันรอดจากการที่ลิงก์เสื่อมสภาพ หน้าแรกจะระบุว่าบทความใดที่เราบันทึกสำเนาในเครื่องไว้
• Strategies คือสคริปต์ Pine บน TradingView พร้อม metadata ของมัน — ผู้เขียน หมวดหมู่ แท็ก ไลก์ และว่ารายการนั้นมีโค้ด ชาร์ต หรือบทวิเคราะห์หรือไม่
• Videos ทำดัชนีช่อง YouTube ที่เกี่ยวข้องเพื่อให้ทอล์กและวิดีโอสาธิตค้นพบได้ควบคู่ไปกับเนื้อหาที่เป็นตัวหนังสือ

การทำดัชนีใหม่ในระบบ production รันผ่านอุโมงค์ SSH ไปยัง Meilisearch ที่ผูกกับ localhost เพราะเอนจินนี้ไม่เคยถูกเปิดเผยสู่อินเทอร์เน็ตเลย ลูปทั้งหมด — harvest, build, deploy, index — ถูกออกแบบให้รันซ้ำแบบ idempotent ได้ ซึ่งก็คือสิ่งที่ cron รายวันทำเป๊ะ ๆ

การเข้าถึงและการโฮสต์

researcher รันบน Server 1 ของเราในรูปสแต็ก Docker Compose ขนาดเล็ก: คอนเทนเนอร์ Next.js อยู่หลัง Traefik และคอนเทนเนอร์ Meilisearch ที่ผูกกับ localhost แอป Next.js อ่านชุดข้อมูลของมันฝั่งเซิร์ฟเวอร์และสื่อสารกับ Meilisearch ผ่านเครือข่ายภายใน

การเข้าถึงถูกคุมผ่าน auth.marketmaker.cc ซึ่งเป็นบริการระบุตัวตนที่ใช้ร่วมกันของเรา โทเคนเป็น JWT แบบ RS256 ที่ตรวจสอบกับ JWKS ของบริการ auth — ทุกการตัดสินใจอนุญาตสิทธิ์จะตรวจลายเซ็น (พร้อมการตรวจ issuer และอัลกอริทึมอย่างเข้มงวด และล้มเหลวแบบปิดหากเข้าถึงเอนด์พอยต์คีย์ไม่ได้) ส่วนเส้นทางถอดรหัสแบบไม่ตรวจสอบจะใช้เฉพาะกับ UI เชิงรูปลักษณ์เท่านั้น เช่นการแสดงอีเมลของคุณในแถบนำทาง บริการ auth ออกบทบาทแยกตามแต่ละบริการ บน researcher นั้นบทบาท admin คุมพื้นที่แอดมินภายใน (ที่เรารันและติดตามตรวจสอบ scraper) ส่วนหน้าแรกสาธารณะไม่ต้องใช้โทเคนใด ๆ เลย มันคือโครงสร้าง auth เดียวกันที่อยู่หน้าเครื่องมือภายในอื่น ๆ ของเรา ดังนั้นล็อกอินครั้งเดียวจึงใช้ได้ทั่วทั้งระบบนิเวศ

มันอยู่ตรงไหนในสแต็ก Marketmaker

researcher คือโครงสร้างพื้นฐาน ไม่ใช่จุดหมายปลายทาง ประเด็นไม่ได้อยู่ที่ตัวเว็บไซต์ — แต่อยู่ที่ตอนนี้เรามีมุมมองที่ สอบถามได้ ของวงการนี้ที่ทั้งคนและเอเจนต์ใช้ร่วมกัน

สำหรับเราในฐานะมนุษย์ มันคือที่มาของบล็อกนี้ส่วนใหญ่เลย เมื่อเรารีวิวเครื่องมืออย่าง VectorBT หรือผ่าเฟรมเวิร์กอย่าง TradingAgents หรือ Fincept Terminal จุดเริ่มต้นมักเป็นการค้นหาทั่ว researcher: เครื่องมือนี้ต่อยอดจากเปเปอร์ใด มี repo อื่นใดบ้างที่แก้ปัญหาเดียวกัน ใครเขียนถึงมันบ้าง คลังข้อมูลคือกรวยกรอง บล็อกโพสต์คือสิ่งที่ร่วงออกมาจากมัน

สำหรับ เอเจนต์ AI ของเรา มันคือบางสิ่งที่เป็นเชิงโครงสร้างมากกว่านั้น ฐานรองงานวิจัยที่เข้าถึงได้ผ่าน MCP หมายความว่าเอเจนต์ที่ทำงานด้านกลยุทธ์ไม่ต้อง scrape arXiv แบบสด ๆ ไม่ต้องสลับสับเปลี่ยน API สี่ตัว หรือเดาว่าข้างนอกมีอะไรอยู่บ้าง — มันแค่เรียก search_papers, search_repos, search_pine กับคลังข้อมูลที่รวมศูนย์ กำจัดข้อมูลซ้ำ และทำดัชนีไว้แล้ว นั่นคือทิศทางเดียวกันกับเครื่องมือสั่งการและปฏิบัติงาน (cmdop) และเครื่องมือเอเจนต์ของเรา: มอบ tool ที่มีไทป์ชัด อ่านอย่างเดียว และมีเอกสารครบถ้วนให้เอเจนต์ใช้กับข้อมูลจริง ล้มเหลวอย่างดัง ๆ เมื่อแบ็กเอนด์ใช้งานไม่ได้ และให้แบ็กเอนด์ที่ใช้ร่วมกันหนึ่งตัวให้บริการทั้ง UI ของมนุษย์และอินเทอร์เฟซของเครื่องจากดัชนีชุดเดียวกันเป๊ะ มนุษย์เปิดเรียกดูและเอเจนต์สอบถาม — แต่ทั้งคู่กำลังมองคลังข้อมูลเดียวกัน และนั่นแหละคือแก่นของไอเดียทั้งหมด

บทสรุป

researcher เริ่มต้นจากการเป็นทางแก้ปัญหาเล็ก ๆ ที่น่ารำคาญ — ที่งานวิจัยควอนต์กระจัดกระจายอยู่ในสี่ที่ที่ไม่คุยกัน — แล้วกลายเป็นสิ่งที่เราพึ่งพาทุกวัน ราว ๆ 51,000 เอกสารกระจายอยู่ใน papers, code, articles และ strategies ทั้งหมดอยู่เบื้องหลังเสิร์ชเอนจินข้อความเต็มเพียงตัวเดียว ทั้งหมดเข้าถึงได้ทั้งโดยมนุษย์ที่มีเบราว์เซอร์และโดยเอเจนต์ที่มีไคลเอนต์ MCP มันจงใจไม่หรูหรา: ค้นหาข้อความเต็ม ไม่ใช่ embedding แหล่งความจริงหนึ่งเดียว ไม่ใช่แคชเจ้าเล่ห์ tool ที่โยน error อย่างซื่อสัตย์ ไม่ใช่ tool ที่กลบเกลื่อนเหตุล่ม

หากคุณกำลังสร้างเอเจนต์สำหรับงานวิจัยการเทรด บทเรียนนี้ใช้ได้เกินกว่าคลังข้อมูลเฉพาะของเรา: สิ่งที่ให้แรงงัดสูงสุดที่คุณมอบให้เอเจนต์ได้ไม่ใช่โมเดลที่ใหญ่กว่า แต่เป็นมุมมองข้อมูลที่สะอาด รวมศูนย์ และสอบถามได้ของข้อมูลที่มันต้องการ — เปิดเผยผ่านดัชนีชุดเดียวกันกับที่มนุษย์ไว้วางใจ และนั่นแหละคือสิ่งที่ researcher เป็น