Search as Code ให้ตัวโมเดลเป็นผู้ตัดสินใจว่าจะค้นข้อมูลอย่างไร แทนที่จะให้เสิร์ชเอนจินจัดการทั้งหมด เจ้าของแนวคิดนี้คือ Perplexity บริษัทเสิร์ชเอนจิน AI ที่เพิ่งประกาศนำมาใช้เป็นโครงสร้างใหม่ของระบบค้นหาทั้งบริษัท และเรียกย่อว่า SaC

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

เวลาสั่ง AI ให้หาข้อมูลที่ต้องค้นหลายรอบ มักเจอปัญหาเดิมๆ ทั้งใช้เวลานาน ค่าใช้จ่ายบานปลาย และมีข้อมูลที่ไม่เกี่ยวปะปนจนคำตอบเพี้ยน ระบบนี้ตั้งใจแก้ปัญหาเหล่านั้น ในงานทดสอบจริงที่ให้ไล่ช่องโหว่ความปลอดภัยกว่า 200 รายการ วิธีใหม่ใช้ token หรือหน่วยนับข้อความที่ใช้คิดเงิน ลดลง 85.1% เทียบกับวิธีเดิม โดยคำตอบยังถูกต้องเต็ม 100%

แนวคิดแบบนี้ไม่ได้ใช้ได้แค่กับการค้นหา แต่ยังเป็นตัวอย่างของการให้โมเดลที่คิดเองได้ทำงานร่วมกับโค้ดที่ให้ผลแน่นอนตายตัว

ระบบค้นหาแบบเดิมบังคับให้ AI ค้นทีละรอบ

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

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

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

ข้อมูลที่ได้ไม่พอดีกับงาน โมเดลไวต่อคุณภาพและความกระชับของ context ซึ่งก็คือกองข้อมูลที่มันต้องอ่านก่อนตอบ ถ้างานต้องการข้อมูลชิ้นเดียวแบบเจาะจง แต่ระบบมีให้แค่ช่องค้นที่ออกแบบมาให้กวาดของมาเยอะไว้ก่อน ของที่ไม่เกี่ยวก็ไหลเข้ามาทั้งกอง กลับกัน ถ้างานต้องการข้อมูลหลายชิ้นที่ต้องใช้วิธีค้นคนละแบบ โมเดลก็ถูกบังคับให้เรียกขั้นตอนชุดเดิมซ้ำๆ ทีละรอบ ต้นทุนบานและ context รก

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

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

การวนกลับไปให้โมเดลคิดใหม่ทุกขั้นตอนคือหัวใจของ agent loop ที่ทำให้ agent ทำงานเองจนจบได้ แต่เมื่อทำงานที่ต้องค้นข้อมูลเยอะ จุดนี้ก็ทำให้เสียทั้งเวลาและเงิน

ข้อจำกัดพวกนี้แก้ไม่ได้เลยในยุคของ function calling กับ MCP ซึ่งเป็นสองวิธีมาตรฐานที่ให้ AI เรียกเครื่องมือภายนอกทีละคำสั่ง เพราะการค้นทุกครั้งต้องวิ่งกลับไปหาโมเดลใหม่หนึ่งรอบเสมอ คนออกแบบระบบจึงเลือกยัดทุกอย่างไว้ในชุดขั้นตอนสำเร็จรูปก้อนเดียว เพื่อให้จบงานได้มากที่สุดในหนึ่งรอบ

สามชั้นที่ทำให้ Search as Code ทำงานได้

SaC ไม่ใช่แค่การนำ search API หรือคำสั่งค้นหาแบบเดิมมาใส่ไว้ในโปรแกรมรันโค้ด แต่รื้อระบบค้นหาออกเป็นชิ้นส่วนย่อยก่อน แล้วค่อยเปิดให้โมเดลหยิบมาต่อกันเอง โครงสร้างมีสามชั้นที่ต้องมีครบถึงจะได้ผล

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

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

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

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

ทีมงานเทียบภาษาที่จะใช้รัน SDK ทั้ง Python · Rust · TypeScript · Bash แล้วเลือก Python เพราะมีไลบรารีสำหรับประมวลผลข้อมูลให้เลือกใช้มากที่สุด และการทดสอบภายในยืนยันตามนั้น ส่วนขั้นตอนค้นหาสำเร็จรูปแบบเดิมยังอยู่ใน SDK ในฐานะทางลัดสำหรับงานที่เจอบ่อย แต่ไม่ใช่ทางเลือกเดียวอีกต่อไป โมเดลจะหยิบมาใช้หรือข้ามไปเลยก็ได้

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

โจทย์ไล่ CVE กว่า 200 รายการ ใช้ token ลดจาก 288.7K เหลือ 42.9K

โจทย์ในชุดทดสอบภายในข้อหนึ่งคือให้ agent ไล่ระบุและอธิบายช่องโหว่ความปลอดภัยระดับความรุนแรงสูงกว่า 200 รายการ ระหว่างปี 2023 ถึง 2025

ความโหดอยู่ที่เงื่อนไขการอ้างอิง แต่ละรายการต้องอ้างประกาศเตือนจากผู้ผลิตซอฟต์แวร์เจ้าของสินค้าเองเท่านั้น ต้องระบุชื่อผลิตภัณฑ์และเวอร์ชันที่แก้ช่องโหว่แล้ว และต้องจับคู่เวอร์ชันนั้นกับรหัส CVE ของช่องโหว่ให้ตรงกัน

โค้ดที่โมเดลเขียนออกมาแบ่งได้เป็นสามท่อนหลัก ท่อนแรกเป็นการวางแผนล้วนๆ โปรแกรมเขียนกฎเรื่องแหล่งข้อมูลลงไปในแผนการค้นหาตั้งแต่ต้น คือรับเฉพาะรูปแบบประกาศที่มาจากผู้ผลิตเอง ส่วนฐานข้อมูลรวมอย่าง NVD หรือ MITRE รวมถึงข่าวและหน้าประกาศของหน่วยงานเฝ้าระวังภัยไซเบอร์ ถูกตัดออกก่อนจะเริ่มดึงข้อมูลด้วยซ้ำ

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

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

ผลที่ออกมาคือคำตอบถูกต้อง 100% ส่วน token ที่ใช้ทั้งงานลดจาก 288.7K เหลือ 42.9K หรือลดลง 85.1% เทียบกับการทำงานแบบเดิมที่ไม่ใช้ SaC ขณะที่ระบบอื่นที่ไม่ใช่ของ Perplexity ทำโจทย์ข้อนี้ได้ต่ำกว่า 25% ทุกตัว

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

ตัวเลขจากชุดทดสอบทั้งห้า SaC ชนะสี่ แพ้หนึ่ง

ตัวเลขทั้งหมดนี้มาจากการวัดของ Perplexity Research ซึ่งเป็นทีมวิจัยของบริษัทเอง โดยนำ 5 ระบบมาทดสอบกับชุดทดสอบ 5 ชุด คะแนนเต็มคือ 1 และยิ่งสูงยิ่งดี ระบบที่เอามาเทียบคือ Perplexity ที่ใช้ SaC · OpenAI Responses API · Anthropic Managed Agents · Exa Agent · Parallel Tasks

SaC ทิ้งห่างระบบอื่นมากที่สุดในชุด WANDR โดยนำระบบรองลงมาราว 2.5 เท่า แต่คะแนน 0.386 ก็บอกอีกอย่างว่างานประเภทนี้ยังยากสำหรับทุกระบบรวมถึงตัวมันเองด้วย ส่วนอีกสองชุดที่ไม่ได้อยู่ในตาราง SaC ชนะ WideSearch ที่ 0.651 และแพ้อยู่ชุดเดียวคือ HLE ที่ได้ 0.612 เทียบกับ 0.614 ของ OpenAI ซึ่งถือว่าเสมอกันในทางปฏิบัติ

การเปรียบเทียบอีกชุดที่ตัดตัวแปรอื่นออกไปได้ คือการวัด SaC กับระบบค้นหาแบบเดิมบนโครงสร้างพื้นฐานชุดเดียวกันของ Perplexity เอง ผลคือ DSQA ขยับขึ้น 19.77 จุด หรือ 29% และ WANDR ขยับขึ้น 12 จุด หรือ 45%

การทดสอบต้นทุนใช้ DSQA กับ WideSearch โดยไล่ระดับการคิดของโมเดลตั้งแต่ต่ำถึงสูง ที่ระดับกลาง SaC ทำคะแนนดีกว่าทุกระบบที่ไม่ใช่ SaC โดยมีต้นทุนต่ำกว่า 1 ดอลลาร์ต่องาน และที่ระดับต่ำสุดก็ยังถูกกว่าทุกระบบที่เอามาเทียบ

Search as Code บอกอะไรเกี่ยวกับอนาคตของเครื่องมือ AI

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

รายละเอียดหนึ่งที่ยืมไปใช้กับงานตัวเองได้เลยคือวิธีสอนโมเดลให้ใช้ของใหม่เป็น เพราะ SDK ที่สร้างขึ้นเองไม่เคยอยู่ในข้อมูลที่โมเดลเรียนมาก่อน ทีมงานจึงเขียน Agent Skill ซึ่งเป็นไฟล์คู่มือสำหรับสอน AI ให้ทำงานเฉพาะทาง แล้วคุมขนาดไฟล์หลักไว้ไม่ให้เกิน 2000 token

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

ตอนนี้ SaC เริ่มใช้งานจริงแล้วผ่าน Perplexity Computer และ Agent API เป็นสองทางแรก

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

---

ที่มา: บทความ Rethinking Search as Code Generation จาก Perplexity Research