Tool: batch_browse — อ่านหลาย URL ในคำเรียกเดียว ด้วยสถาปัตยกรรม 2 เฟสที่กัน LLM ชนกัน
batch_browse อ่านเนื้อหาจากหลาย URL ในครั้งเดียว แล้วส่งผลลัพธ์กลับมาเป็นชุด เหมาะเมื่อ agent ต้องเปรียบเทียบหลายแหล่งหรือเก็บข้อมูลตามรายการลิงก์ที่มีอยู่แล้ว
Tool นี้คืออะไร
รับรายการ URL (สูงสุดตาม config, ดีฟอลต์ 8) แล้วดึง+สรุปทั้งหมดในการเรียก tool ครั้งเดียว คืนสรุปรวมกลับมา — docstring บอกตรงๆ ว่าใช้แทนการเรียก browse_url ทีละตัวเมื่อมี URL list อยู่แล้ว (เช่นจาก fetch_sitemap หรือผลค้นเว็บ)
ปัญหาที่แก้: “LLM thread pile-up”
คอมเมนต์ในซอร์สระบุปัญหาที่ทีมพัฒนาเจอตรงๆ: ถ้าดึง URL หลายตัวพร้อมกันและสรุปแต่ละตัวพร้อมกันด้วย (ทำทุกอย่างในเธรดขนานเดียวกัน) ปัญหาคือ MLX server ที่รันโมเดลในเครื่องรับคำขอได้ทีละคำขอเท่านั้น ถ้ายิงคำขอสรุปพร้อมกันหลายเธรด คำขอเหล่านั้นจะแค่ต่อคิวรอกันที่ตัวเซิร์ฟเวอร์ ไม่ได้เร็วขึ้นจริง แถมเธรดที่รอคิวอยู่กินหน่วยความจำเปล่าประโยชน์
สถาปัตยกรรม 2 เฟสที่แยกชัดเจน
ทางแก้คือแบ่งงานเป็น 2 เฟสที่มีลักษณะต่างกันโดยสิ้นเชิง:
- เฟส 1 (ขนาน): ดึง HTTP เท่านั้น ไม่มีการเรียก LLM ในเธรดเลย — ใช้
ThreadPoolExecutorดึงหลาย URL พร้อมกันได้จริง เพราะ network I/O เป็นคอขวดที่ทำขนานได้อย่างปลอดภัย ไม่มี resource ตัวไหนที่ใช้ทีละคำขอเท่านั้น - เฟส 2 (เรียงคิว): สรุปด้วย LLM ทีละ URL ตามลำดับ — ไม่มีเธรดค้างรอคิวที่ตัวโมเดล
การแยกเป็น 2 เฟสชัดเจนแบบนี้ทำให้ได้ความเร็วสูงสุดจากส่วนที่ขนานได้จริง (HTTP) โดยไม่สร้างปัญหาที่ส่วนที่ขนานไม่ได้จริง (LLM)
ข้าม cache hit ทั้งสองเฟส — ไม่นับ web counter ด้วย
ก่อนเข้าเฟสไหนเลย ระบบเช็ค cache ของแต่ละ URL ก่อน — URL ที่มี cache อยู่แล้ว (ทั้ง raw และสรุปตรง query) จะถูกแยกออกจากรายการที่ต้อง fetch ทันที ไม่เสียเวลาทั้งสองเฟส และไม่นับเข้าโควตาการเรียกเว็บต่อ turn (ต่างจาก URL ที่ fetch จริงซึ่งนับทุกครั้งที่ fetch สำเร็จ) — ผลลัพธ์สุดท้ายรวม cache hit กับผลลัพธ์ที่เพิ่ง fetch เข้าด้วยกันตามลำดับเดิมของ URL ที่ส่งมา ไม่สลับที่
ทำไมเรื่องนี้ถึงสำคัญ
batch_browse เป็นตัวอย่างที่ชัดเจนของการออกแบบตาม constraint จริงของระบบ ไม่ใช่ตามสัญชาตญาณทั่วไป — สัญชาตญาณทั่วไปอาจบอกว่า “ขนานทุกอย่างให้เร็วที่สุด” แต่เพราะ local LLM server รับคำขอได้ทีละคำขอ การขนานส่วน LLM จึงไม่ได้ประโยชน์อะไรเลยและยังเสียทรัพยากรเพิ่ม ทีมพัฒนาจึงแยกวิเคราะห์ว่าส่วนไหนขนานได้จริง (HTTP) ส่วนไหนขนานไม่ได้จริง (LLM บน local server) แล้วออกแบบ pipeline ให้ตรงกับข้อจำกัดจริงของแต่ละส่วน
ความคิดเห็น
กำลังโหลดความคิดเห็น...