NEEDLE: เบนช์มาร์ก Search API ที่สร้างคำถามใหม่ทุกชั่วโมงเพื่อกันการปั้นคะแนน — และตัวเลขสดวันนี้บอกว่าไม่มีเจ้าไหนหาเจอเกินครึ่งของที่หาเจอได้

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

NEEDLE เลือกตอบปัญหานี้ด้วยวิธีตรงไปตรงมา: ไม่มีชุดคำถามให้ปั้น เพราะมันสร้างใหม่ทุกชั่วโมง เป็นโปรเจกต์โอเพนซอร์สใต้ MIT จาก Keenable AI รีโป keenableai/needle ถูกสร้างเมื่อ 25 สิงหาคม 2026 และมีคอมมิตล่าสุดวันนี้ (1 ก.ย.) โดยมีสำนักข่าวสายเทคหยิบไปเขียนถึงเมื่อ 31 ส.ค. ตัวรีโปยังเล็กมาก — 19 ดาว 6 fork ณ วันที่เขียน — แต่สิ่งที่มันปล่อยออกมาน่าสนใจกว่าขนาดของมัน เพราะผลทุกรอบถูกเขียนลง gh-pages เป็นไฟล์ JSONL สาธารณะที่ใครก็ดึงไปวิเคราะห์เองได้

กลไก: กติกาเดียวกันทุกเจ้า และเพดานที่คำนวณจากทุกเจ้ารวมกัน

NEEDLE ไม่ใช่เบนช์มาร์กเดียว แต่เป็นห้าตัวที่ใช้อินเทอร์เฟซเดียวกัน (generate แล้ว run) โดยแต่ละตัวสร้าง gold ขึ้นสด ๆ จากแหล่งสาธารณะ และรีโปไม่คอมมิตเฉลยเก็บไว้เลย:

• news — คำถามจากฟีด RSS ที่คัดไว้ราว 124 แหล่ง บวก Google Trends แล้วให้ LLM แปลงเป็นคำค้น โดยปฏิเสธเนื้อหาที่ไม่ผูกกับเวลา ตัดสินด้วย LLM relevance judge สเกล 0–4 แล้วคิดเป็น nDCG@5 พร้อมหักคะแนนถ้ามี URL ซ้ำ — รันทุกชั่วโมง
• finance — คำถามข้อเท็จจริงเกี่ยวกับบริษัทมหาชน เฉลยจาก Wikidata, GLEIF และเอกสาร SEC วัดด้วย answer-recall@K กับ MRR@K แบบ deterministic — รันวันละครั้ง 00:17 UTC
• scholar — หาเปเปอร์ที่รู้ตัวอยู่แล้ว ทั้งค้นจากชื่อเรื่องและค้นจากรายละเอียดที่มีอยู่แต่ในเนื้อเต็ม เฉลยจาก arXiv และ Europe PMC — 12:17 UTC
• legal — หาคำพิพากษาและมาตราใน CFR เฉลยจาก CourtListener และ eCFR — 18:17 UTC
• agentic_rare — คำถามภาษาอังกฤษที่มีคำหายาก สุ่มจากสตรีมคิวรีที่กรองแล้ว — 06:17 UTC

รายละเอียดออกแบบที่ผมคิดว่าทำได้ดีอยู่สามข้อ ข้อแรกคือ --snippet-chars ตัดความยาวหลักฐานให้เท่ากันทุกเจ้า (ดีฟอลต์ 2,000 ตัวอักษร) เพื่อไม่ให้เอนจินที่คืนข้อความยาวกว่าได้เปรียบฟรี ๆ ตอนผู้ตัดสินอ่าน ข้อสองคือทุกเอนจินยิงทีละคำขอ ไม่ยิงขนาน เพื่อให้ตัวเลข latency เทียบกันได้จริง ข้อสามคือค่าเฉลี่ยจะ ข้ามคำถามที่ค้นหรือตัดสินล้มเหลว ไม่ใช่ให้ศูนย์ พร้อมรายงาน search_errors / judge_errors แยกไว้ — ซึ่งสำคัญ เพราะรอบ legal ล่าสุด Bing มี search error ถึง 18 จาก 96 คำถาม ถ้านับเป็นศูนย์คะแนนจะเพี้ยนไปคนละเรื่อง

แต่ตัวเลือกที่ฉลาดที่สุดคือเส้นอ้างอิงที่ชื่อ ultimate — มันไม่ใช่เอนจิน แต่คือ “ผลดีที่สุดของแต่ละ URL หลังรวมผลจากทุกเจ้าแล้วจัดอันดับแบบ oracle” ดังนั้น ultimate ได้ 1.000 เสมอโดยนิยาม และคำถามที่ไม่มีเอนจินไหนหาอะไรที่เกี่ยวข้องเจอเลยจะถูกตัดทิ้ง ผลคือคะแนนของแต่ละเจ้าอ่านได้ว่า “หาเจอกี่เปอร์เซ็นต์ของสิ่งที่หาเจอได้จริงในรอบนั้น” ไม่ใช่เทียบกับความสมบูรณ์แบบในจินตนาการ

ตัวเลขสดรอบล่าสุด: เพดานอยู่ที่ 1.00 แต่ไม่มีใครถึง 0.53

ข้อดีของการที่ผลถูกเขียนลงไฟล์สาธารณะคือเราดึงมาอ่านเองได้ ไม่ต้องเชื่อกราฟในบล็อกประกาศ ต่อไปนี้คือ nDCG@5 จากรอบ news เวลา 10:41 UTC วันที่ 1 ก.ย. 2026 (20 คำถาม ไม่มี error):

เอนจิน	nDCG@5	p50 (ms)	p95 (ms)
ultimate (เพดานรวมทุกเจ้า)	1.000	—	—
keenable	0.521	155	3,963
exa	0.521	1,855	2,098
keenable-realtime	0.516	146	180
brave-llmcontext	0.491	488	615
brave	0.448	472	647
you / perplexity	0.435	458 / 1,437	595 / 1,619
kagi	0.424	1,518	2,087
bing	0.420	1,629	7,643
google (ผ่าน Serper)	0.416	1,002	4,687
parallel	0.400	1,691	2,407
exa-instant	0.373	359	479
firecrawl	0.337	1,299	12,413
tavily	0.235	1,879	2,944
ceramic	0.052	34	219

และรอบ agentic_rare เวลา 08:38 UTC วันเดียวกัน (ตัดสินได้ 89 จาก 100 คำถาม) ลำดับพลิก: exa นำที่ 0.472, keenable-realtime 0.440, brave-llmcontext 0.428, keenable 0.426 — ส่วน google ตกไปอยู่ที่ 0.244 และ bing ที่ 0.180 คือคำถามที่มีคำหายากทำให้เสิร์ชเอนจินกระแสหลักเสียเปรียบชัดเจน

ข้อสรุปที่ใหญ่ที่สุดไม่ได้อยู่ที่ว่าใครชนะ แต่อยู่ที่ ไม่มีใครเกิน 0.53 เลย ทั้งที่เพดาน 1.00 นั้นสร้างจากผลของเอนจินเหล่านี้เองล้วน ๆ พูดอีกอย่างคือ ถ้าคุณต่อเอเจนต์เข้ากับ Search API เจ้าเดียว คุณกำลังทิ้งผลลัพธ์ที่เกี่ยวข้องไปราวครึ่งหนึ่ง — ครึ่งที่เจ้าอื่นหาเจอแต่เจ้าของคุณไม่เจอ

อีกมิติที่ตารางบอกชัดคือ ความเร็วกับความแม่นเป็นคนละแกน ceramic เร็วที่สุดในตาราง (p50 34 ms) แต่ได้ 0.052 คือแทบไม่มีประโยชน์ ขณะที่ firecrawl มี p95 ถึง 12.4 วินาที ซึ่งบนเอเจนต์ที่เรียกเสิร์ชหลายรอบต่องานหนึ่ง หางแบบนั้นคือตัวกำหนดเวลาตอบจริง มากกว่าค่ากลางที่สวยงาม

ข้อที่ต้องอ่านพร้อมกัน: คนทำเบนช์มาร์กอยู่ในตารางด้วย

Keenable AI เป็นผู้ให้บริการ Search API และ keenable กับ keenable-realtime อยู่ในทุกตารางที่มันวัด ยิ่งกว่านั้น ค่าดีฟอลต์ของแฟล็ก --engines ในตัว CLI คือ keenable,exa — คือถ้าใครรันตามที่รีโปเขียนไว้โดยไม่แก้ ก็จะได้เอนจินของเจ้าของเบนช์มาร์กติดมาเป็นค่าเริ่มต้น และผมอ่าน README ทั้งไฟล์แล้ว ไม่พบข้อความเปิดเผยความขัดแย้งทางผลประโยชน์ใด ๆ

ข้อจำกัดอื่นที่ควรถือไว้พร้อมกัน: รอบ news วัดแค่ 20 คำถามต่อรอบ ซึ่งเล็กมาก คะแนนรายรอบจึงแกว่งและไม่ควรอ่านเป็นอันดับถาวร (ข้อดีคือมันรันทุกชั่วโมง จึงดูแนวโน้มข้ามรอบได้) ผู้ตัดสินเป็น LLM ตัวเดียว (ดีฟอลต์คือ openai/gpt-5.6-terra) ซึ่งลำเอียงเท่ากันทุกเจ้าก็จริง แต่ก็ยังเป็นผู้ตัดสินคนเดียว และคำถามทั้งหมดเป็นภาษาอังกฤษ จากแหล่งข่าว-การเงิน-กฎหมายของสหรัฐฯ เป็นหลัก

ที่ต้องให้เครดิตคือ ทั้งหมดนี้ ตรวจสอบได้ โค้ดเป็น MIT, มี DOI บน Zenodo, ผลทุกรอบเขียนลง history.jsonl บน gh-pages และอาร์ทิแฟกต์เต็มถูกเก็บลงชุดข้อมูล keenable-ai/needle-results บน Hugging Face ตารางข้างบนนี้ผมดึงจากไฟล์นั้นตรง ๆ ไม่ได้ลอกจากแดชบอร์ด — และนั่นคือความแตกต่างที่แท้จริงระหว่างเบนช์มาร์กที่วางใจได้กับเบนช์มาร์กที่วางใจไม่ได้ ไม่ใช่ว่าใครเป็นคนรัน แต่คือคุณตรวจซ้ำเองได้หรือเปล่า

มุมมอง AI Curator

เราเพิ่งเขียนถึง Search Index ของ Artificial Analysis เมื่อ 19 ส.ค. ซึ่งวัดคนละแกน — AA ล็อกโมเดลกับงานไว้แล้วสลับเฉพาะ Search API เพื่อดูว่าคำตอบสุดท้ายของเอเจนต์ถูกขึ้นแค่ไหน ส่วน NEEDLE วัดคุณภาพการค้นตรง ๆ ก่อนถึงมือโมเดล ทั้งสองอันจำเป็นและตอบคนละคำถาม แต่ถ้าต้องเลือกอันเดียวไปตัดสินใจซื้อ ผมจะเลือก AA เพราะสิ่งที่ทีมส่วนใหญ่สนใจคือคำตอบสุดท้าย ไม่ใช่ nDCG ของรายการลิงก์ — แล้วใช้ NEEDLE เป็นตัวเช็กว่าอาการที่เห็นใน AA มาจากชั้นค้นหาหรือชั้นโมเดล

ข้อที่ผมคิดว่าทีมไทยควรหยิบไปใช้ทันทีคือ สถาปัตยกรรมของเบนช์มาร์ก ไม่ใช่ผลของมัน เพราะผลทั้งหมดนี้วัดจากคำถามภาษาอังกฤษบนแหล่งข้อมูลอเมริกัน ซึ่งบอกอะไรเกี่ยวกับการค้นข่าวไทย ประกาศราชกิจจานุเบกษา หรือคำวินิจฉัยของศาลไทยได้น้อยมาก — ทีมที่สร้างเอเจนต์ภาษาไทยจะเจอลำดับที่ต่างออกไปแทบแน่นอน แต่แนวคิดหลักลอกได้ทั้งดุ้น: สร้างคำถามใหม่จากฟีดสดแทนการแช่ชุดทดสอบไว้ (RSS ของไทยรัฐ/มติชน/ราชกิจจาฯ ทำหน้าที่เดียวกับฟีด 124 แหล่งของเขาได้), ตัดความยาว snippet ให้เท่ากันก่อนตัดสิน, รันทีละคำขอเพื่อให้ latency เทียบได้, และที่สำคัญที่สุดคือ สร้างเส้น ultimate จากการรวมผลทุกเจ้า เพื่อรู้ว่าเพดานจริงอยู่ตรงไหน ต้นทุนของทั้งหมดนี้คือค่า API กับค่าผู้ตัดสิน LLM ซึ่งถูกกว่าการเลือก vendor ผิดหลายเท่า

ส่วนตัวเลข 0.52 นั้นควรอ่านเป็นข้อเสนอเชิงสถาปัตยกรรมมากกว่าข้อเสนอเชิงจัดซื้อ ถ้าเพดานที่รวมทุกเจ้าเข้าด้วยกันสูงกว่าเจ้าที่ดีที่สุดถึงเท่าตัว คำถามที่ควรถามไม่ใช่ “ควรใช้เจ้าไหน” แต่คือ “ควรยิงกี่เจ้าแล้วรวมผล” — ซึ่งบนงานที่ความถูกต้องสำคัญกว่าค่า API (งานกฎหมาย งานการเงิน งานที่ต้องอ้างอิงได้) คำตอบมักจะมากกว่าหนึ่ง และตารางนี้ยังบอกด้วยว่าควรจับคู่กับใคร: ในรอบ agentic_rare ที่ exa นำ google ตกไปอยู่ท้ายตาราง ส่วนรอบ news ทั้งคู่กลับมาใกล้กัน — ความต่างแบบนั้นแหละคือสิ่งที่ทำให้การรวมผลได้กำไร ไม่ใช่การหาเจ้าที่ดีที่สุดเจ้าเดียว

แหล่งข่าว

• keenableai/needle — โค้ดและเอกสารเบนช์มาร์ก (MIT)
• แดชบอร์ดผลสด NEEDLE
• ชุดข้อมูลผลลัพธ์เต็ม keenable-ai/needle-results บน Hugging Face
• Keenable AI Open-Sources NEEDLE — MarkTechPost, 31 ส.ค. 2026