Tool: read_file — สุ่มตัวอย่างเอกสารใหญ่แบบปักหมุดคำที่ query ถามถึงไม่ให้หายไป

เผยแพร่ 12 สิงหาคม 2569

ภาพประกอบ: Tool: read_file — สุ่มตัวอย่างเอกสารใหญ่แบบปักหมุดคำที่ query ถามถึงไม่ให้หายไป

read_file เปิดอ่านเนื้อหาของไฟล์ใน workspace ตามช่วงที่จำเป็น เพื่อให้ agent เข้าใจบริบทก่อนวิเคราะห์หรือแก้ไข โดยไม่ต้องเดาเนื้อหาจากชื่อไฟล์

Tool นี้คืออะไร

อ่านไฟล์ text, code, และเอกสาร PDF/Word/Excel — แปลงเอกสารเป็น markdown, sample เอกสารใหญ่ให้ครอบคลุมทั้งไฟล์, และมีพฤติกรรมพิเศษสำหรับไฟล์โค้ดที่ใหญ่เกินขีดจำกัด ที่ต่างจาก read_file ของ AGENT LITE อย่างชัดเจน

ไฟล์โค้ดใหญ่: คืน “structure map” ไม่ใช่ sample เนื้อหา

จุดต่างสำคัญที่สุด: ถ้าไฟล์เป็นโค้ด (.py, .js, .go ฯลฯ) และยาวเกินขีดจำกัด ระบบไม่สุ่มตัวอย่างบรรทัดเหมือนเอกสารทั่วไป แต่สกัดโครงสร้างของไฟล์ ออกมาแทน — สแกนหาบรรทัดที่ประกาศ def, class, function, const ฯลฯ แล้วคืนเป็นรายการ signature พร้อมเลขบรรทัด:

[bash.py — 697 lines, structure map only]

imports:
  from __future__ import annotations
  import os

symbols:
  def bash(command, timeout=30)                                          :648
  def _build_sandbox_profile(workspace, extra_write_paths=())            :12

Use grep or bash to read specific sections by line number.

เหตุผลชัดเจน: สำหรับไฟล์โค้ด การเห็นภาพรวมของฟังก์ชัน/คลาสทั้งหมดพร้อมเลขบรรทัดมีประโยชน์กว่าการเห็นเนื้อหาสุ่มบางส่วน — โมเดลรู้ทันทีว่ามีอะไรอยู่ตรงไหน แล้วใช้ grep หรือ bash (sed -n) อ่านเฉพาะส่วนที่ต้องการต่อ แทนที่จะได้ code fragment สุ่มๆ ที่อาจตัดกลางฟังก์ชันจนอ่านไม่รู้เรื่อง

เอกสาร (PDF/Word/Excel): sample แบบปักหมุดโครงสร้าง + คำที่ query ถาม

สำหรับเอกสารที่ไม่ใช่โค้ด ใช้ _sample_coverage ที่ซับซ้อนกว่าการสุ่มบรรทัดธรรมดา — มีการปักหมุด (pin) เนื้อหาที่ต้องรอดจากการสุ่มเสมอ 2 ประเภท:

  1. โครงสร้างเอกสาร — หัวข้อ markdown (#) และแถวหัวตาราง (บรรทัดที่อยู่เหนือ separator แบบ | --- |) เพื่อไม่ให้ตัวอย่างที่สุ่มมาเป็นข้อมูลที่ไม่มี label กำกับ
  2. คำที่ query ถามถึง — ถ้าโมเดลส่ง user_query มาด้วย (เช่น “ค่าธรรมเนียมเท่าไร”) ระบบดึงคำสำคัญจาก query แล้วปักหมุดบรรทัดที่มีคำเหล่านั้นให้รอดจากการสุ่มเสมอ (จำกัดงบไว้ที่ 40% ของพื้นที่ทั้งหมด กันไม่ให้หน้าที่มีคำนั้นเยอะแย่งพื้นที่จนไม่เหลือให้ coverage ทั่วไป)

ตัวอย่างที่ยกไว้ในคอมเมนต์ตรงๆ: ค่าธรรมเนียมเปอร์เซ็นต์ที่อยู่ที่ตัวอักษรตัวที่ 25,000 ของหน้าเว็บแอปยาว 1.2 ล้านตัวอักษร รอดจากการถูกสุ่มทิ้งได้ เพราะมันตรงกับคำใน query แม้จะอยู่ลึกกลางเอกสารที่การสุ่มแบบสม่ำเสมอทั่วไปมีโอกาสข้ามไปสูงมาก

Sampling รับประกันว่าเนื้อหาไม่ถูกหยุดกลางคัน

อัลกอริทึมคำนวณสัดส่วนการเก็บ (ratio) ให้พอดีกับงบตัวอักษรที่มี รวมค่าใช้จ่ายของ marker [... skipped N lines ...] เข้าไปในการคำนวณด้วย เพื่อไม่ให้การสุ่มหยุดก่อนถึงท้ายเอกสาร — และบังคับเก็บบรรทัดแรกและบรรทัดสุดท้ายเสมอ (หัวและท้ายเอกสารมีข้อมูลสำคัญบ่อยครั้ง) พร้อม cap ความยาวต่อบรรทัดไว้ที่ 2,000 ตัวอักษร กันบรรทัดเดียวที่ยาวผิดปกติ (เช่น minified code) กินงบทั้งหมด

ไฟล์ใหญ่เกิน 5MB ปฏิเสธตรงๆ

ต่างจากการพยายาม sample ไฟล์ทุกขนาด — ถ้าไฟล์ใหญ่เกิน READ_FILE_MAX_BYTES (ดีฟอลต์ 5MB) ระบบปฏิเสธทันทีพร้อมแนะนำให้ใช้ grep/bash อ่านเฉพาะส่วนแทน ไม่พยายาม sample ไฟล์ขนาดนั้นเพราะแม้แต่การอ่านเข้ามาเพื่อ sample ก็มีต้นทุนสูงเกินไป

ไม่ระบุ path มา — แนะนำไฟล์ในเวิร์กสเปซให้แทนการเดา

ถ้าโมเดลลืมส่ง path มา ระบบไม่ error เฉยๆ แต่สแกนหาไฟล์เอกสาร (PDF/Word/Excel) ที่มีอยู่ใน workspace แล้วแสดงรายชื่อให้ พร้อมข้อความชัดเจนว่า “Ask the user which file they mean — do not guess” — ป้องกันโมเดลเดา path มั่วเมื่อไม่แน่ใจ

ทำไมเรื่องนี้ถึงสำคัญ

read_file ของ TH แสดงหลักการsample อย่างฉลาด ไม่ใช่ sample อย่างสุ่มเดา — ทั้ง structure map สำหรับโค้ด และ query-aware pinning สำหรับเอกสาร ล้วนมาจากการสังเกตจริงว่าการสุ่มตัวอย่างแบบเดียวกันไม่เหมาะกับข้อมูลทุกประเภท โค้ดต้องการภาพรวมโครงสร้าง เอกสารต้องการให้ตัวเลข/ข้อเท็จจริงที่ผู้ใช้ถามถึงไม่หายไประหว่างทาง

อ่านเพิ่มเติม

ความคิดเห็น

กำลังโหลดความคิดเห็น...