AbsenceBench: โมเดลภาษายังระบุข้อมูลที่หายไปไม่ได้

 (arxiv.org)
1 คะแนน โดย GN⁺ 2025-06-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โมเดลภาษาขนาดใหญ่ (LLM) ค้นหาข้อมูลเฉพาะในอินพุตยาวได้ดี แต่ยังมีข้อจำกัดในการระบุข้อมูลที่หายไป
  • เกณฑ์ทดสอบ AbsenceBench ใหม่ ประเมินความสามารถของ LLM ในการตรวจจับข้อมูลที่ขาดหายไปใน 3 โดเมน ได้แก่ ลำดับข้อมูล บทกวี และ GitHub PR
  • แม้แต่โมเดลล่าสุดอย่าง Claude-3.7-Sonnet ก็ยังทำผลงานได้ต่ำ โดยได้เพียง 69.6% F1-score ในบริบทขนาด 5K โทเค็น
  • สาเหตุคือข้อจำกัดที่กลไก attention บนพื้นฐาน Transformer ไม่สามารถทำงานกับ 'ช่องว่าง' ในเอกสารได้อย่างมีประสิทธิภาพ
  • งานวิจัยนี้แสดงให้เห็นถึงความแตกต่างเชิงพื้นฐานด้านความยากระหว่าง การตรวจจับข้อมูลที่ถูกแทรก กับ การตรวจจับข้อมูลที่หายไป ของ LLM

ภาพรวม

  • โมเดลภาษาขนาดใหญ่ (LLM) มีพัฒนาการด้านการค้นหาข้อมูลในเอกสารยาวดีขึ้นอย่างมาก
  • การทดสอบ ‘Needle in a Haystack (NIAH)’ แบบเดิมใช้ประเมินความสามารถในการหาข้อมูลที่ซ่อนอยู่ในอินพุตยาว และ LLM ทำได้ดีมากในงานนี้
  • แต่การที่ LLM จะสามารถหาว่า ข้อมูลใดหายไปอย่างชัดเจน ได้หรือไม่นั้นเป็นอีกปัญหาหนึ่ง
  • ด้วยเหตุนี้จึงมีการเสนอเกณฑ์ทดสอบ AbsenceBench ซึ่งลบบางส่วนของเอกสารออกอย่างชัดเจน แล้วให้ทายว่าข้อมูลใดถูกลบไป

คำอธิบายเกณฑ์ทดสอบ AbsenceBench

  • AbsenceBench ประเมินความสามารถของโมเดลในการตรวจจับสิ่งที่หายไปใน 3 โดเมน ได้แก่ บทกวี ลำดับตัวเลข และ GitHub Pull Request(PR)
  • ระบบจะป้อนทั้งเอกสารต้นฉบับและฉบับแก้ไขที่ลบบางส่วนออกโดยตั้งใจให้กับ LLM พร้อมกัน แล้วประเมินว่าสามารถระบุข้อมูลที่หายไปได้หรือไม่
  • ถือเป็นเกณฑ์ทดสอบแบบ ‘บริบทระดับกลาง’ ที่มีความยาวบริบทเฉลี่ย 5K โทเค็น ซึ่งสั้นกว่าการทดสอบเอกสารยาวแบบเดิม

ประเด็นสำคัญจากผลการประเมิน

  • มีการประเมินกับ LLM ตัวแทน 14 รุ่น (เช่น GPT-4, Claude-3.7-Sonnet, Gemini-2.5-flash เป็นต้น) และพบว่า แม้แต่โมเดลล่าสุดก็ยังได้ F1-score เพียงราว 69.6% ซึ่งถือว่าต่ำ
  • แม้ LLM จะอยู่ในระดับ ‘เหนือมนุษย์’ แล้วในการทดสอบ NIAH แต่ใน AbsenceBench ประสิทธิภาพกลับ ลดลงอย่างมากถึง 56.9%
  • ยิ่งบริบทยาวขึ้น ประสิทธิภาพก็ยิ่งลดลง โดยเฉพาะในโดเมนบทกวี
  • แม้จะใช้ความสามารถด้าน inference-time compute ประสิทธิภาพก็เพิ่มขึ้นเพียง 7.9% แต่กลับใช้โทเค็น chain-of-thought มากขึ้นเฉลี่ยถึง 3 เท่า
  • ในทางกลับกัน เมื่อ อัตราการละข้อมูล (omission rate) ต่ำลง ประสิทธิภาพของ LLM กลับแย่ลงอย่างน่าประหลาด

สาเหตุและการวิเคราะห์เชิงลึก

  • กลไก self-attention บนพื้นฐาน Transformer ให้ความสนใจกับ ‘ข้อมูลที่หายไป’ หรือช่องว่างได้ยาก เพราะโครงสร้างการ attention แบบอิงคีย์นั้นติดตามข้อมูลที่ไม่มีอยู่จริงได้ยากโดยธรรมชาติ
  • ระหว่างการทดสอบ เมื่อเพิ่ม สตริง placeholder ลงในตำแหน่งที่ข้อมูลหายไป ประสิทธิภาพเพิ่มขึ้นเฉลี่ยมากถึง 35.7%

โครงสร้างและตัวอย่างของ AbsenceBench

  • แต่ละงานถูกกำหนดดังนี้
    • ให้ เอกสารต้นฉบับ (Dorig) และ เอกสารที่แก้ไขแล้ว (Dmodified)
    • สร้าง Dmodified โดยลบองค์ประกอบ p% ออกจาก Dorig จากนั้นเปรียบเทียบทั้งสองฉบับเพื่อให้ LLM สร้างชุดคำตอบว่าข้อมูลใดหายไป (Domit)
  • ตัวอย่างในทั้งสามโดเมน:
    • บทกวี (Poetry) : เลือกบทกวีจาก Gutenberg Poetry Corpus แล้วสุ่มลบบางบรรทัดทีละบรรทัด
    • ลำดับตัวเลข (Numerical Sequences) : ละตัวเลขจากลำดับที่สร้างแบบสุ่มตามความน่าจะเป็นที่กำหนด
    • GitHub PRs: สุ่มลบบางบรรทัดที่มีการเปลี่ยนแปลงออกจากไฟล์ diff ของ PR โอเพนซอร์สยอดนิยม

ตัวอย่างเทมเพลตการประเมิน (โดเมนบทกวี)

  • system prompt: “นักเรียนท่องบทกวี แต่บางบรรทัดอาจหายไป จงหาว่าบรรทัดใดหายไปอย่างแม่นยำ”
  • ให้ทั้งบทกวีต้นฉบับและฉบับที่ท่อง แล้วกำหนดให้ตอบเฉพาะบรรทัดที่หายไปอย่างถูกต้องเท่านั้น

ผลการทดลองหลัก

  • มีการทดลองโดยปรับความยาวเอกสาร อัตราการละข้อมูล และปัจจัยอื่น ๆ แยกตามแต่ละโดเมน
  • ทั้งใน GitHub PR บทกวี และลำดับตัวเลข LLM ไม่สามารถระบุส่วนที่หายไปได้ครบถ้วน
  • ความแตกต่างหลักระหว่าง NIAH กับ AbsenceBench คือ NIAH เน้นการจับคีย์หรือข้อมูลที่มีอยู่ ขณะที่ AbsenceBench ต้องสนใจกับ ‘ส่วนที่ไม่มีอยู่’ จึงยากกว่าในเชิงโครงสร้าง

บทสรุปและนัยสำคัญ

  • AbsenceBench แสดงให้เห็นว่า LLM ยังเปราะบางต่อคำถามประเภท ‘อะไรหายไป?’
  • สิ่งนี้ชี้ว่าในการใช้งานจริงที่นำ LLM มาเป็นผู้ตัดสิน (เช่น LLM-as-a-Judge) จำเป็นต้องระวังเรื่องความน่าเชื่อถือ
  • จำเป็นต้องมีแนวทางใหม่เพื่อแก้ข้ออ่อนเชิงโครงสร้างของสถาปัตยกรรม Transformer
  • ชุดข้อมูลและโค้ดของ AbsenceBench เปิดเผยสู่สาธารณะแล้ว และถูกเสนอให้เป็นจุดเริ่มต้นสำหรับการวิจัยความสามารถด้านการตรวจจับข้อมูลที่หายไปของ LLM

สรุปผลงานสำคัญ

  • ออกแบบและเผยแพร่เกณฑ์ทดสอบใหม่สำหรับการตรวจจับองค์ประกอบที่หายไปอย่างชัดเจนในเอกสารบริบทระดับกลาง (5K โทเค็น)
  • ประเมิน LLM รุ่นใหม่ 14 รุ่น และยืนยันว่าแม้การตรวจจับข้อมูลที่ถูกแทรกจะเกือบสมบูรณ์ แต่การตรวจจับข้อมูลที่หายไปยังคงยาก
  • แสดงให้เห็นว่าแม้ใช้ inference-time compute ก็ยังมีข้อจำกัดในการเพิ่มประสิทธิภาพจริง
  • ยืนยันปรากฏการณ์ที่ว่าการใส่ placeholder อย่างชัดเจนในตำแหน่งที่หายไปช่วยเพิ่มประสิทธิภาพได้มาก
  • AbsenceBench เป็นกรณีตัวอย่างที่เผยให้เห็นข้อจำกัดพื้นฐานของกลไก attention ใน Transformer

องค์ประกอบของชุดข้อมูล AbsenceBench

  • Poetry: ตัดบทกวีหนึ่งบทให้อยู่ในช่วง 100~1000 บรรทัดเพื่อสร้างเอกสารหลายความยาว และลบบางบรรทัดแยกตามบรรทัด
  • Numerical Sequences: กำหนดตัวเลขแรกแบบสุ่ม แล้วเรียงตัวเลขถัดไปตามกฎหลายแบบ (เพิ่มขึ้น ลดลง สุ่ม ช่วงห่างหลากหลาย) พร้อมลบบางส่วนออก
  • GitHub PRs: เลือกเฉพาะบรรทัดที่มีการเปลี่ยนแปลงจาก diff ยาว 10~200 บรรทัดของ 20 ฮอตรีโพซิทอรีอันดับต้น เพื่อสะท้อนสถานการณ์จริง โดยลบบางส่วนออก

ตัวอย่างการทดสอบจริง

  • ตัวอย่างบทกวี
    • ต้นฉบับ: “And so, to you, who always were / To me, I give these weedy rhymes / In memory of early times...”
    • ฉบับแก้ไข: “And so, to you, who always were / In memory of early times...”
    • คำตอบ: “To me, I give these weedy rhymes”
  • ตัวอย่างลำดับตัวเลข
    • ต้นฉบับ: 117, 121, 125, 129, 133, 137 ...
    • ฉบับแก้ไข: 117, 125, 129, 133 ...
    • คำตอบ: 121, 137
  • ตัวอย่าง GitHub PR
    • มีบางบรรทัดของการเปลี่ยนแปลงโค้ดใน PR ที่ถูกลบออก

การนำไปใช้และความสำคัญเชิงปฏิบัติ

  • ในทางปฏิบัติ เรื่องนี้เกี่ยวข้องโดยตรงกับความสามารถในการตรวจจับการตกหล่นของการเปลี่ยนแปลงใน PR diff หรือการขาดข้อมูลที่จำเป็นในเอกสาร
  • เมื่อนำ LLM ไปใช้กับงานรีวิวหรืองานตรวจสอบอัตโนมัติ การตรวจจับข้อมูลที่หายไปจำเป็นต้องมีมาตรการเสริมแยกต่างหาก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-06-22
ความคิดเห็นจาก Hacker News

  • แชร์ประสบการณ์ที่ดูบรรยายของ Gerald Sussman แล้วนำภาพ Kanizsa triangle ป้อนให้ Claude พร้อมตั้งคำถามคลุมเครือเพื่อทดสอบว่า Claude มองออกหรือไม่ว่าเป็นรูปสามเหลี่ยม โดย Claude ระบุภาพได้อย่างถูกต้องและสรุปได้ด้วย จึงลองหมุนภาพ 90 องศาแล้วทดสอบอีกครั้ง แต่คราวนี้ Claude กลับจำภาพไม่ได้ และยังนับจำนวนองค์ประกอบผิดด้วย สิ่งที่ Claude อธิบายคือ ‘ส่วนโค้งคล้าย Pac-Man สี่ชิ้น สามเหลี่ยมสีดำบาง ๆ หรือรูปร่างคล้ายลูกศรสองอัน และพื้นหลังสีเทาอ่อน’

    • คาดว่าในอนาคตอาจแก้ปัญหานี้ได้ด้วยการเพิ่มภาพทุกภาพในเวอร์ชันที่หมุน 90 องศาเข้าไปในกระบวนการฝึกข้อมูล

    • มีความเห็นว่าเนื้อหาของงานวิจัยจำกัดอยู่ที่เอกสารข้อความ ดังนั้นการทดลอง Kanizsa triangle จึงนำมาใช้กับข้อถกเถียงนี้โดยตรงไม่ได้ พร้อมย้ำว่า LLM ยังพัฒนาเรื่องการประมวลผลภาพได้ไม่มากนัก ความสามารถด้านวิชันส่วนใหญ่เป็นโครงสร้างที่ผ่านการพรีโปรเซสแยกต่างหากเพื่อแปลงเป็นโทเคนก่อนป้อนเข้า transformer และยกตัวอย่างขั้นตอนพรีโปรเซสหลายแบบ เช่น OCR, การรู้จำแพตเทิร์นด้วย CNN, ภาพหลายมุม และภาพที่ขยายแล้ว

    • ชี้ว่ามีความเข้าใจเรื่องการคำนวณไม่เพียงพอ พร้อมแชร์ลิงก์ไปยังกระทู้ Hacker News เก่าและวิดีโอบรรยาย Strange Loop ที่เกี่ยวข้อง ลิงก์, ลิงก์

    • มีความเห็นว่าถ้าเอารูปสุนัขที่มีขา 5 ขาให้ LLM ดู มันก็คงนับจำนวนขาไม่ถูก

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

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

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

      Original: {gongtong bubun} {jigeodoen bubun} {gongtong dwitbubun}
Modified: {gongtong bubun} {gongtong dwitbubun}

      และ

      Original: {gongtong bubun} {gongtong dwitbubun}
Modified: {gongtong bubun} {chugadoen bubun} {gongtong dwitbubun}

      ต่างกันไม่มากนัก พร้อมเสนอแนวทางเชิงรูปธรรมว่าอาจใช้ RASP สร้างอัลกอริทึมลักษณะนี้ได้: ขั้นแรกระบุตำแหน่งของโทเคนใน Original/Modified, ขั้นที่สองคำนวณค่าเฉลี่ยของโทเคนแต่ละฝั่งแล้วหาความต่าง, ขั้นที่สามตัดสินว่าโทเคนที่ใกล้กับค่าความต่างมากที่สุดคือ {ส่วนที่ถูกลบ}/{ส่วนที่ถูกเพิ่ม} ประเด็นมีเพียงว่าจะลบค่าจากฝั่งไหนก่อนเท่านั้น หากโมเดลจับการเพิ่มได้ดีแต่จับการลบไม่ได้ อาจหมายความว่า LLM เข้าใจหลักการอยู่แล้ว แต่ยังฝึกกับข้อมูลการลบไม่พอ

    • ชี้ว่าผลการทดลองของโมเดลระดับท็อปล่าสุด (OpenAI opus, o3, Gemini 25 pro ฯลฯ) ไม่ได้ถูกรวมอยู่ในงานวิจัย

    • ตั้งข้อสงสัยว่าสำหรับโมเดลวิชัน อาจฝึกด้วยภาพเนกาทีฟหรือภาพหมุนได้หรือไม่ และกล่าวถึงความเป็นไปได้ที่จะทดลองด้วยวิธี Q/A แบบเติมคำในช่องว่างคล้าย madlib

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

  • มีข้ออ้างว่าตามโครงสร้างของกลไก attention การหาส่วนที่หายไปโดยที่ยังไม่รู้ว่าจะจัดหมวดหมู่อย่างไรนั้นเป็นเรื่องธรรมชาติที่ทำไม่ได้ ปัญหา needle-in-a-haystack ทำงานได้เพราะมีเป้าหมายเฉพาะให้ค้นหา attention จึงทำงานได้ดี แต่กรณี omission นั้นไม่รู้ว่ามีอะไรหายไป จึงต้องเทียบบริบททั้งหมด และ attention layer แบบเดิมมีข้อจำกัด คล้ายกับปัญหาจัดเรียงรายการยาว ๆ

    • มีความเห็นว่าการทดลองหาการตกหล่นนั้นได้ให้ข้อมูลที่ LLM ต้องใช้จริง ๆ อยู่แล้ว (เช่น ทั้งต้นฉบับและฉบับแก้ไข) ดังนั้นนี่เป็นปัญหาด้านการจูนโมเดล ไม่ใช่ข้อจำกัดเชิงสถาปัตยกรรม ตัวอย่างเช่น เวลาหาช่องโหว่ในบทความ ML สมองก็จะเปรียบเทียบเฉพาะบทความ ML ด้วยกัน ไม่ได้ไปเทียบกับความทรงจำไร้สาระอย่าง Star Wars หรือ Top Gear จึงมองว่าการลดขอบเขตของบริบทช่วยให้ทำงานได้อย่างมีประสิทธิภาพ

  • ยังไม่ได้อ่านงานวิจัย แต่เห็นด้วยกับคำอธิบายเรื่องข้อจำกัดของกลไก attention เช่นกัน เพราะ omission คือการไม่รู้ว่ามีอะไรหายไป จึงหาออกได้ยากด้วยวิธีตรงไปตรงมา และต้องอาศัยการเปรียบเทียบบริบททั้งหมด

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

  • เห็นด้วยบางส่วนกับความเห็นของผู้เขียนงานวิจัยที่ว่า LLM ต่างจากมนุษย์ตรงที่เข้าใกล้ตำแหน่งของสิ่งที่หายไปในบริบทไม่ได้เลย แต่ก็สงสัยว่าทำไมในเชิงคณิตศาสตร์สถาปัตยกรรมนี้จึงเหมาะน้อยกว่า พร้อมตั้งคำถามว่าการ fine-tune กับงานลักษณะนี้จะช่วยได้หรือไม่ ผลที่ว่าพอยิ่งอินพุตสั้นและมีส่วนหายน้อยลงยิ่งทำโจทย์ได้แย่ลง ก็ชวนให้นึกว่ามนุษย์เองก็มักสังเกตคำที่หายไปแค่คำสองคำได้ยากเหมือนกัน แม้โมเดลแบบ reasoning จะทำได้ดีกว่า แต่ก็ยังไปไม่ถึงความแม่นยำ 100% ซึ่งน่าประหลาดใจ พร้อมชี้ว่านี่เป็นปัญหาที่โปรแกรมง่าย ๆ แบบในงานวิจัยสามารถแก้ได้ไม่ยาก รู้สึกว่างานวิจัยนี้น่าสนใจเพราะชี้ว่ามีหลายแง่มุมของสติปัญญามนุษย์ที่ยังไม่ถูกนิยามอย่างเป็นทางการ และ LLM อาจอ่อนแอในจุดเหล่านั้น

  • มองว่าการหาความต่างของ literal string เป็นงานที่เหมือนบังคับให้ LLM ทำเลขคณิต คือมีการใช้ความซับซ้อนเกินความจำเป็น กลับกัน การให้ LLM ไล่เรียงเอกสารทั้งหมดแล้วเปรียบเทียบเองแบบ reasoning อาจได้ผลดีกว่า คล้ายกับปรากฏการณ์ที่โจทย์ arithmetic ทำได้ดีขึ้นเมื่อแยกเป็นขั้นตอนย่อย ๆ พร้อมตั้งข้อสังเกตว่าโมเดลที่ผลงานดีอาจเป็นสถาปัตยกรรม MoE (Mixture of Experts) และคาดว่า Gemini Flash ก็น่าจะเป็นโมเดลสาย MoE เช่นกัน

  • หากอนุญาตให้ LLM ใช้วิธีแบบ ‘meta’ ก็อาจแก้ปัญหา omission detection ได้ด้วยการให้เขียนและรันสคริปต์ Python เอง

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

  • แสดงความไม่พอใจกับเบนช์มาร์กเฉพาะจุดนี้ โดยยกตัวอย่างว่าในพรอมป์ตัวอย่าง โมเดล qwq-32b หารายการที่ถูก omitted ได้ครบสมบูรณ์ในการทดลองที่มี 3 รายการ และเชื่อว่าน่าจะแก้โจทย์ 100 รายการได้ดีเช่นกันถ้ามีโทเคนมากพอ จำกัดที่ 5000 โทเคนถือว่าน้อยเกินไปสำหรับ reasoning model และอ้างว่าถ้าให้ทำหลายรอบพร้อมกระบวนการ simplification มากขึ้น ก็จะหาคำตอบได้ถูกต้องเสมอ พร้อมเสนอวิธีการคือโทเคไนซ์เอกสารทั้งหมดแล้วเปรียบเทียบซ้ำ ๆ เพื่อดึงคำตอบ [แชร์ตัวอย่างพรอมป์ทั้งหมด]

    • มีการทดลองเองจริง โดยใช้รายการพาดหัว HN 26 รายการที่ตัดออก 3 รายการแล้วให้ qwq-32b หา ผลคือหาได้ถูกต้องทั้งหมดโดยยังไม่ใช้ถึง 50,000 โทเคน ลิงก์ข้อมูลทดลอง

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

  • เล่าประสบการณ์จริงที่ถาม ChatGPT ว่ามีคำว่า ‘utter love’ อยู่ในบทพูด Hamlet หรือไม่ โดย ChatGPT ตอบว่าได้ตรวจบทพูด Hamlet ทั้งหมดแล้วและไม่มีคำนี้ แต่เมื่อเจ้าตัวค้นต้นฉบับออนไลน์เองกลับเจอทันที พอนำส่วนนั้นไปให้ ChatGPT ดู ก็ยอมรับทันที ขอโทษ และส่งบทพูดทั้งหมดมาใหม่ เป็นประสบการณ์ที่รู้สึกว่า “สุดท้ายแล้วความจำของมนุษย์ยังดีกว่า index ของ ChatGPT”

    • มีการแก้ไขว่าคำตอบที่ถูกต้องคือ Act 2, Scene 1 และผู้พูดคือ Polonius

    • ยอมรับว่า LLM มีความสามารถในการระลึกค้นหาต่ำมากหากไม่มี search loop หรือเครื่องมือช่วย แม้แต่โมเดล 4o ก็ล้มเหลวหากไม่ใช้การค้นหา และต้องมีฟังก์ชัน search จึงจะตอบได้ถูก จึงได้ข้อสรุปว่าความสำคัญของ “การใช้เครื่องมือที่เหมาะกับปัญหาให้ถูกต้อง” กำลังเพิ่มขึ้นเรื่อย ๆ

  • มองว่า LLM อาจตรวจจับการมีอยู่ของสิ่งต่าง ๆ จาก sensory input ได้ในระดับหนึ่ง แต่การตรวจจับ absence นั้นยากกว่าเพราะไม่มี sensory input โดยตรง ต้องอาศัย world model และความคาดหวังที่แข็งแรงมาก จึงเสนอว่านี่อาจเป็นงานทางระบบประสาทระดับสูงที่ยังเป็นความสามารถเฉพาะของสิ่งมีชีวิตมากกว่า LLM

    • LLM อาจมีปัญหาเรื่องความสอดคล้องกันตามการออกแบบ โดยบางส่วนอาศัยการท่องจำง่าย ๆ ขณะที่บางเส้นทางพึ่งพาการจับแพตเทิร์นขั้นสูง

    • ชี้ว่าเมื่อเทียบกับการคิดแบบเรียลไทม์ LLM ให้เหตุผลบนพื้นฐานของความจริงแบบ ‘คงที่และหยุดนิ่ง’ จึงมีข้อจำกัดด้านมิติของเวลาอยู่ด้วย

    • การตรวจจับการหายไปจริง ๆ แล้วสัมพันธ์แนบแน่นกับความจำ เช่น ถ้าปากกาที่เคยวางอยู่บนโต๊ะหายไป สมองจะเปรียบเทียบ sensory input ในอดีต (ความจำว่ามองเห็นปากกา) กับสถานการณ์ปัจจุบันเพื่อรับรู้ถึงการไม่อยู่ของมัน และ ณ จุดนี้ การคิดอาจยังเป็นคุณลักษณะเฉพาะของสิ่งมีชีวิตเท่านั้น