Artificial Analysis เปิด Search Index — เบนช์มาร์กแรกที่วัด "Search API ไหนทำให้เอเจนต์ตอบถูกขึ้น" โดยตรง
ทีมที่สร้างเอเจนต์แทบทุกทีมต้องเลือก Search API สักเจ้ามาต่อกับ web_search — Tavily, Exa, Brave, Firecrawl, Parallel, You.com — แล้วก็เลือกด้วยความรู้สึกกันมาตลอด เพราะไม่มีใครวัดตรง ๆ ว่าเจ้าไหนทำให้ คำตอบสุดท้ายของเอเจนต์ถูกขึ้น เท่าไร
เมื่อ 18 สิงหาคม 2026 Artificial Analysis ปล่อย Search Index ซึ่งเป็นความพยายามแก้ปัญหานี้แบบตรงจุด: เบนช์มาร์กที่ออกแบบเป็น provider-swap comparison — ล็อกโมเดลที่ตอบ ล็อกชุดคำถาม ล็อก agent loop ไว้เหมือนกันหมด แล้ว เปลี่ยนแค่ตัวแปรเดียวคือผู้ให้บริการค้นหา สิ่งที่ได้จึงเป็นค่า “uplift” ที่มาจาก search API ล้วน ๆ ไม่ใช่จากโมเดลที่เก่งกว่า
วิธีวัด: ล็อกทุกอย่าง เหลือตัวแปรเดียว
หัวใจของวิธีการอยู่ที่ค่าคงที่ยาวเหยียดที่ตรึงไว้ทุกรอบการทดสอบ:
- โมเดลที่ตอบและโมเดลที่ตรวจ: GPT-5.6 Luna (medium) ตัวเดียวกันทั้งคู่ ทั้งสามเบนช์มาร์ก
- reasoning effort medium, temperature 0.6, output สูงสุด 127,999 โทเคน
- งบ 25 turn ต่อหนึ่งงาน เรียก tool ได้ไม่จำกัดภายในงบนี้
- เครื่องมือสองตัว:
web_search(วิ่งไปหา provider ที่กำลังทดสอบ) และweb_fetch(ดึงเนื้อหน้าเว็บแบบ text-only, timeout 15 วินาทีต่อหน้า) - ผลค้นหาสูงสุด 10 รายการต่อการค้นหนึ่งครั้ง และโมเดลเห็น payload ดิบของ provider ตามรูปแบบดั้งเดิมของแต่ละเจ้า
- ทั้งหมดรันบน agent harness ของ Artificial Analysis เองชื่อ Stirrup
กติกาที่ควรรู้: เมื่อโมเดลคิดว่าข้อมูลพอแล้วต้องเรียก tool finish เพื่อส่งคำตอบ — ถ้าใช้ครบ 25 turn แล้วยังไม่เรียก finish งานนั้นได้ศูนย์ ซึ่งเป็นการลงโทษ provider ที่ให้ผลค้นหาเยอะแต่ไม่ตรง จนโมเดลวนหาไม่จบ
และมี baseline ชื่อ model_only — ยิงคำถามให้โมเดลตอบเปล่า ๆ ไม่มีเครื่องมือค้นหาเลย ตัวเลขนี้คือเส้นฐานที่บอกว่าคำถามชุดนั้น “ตอบได้จากความรู้ในตัวโมเดล” มากแค่ไหน
สามเบนช์มาร์กที่ประกอบเป็นดัชนี
Search Index คือ ค่าเฉลี่ยถ่วงน้ำหนักเท่ากัน ของเมตริกหลักจากสามชุด:
| เบนช์มาร์ก | ลักษณะ | จำนวน | เมตริก |
|---|---|---|---|
| DeepSearchQA (Google) | คำถามแบบงานวิจัยเชิงลึก ทั้งคำตอบเดี่ยวและชุดคำตอบ | 900 | F1 ที่ตรวจด้วย LLM, pass@1 |
| AA-Omniscience | ถามข้อเท็จจริง 6 โดเมน โดเมนละ 100 ข้อ (ชุดปิด) | 600 | accuracy, pass@1 |
| BrowseComp (OpenAI) | คำถามที่ต้องขุดจากเว็บจริง ๆ ตอบสั้นแบบตรงตัว | 200 | accuracy |
จุดที่ทีมอธิบายไว้ชัดคือ AA-Omniscience ในดัชนีนี้ใช้ accuracy ไม่ใช่ Omniscience Index หรือ hallucination rate เหตุผลตรงไปตรงมา: เบนช์มาร์กเดิมออกแบบมาวัดความรู้ในพารามิเตอร์และความสามารถ “รู้ตัวว่าไม่รู้” แต่พอมี search context ป้อนให้ โมเดลจะ ตอบเสมอ แทบไม่ abstain เลย เมตริกการงดตอบจึงไม่มีความหมายในบริบทนี้
ผู้ให้บริการที่อยู่ในชุดทดสอบมี Brave, Tavily, You.com, Firecrawl, Exa (2 โหมด), Parallel (3 โหมด) และ Keenable (2 โหมด) รวมเป็น 10 ผลลัพธ์ โดยทุกเจ้าตั้ง max_results=10 เท่ากัน ที่เหลือใช้ค่า default ของแต่ละเจ้า
ผลที่รายงาน และข้อสังเกตเรื่องต้นทุน
จากรายงานของ The Decoder ที่อ้างการเปิดตัวของ Artificial Analysis กลุ่มนำคือ Parallel, Exa และ Firecrawl ที่ราว 73–75 คะแนน ขณะที่ baseline แบบไม่มีการค้นหาอยู่ที่ราว 33 และกลุ่มที่มีการค้นหาทั้งหมดกระจายอยู่ในช่วง 65–75
ตัวเลขชุดนี้มาจากการรายงานของสื่อ ไม่ได้ปรากฏบนหน้า methodology ที่เราตรวจสอบโดยตรง — แนะนำให้ดูตารางสดบนเว็บ Artificial Analysis อีกครั้งก่อนใช้ตัดสินใจจริง เพราะดัชนีประเภทนี้ขยับได้ทุกครั้งที่ provider ปรับ index หรือ API
แต่ข้อสังเกตที่มีค่ากว่าอันดับคือเรื่อง ต้นทุน: คุณภาพผลค้นหาที่ดีกว่า ลดค่าใช้จ่ายรวม เพราะเมื่อโมเดลได้ผลตรงตั้งแต่ครั้งแรก มันเผาโทเคนน้อยลง ไม่ต้องวนค้นซ้ำหลายรอบ — ซึ่งหมายความว่า search API ที่ราคาต่อ query ถูกกว่าอาจแพงกว่าเมื่อคิดทั้งบิล และ Artificial Analysis ก็แยกต้นทุนออกเป็นสองก้อนให้ดู (ค่าโมเดล + ค่า search API) พร้อมแยก latency เป็นเวลาโมเดล เวลาค้นต่องาน และเวลาต่อการค้นหนึ่งครั้ง
มุมมอง AI Curator
เบนช์มาร์กนี้แก้ปัญหาที่คนสร้างเอเจนต์เจอทุกวันแต่ไม่ค่อยมีใครพูดถึง: เราวัดโมเดลกันจนละเอียดยิบ แต่ชั้น retrieval ที่ป้อนข้อมูลให้โมเดลกลับไม่มีใครวัด ทั้งที่ในระบบ RAG หรือ deep-research agent จริง ๆ คุณภาพของสิ่งที่ค้นมาได้มักเป็นตัวกำหนดคำตอบมากกว่าความฉลาดของโมเดลเสียอีก การมีวิธีวัดที่ isolate ตัวแปรนี้ได้จึงเป็นของที่ควรมีมานานแล้ว
สิ่งที่ผมคิดว่าสำคัญที่สุดในรายงานนี้ไม่ใช่ว่าใครที่หนึ่ง แต่คือช่องว่าง 33 → 65-75 นั่นคือหลักฐานเชิงปริมาณว่า search tool ให้ uplift ระดับเท่าตัว กับงานประเภทหาข้อเท็จจริง ทีมที่ยังลังเลว่าจะต่อ web search เข้ากับเอเจนต์ดีไหมเพราะกลัวความซับซ้อน มีตัวเลขให้ใช้ตัดสินใจแล้ว ส่วนช่องว่างระหว่างเจ้าที่หนึ่งกับเจ้าท้าย ๆ อยู่ราว 10 คะแนน — ใหญ่พอที่จะไม่ควรเลือกด้วยความเคยชิน แต่ไม่ใหญ่พอที่จะทิ้งเรื่องราคาและ latency
ข้อควรระวังที่ต้องพูดให้ชัด: นี่คือผลบนโมเดลเดียว งานภาษาเดียว และ harness เดียว ทุกอย่างวัดด้วย GPT-5.6 Luna บนคำถามภาษาอังกฤษ ซึ่งไม่ได้บอกอะไรเลยว่า provider เจ้าไหน index เนื้อหาภาษาไทย ได้ครอบคลุมกว่ากัน และนี่คือจุดที่ผมอยากเตือนทีมไทยเป็นพิเศษ — จากประสบการณ์ ความต่างของ coverage ภาษาไทยระหว่าง search API แต่ละเจ้ามัก มากกว่า ความต่าง 10 คะแนนบนเบนช์มาร์กอังกฤษเสียอีก โดยเฉพาะกับเนื้อหาที่อยู่ในเว็บบอร์ด เอกสารราชการ หรือข่าวท้องถิ่นที่ไม่มีใครทำ SEO
คำแนะนำเชิงปฏิบัติของผมคือ ยืม methodology ไป อย่ายืมอันดับมา ของที่มีค่าจริงในหน้านั้นคือ “สูตร” — ล็อกโมเดล ล็อกงาน ล็อกงบ turn แล้วสลับแค่ provider ทำแบบเดียวกันกับคำถามภาษาไทย 50–100 ข้อที่สะท้อนงานจริงของคุณ ใช้เวลาไม่ถึงวันและได้คำตอบที่ตรงกับ use case ของคุณมากกว่าตารางอันดับใด ๆ และอย่าลืมวัด ต้นทุนรวมทั้งบิล ไม่ใช่ราคาต่อ query — บทเรียนเรื่อง “ค้นดีกว่าแล้วถูกกว่า” ในรายงานนี้ ใช้ได้กับทุกภาษา
แหล่งข่าว
อ่านเพิ่มในหมวด งานวิจัย
Anthropic ให้ Claude สร้างชุดข้อมูลที่ดูไร้พิษภัยแต่ทำโมเดลเบี้ยว ซ่อนในเรื่องเลี้ยงผึ้งและมวยปล้ำ จนผ่านระบบตรวจที่คล้ายของจริง
ทีม Alignment ของ Anthropic ให้ Claude ปีนหาชุดข้อมูล fine-tune ที่หลบ monitor ได้ ผลคือซ่อนพฤติกรรมในงานเขียนแนวบทบาทสมมติ และโมเดลที่เทรนแล้วนำไปใช้ในบุคลิกตัวเอง ผลซ้ำได้บน Qwen 3.6 27B แต่การทดลองเอื้อฝ่ายโจมตีมากและไม่ได้สะท้อนโมเดลที่ใช้งานจริง
Memdoor ทำซ้ำ GVS5H ได้: ทีม Qwen3.8-27B ห้าตัวตามทัน Fable 5 บนโจทย์ LiveCodeBench Hard แต่ผู้ทำบอกเองว่า 'เท่า' ไม่ใช่ 'ชนะ'
Memdoor ปล่อย workflow team-solve ที่เขียนวิธี GVS5H เป็น YAML ล้วนและทำคะแนน 9.8/10 บน LiveCodeBench Hard 10 ข้อ เทียบกับ 8.0 ของ Fable 5 แบบเรียกครั้งเดียว แต่ตัวอย่างเล็กและมีข้อจำกัด ส่วนงานวิจัยต้นฉบับชี้ว่าวิธีนี้ไม่ได้ช่วยทุกโมเดล
QwenPU รัน LLM ซ้อนใน LLM ด้วยหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ส่วน bootgpt ทำให้เครื่อง 386 บูตเข้าโมเดลภาษาโดยไม่มี OS
ผู้สร้าง Qwenputer ปล่อย QwenPU เมื่อ 31 ต.ค. รัน stories260K ของ Karpathy บนหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ลดเหลือ 53,000 trace token ต่อหนึ่ง token เรื่องเล่า วันเดียวกัน bootgpt ใส่โมเดล int8 ขนาด 11.5KB ให้บูตบนเครื่อง 386 โดยไม่มี OS