การออกแบบ การปรับปรุง และการดูแลรักษา Skill ของเอเจนต์ที่ Perplexity

ผลิตภัณฑ์ตัวแทนอัจฉริยะ (agent) ระดับแนวหน้าของ Perplexity สร้างขึ้นบนรากฐานขององค์ความรู้และความเชี่ยวชาญเฉพาะทางที่บรรจุอยู่ใน Agent Skills แบบโมดูลาร์ เราดูแลรักษาคลังข้อมูลของ Skill ที่คัดสรรมาอย่างพิถีพิถันในสภาพแวดล้อมทางเทคนิคของเรา Skill เหล่านี้ประกอบด้วยยูทิลิตี้อเนกประสงค์จำนวนมากที่ขับเคลื่อน Perplexity Computer; ความสามารถเฉพาะด้านในด้านต่าง ๆ เช่น การเงิน กฎหมาย และสุขภาพ; รวมถึงโมดูลจำนวนมากสำหรับตอบสนองความต้องการของผู้ใช้ Skill บางรายการอาจถูกเรียกใช้น้อยครั้งแต่มีความสำคัญอย่างยิ่งเมื่อถูกเรียกใช้ เพื่อให้มั่นใจว่าผู้ใช้จะได้รับประสบการณ์ที่ยอดเยี่ยมอย่างต่อเนื่อง ทีม Agents ของ Perplexity จึงให้ความสำคัญกับคุณภาพของ Skill มากพอ ๆ กับคุณภาพของโค้ด

สัญชาตญาณและแนวปฏิบัติที่ดีที่สุดที่จำเป็นในการพัฒนา Skill คุณภาพสูงนั้นแตกต่างอย่างมากจากสิ่งที่จำเป็นสำหรับการสร้างซอฟต์แวร์แบบดั้งเดิม ทีม Agents ตรวจสอบคำขอพูล (pull request) จำนวนมากจากวิศวกรผู้มีความสามารถซึ่งพัฒนา Skill ระหว่างการทำงาน ผลลัพธ์ที่ได้เกือบจะทุกครั้งคือความคิดเห็นและข้อเสนอแนะมากมายสำหรับการปรับปรุงแก้ไข ทั้งนี้เป็นเพราะรูปแบบที่มีประโยชน์หลายรูปแบบสำหรับการเขียนโค้ดกลายเป็นรูปแบบตรงกันข้าม (antipattern) ในการสร้าง Skill

ตัวอย่างเช่น หากคุณนำคำคมบางส่วนจาก PEP20 – The Zen of Python มาใช้ จะเห็นได้ ย่างรวดเร็วว่าการเขียนโค้ด Python ที่ดีนั้นไม่เหมือนกับการเขียน Skill ที่ดี จากหลักคำสอน 20 บรรทัด อย่างน้อยครึ่งหนึ่งนั้นผิดพลาดโดยสิ้นเชิงหรือทำให้เข้าใจผิดอย่างมากเมื่อเขียน Skill นี่คือ 5 ข้อจากทั้งหมดนั้น:

ความแตกต่างห้าประการระหว่าง Zen of Python และแนวทางของบทความสำหรับการเขียน Skills.

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

Skill คืออะไร?

เมื่อคุณเขียน Skill คุณไม่ได้กำลังเขียนซอฟต์แวร์ธรรมดา ๆ (แม้ว่าปัจจุบัน Skill จะเป็นส่วนหนึ่งของเอนจิ้นตรรกะหลักสำหรับระบบเอเจนต์แล้วก็ตาม) แต่คุณกำลังสร้างบริบทสำหรับโมเดลและสภาพแวดล้อมของพวกมัน Skill มีข้อจำกัดและหลักการออกแบบที่แตกต่างกัน หากคุณเขียน Skill เหมือนที่คุณเขียนโค้ด คุณจะล้มเหลว

Skill ประกอบด้วยสิ่งต่าง ๆ อย่างน้อยสี่อย่าง โดยเฉพาะอย่างยิ่งในบริบทของวิธีที่เราสร้างมันขึ้นมาที่ Perplexity

Skill คือไดเรกทอรี

Skill ไม่ได้เป็นเพียงไฟล์ SKILL.md ไฟล์เดียวเท่านั้น ในหลายกรณี Skill จะประกอบด้วยไฟล์หลายไฟล์ ภายใต้ไดเรกทอรีที่ตั้งชื่อตาม Skill ของคุณ คุณอาจมี:

SKILL.md: frontmatter และคำแนะนำ

scripts/: โค้ดที่เอเจนต์รัน ไม่ใช่สร้างขึ้นใหม่

references/: เอกสารขนาดใหญ่ โหลดตามเงื่อนไข

assets/: เทมเพลต สกีมา และข้อมูล

config.json: การตั้งค่าผู้ใช้สำหรับการรันครั้งแรก

รูปแบบแบบฮับแอนด์สโปกนี้ช่วยให้คุณคงความเฉพาะเจาะจงและความกระชับของ Skill ได้เป็นอย่างดี และยังสามารถใช้โครงสร้างโฟลเดอร์ได้อย่างสร้างสรรค์อีกด้วย บางครั้ง Skill ที่ซับซ้อนเป็นพิเศษจะได้ประโยชน์จากลำดับชั้นหลายระดับเพื่อช่วยให้โมเดลนำทางได้ดีขึ้น สมมติว่า Skill หนึ่งต้องใช้ความรู้ครอบคลุม 300 หัวข้อ ซึ่งสามารถจัดกลุ่มได้เป็น 20 กลุ่มเนื้อหา การเลือกหัวข้อที่ถูกต้องจาก 300 หัวข้ออย่างน่าเชื่อถือยังคงเป็นความท้าทายที่ยังไม่มีคำตอบ แม้แต่สำหรับโมเดลแนวหน้าที่ดีที่สุดในปัจจุบัน นี่เป็นปัญหาการเลือกที่ง่ายกว่ามากสำหรับโมเดลในการมุ่งไปที่หนึ่งใน 20 กลุ่ม มากกว่าการเลือกจาก 15 หัวข้อภายในกลุ่มนั้น

ตัวอย่างหนึ่งของวิธีที่ลำดับชั้นหลายระดับให้คุณค่าคือ ทีมของเราได้ใช้งานการซ้อนทับหัวข้อสามระดับภายใน Skill ที่ขับเคลื่อนความสามารถด้านภาษีเงินได้บุคคลธรรมดาในสหรัฐฯ ของ Computer ในฤดูกาลยื่นภาษีที่ผ่านมา ลำดับชั้นนี้มีความจำเป็นอย่างยิ่งเมื่อพิจารณาถึงความซับซ้อนของกฎหมายภาษี: ในการทดสอบช่วงแรกของเรา การแสดงโฟลเดอร์เดียวที่มีประมวลรัษฎากรของสหรัฐฯ ทั้ง 1,945 มาตราให้โมเดลดู ส่งผลให้ประสิทธิภาพแย่ยิ่งกว่าการไม่โหลด Skill เลยเสียอีก การจัดระเบียบข้อมูลออกเป็นส่วนย่อย ๆ ตามหลักตรรกะจึงเป็นสิ่งจำเป็นสำหรับการรับประกันการทำงานของการอ่านที่มีความแม่นยำสูง

ถึงกระนั้น ลำดับชั้นนี้ก็ไม่ได้มาฟรี ๆ ระดับลำดับชั้นที่เพิ่มขึ้นจำเป็นต้องมีการดูแลรักษา (curation) สถาปัตยกรรมข้อมูลในระดับที่เพิ่มขึ้นเพื่อจัดการกับการอ้างอิงทางอ้อม (indirection) ที่เกิดขึ้น เราได้คิดค้นคู่มืออ้างอิงด่วน ยูทิลิตี้การค้นหาแบบกำหนดเอง และเครื่องมืออื่น ๆ เพื่อสนับสนุนโมเดลในการค้นหาข้อมูลด้วยการอ้างอิงทางอ้อมให้น้อยที่สุด ในกรณีนี้ การทำงานหนักในการดูแลรักษาท้ายที่สุดแล้วก็นำไปสู่ผลลัพธ์เชิงบวก: Skill ที่ช่วยให้โมเดลสามารถทำงานที่เกี่ยวข้องกับภาษีได้มีความสามารถมากกว่าการใช้เครื่องมือทั่วไปเพียงอย่างเดียว

ขยาย

Skill คือฟอร์แมต

Skill คือรูปแบบหนึ่ง ไฟล์ราก SKILL.md หลักต้องมีทั้งชื่อและคำอธิบาย นอกจากนี้ Skill ต้องแมปตรงกับชื่อไดเรกทอรีที่ Skill นั้นอยู่ ชื่อต้องเป็นอักษรตัวพิมพ์เล็กทั้งหมด ไม่มีเว้นวรรค และสามารถใช้ยัติภังค์ได้ คำอธิบายคือทริกเกอร์สำหรับการกำหนดเส้นทาง นี่เป็นจุดที่มักผิดพลาด: คำอธิบายไม่ใช่เอกสารภายในว่า Skill ทำอะไร แต่มันคือชุดคำสั่งสำหรับโมเดลว่าควรโหลด Skill เมื่อใด ดังนั้นคุณจึงมักจะเห็นคำว่า “Load when” ไม่ใช่ “This Skill does” ซึ่งสำคัญเพราะวิธีที่การใช้งานส่วนใหญ่แทรกคำอธิบายลงในบริบทของโมเดล

ภายในส่วน frontmatter ยังมี “depends:” ซึ่งช่วยให้คุณสร้างการพึ่งพา Skill แบบลำดับชั้นได้ และ “metadata:” ซึ่งใช้สำหรับการตรวจสอบและการประเมิน ระบบเอเจนต์ที่แตกต่างกันสามารถกำหนดฟิลด์ frontmatter ของตนเองเพื่อใช้งานเฉพาะสำหรับระบบเหล่านั้นได้ หรืออีกทางเลือกหนึ่ง เมทาดาต้าเฉพาะของ Skill สามารถบรรจุอยู่ในไฟล์กำหนดค่า JSON หรือ YAML เสริมได้ สิ่งนี้เป็นที่ต้องการเมื่อสร้างระบบเอเจนต์ที่จำเป็นต้องอำนวยความสะดวกในการทำงานขณะรันไทม์ที่แตกต่างกันต่อ Skill โดยไม่ทำให้บริบทของโมเดลรกด้วยรายละเอียดปลีกย่อย สุดท้ายแล้ว พฤติกรรมที่คล้ายคลึงกันสามารถทำได้ผ่านการตัด frontmatter ของ Skill ออกเมื่ออ่าน Computer ใช้ระเบียบวิธีนี้ ซึ่งช่วยให้การกำหนดค่าได้รับการเก็บรักษาไว้ในไฟล์ราก SKILL.md จำเป็นต้องใส่ใจในรายละเอียดอย่างระมัดระวังในตรรกะการแยกวิเคราะห์ (parsing logic) และคุณอาจต้องการใช้งานการตัดออกตามเงื่อนไขหากมีฟิลด์บางฟิลด์ที่มีประโยชน์ในการเก็บไว้ภายในบริบทของโมเดล

Skill สามารถเรียกใช้ได้ (Invocable)

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

มีระดับต้นทุนบริบทอย่างน้อยสามระดับในวิธีที่เราใช้งาน Skill ใน Computer โดยมีกระบวนการดังนี้:

Computer เรียกใช้ load_skill(name="...")

Computer คัดลอกไดเรกทอรี Skill ไปยังแซนด์บ็อกซ์การทำงานที่แยกออกมา

Computer โหลดการพึ่งพา (dependencies) โดยอัตโนมัติแบบเรียกซ้ำในแท็ก “depends:”

จากนั้น Computer จะตัด frontmatter ออก ทำให้เอเจนต์มองเห็นเฉพาะส่วนเนื้อหาและไฟล์เพิ่มเติมเท่านั้น

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

Skill มีความก้าวหน้า (Progressive)

Skill มีความก้าวหน้า ใน Computer มีต้นทุนบริบทสามระดับที่แตกต่างกัน และเราต้องแบกรับทั้งสามระดับในขั้นตอนต่าง ๆ:

สามระดับของบริบท Skill: ดัชนี, การโหลด Skill แบบเต็ม และไฟล์อ้างอิงขณะรันไทม์.

Computer สร้างดัชนี Skill ที่มีชื่อและคำอธิบายสำหรับทุก Skill ที่มีอยู่ งบประมาณสำหรับส่วนนี้อยู่ที่ประมาณ 100 โทเค็นต่อ Skill (ยิ่งสั้นยิ่งดี) ที่ต้องจำกัดแค่นี้เพราะคุณต้องจ่ายต้นทุนนี้ในทุกเซสชัน สำหรับผู้ใช้ทุกคน ข้อมูลนี้จะถูกแทรกเข้าไปในพรอมต์ของระบบตั้งแต่เริ่มต้นการสนทนา โมเดลสามารถเข้าถึงชื่อ Skill และคำอธิบายจำนวนหนึ่งเพื่อให้สามารถตัดสินใจได้ว่าจะเรียกใช้ “load_skill()” หรือไม่ เกณฑ์ในการเข้าไปอยู่ในดัชนีนี้สูงมาก Skill ของคุณต้องมีประโยชน์มาก และคำอธิบายต้องมีความหนาแน่นและกระชับเป็นอย่างยิ่งเพราะทุกคนต้องแบกรับต้นทุนนี้ตลอดเวลา

หลังจากที่ระบบเอเจนต์โหลด Skill แล้ว จะเข้าสู่ส่วนเนื้อหา SKILL.md เต็มรูปแบบ ตามหลักการแล้ว ข้อความเนื้อหาต้องไม่เกิน 5,000 โทเค็น ถึงกระนั้น คุณก็ยังต้องการให้ทุกประโยคมีความสำคัญ เพราะเมื่อคุณโหลด Skill แล้ว บทสนทนาที่เหลือจะต้องแบกรับต้นทุนนั้นจนกว่าคุณจะถึงขอบเขตการบีบอัด (compaction boundary) เธรด (thread) จำนวนมากโหลด Skill ที่แตกต่างกันสามถึงห้าตัว ซึ่งเป็นการทวีคูณต้นทุนนี้ Skill ที่มีเนื้อหาน้ำท่วมทุ่งไร้สาระจะทำให้ Skill อื่น ๆ รวมถึงความสามารถของเอเจนต์โดยรวมเสื่อมลงอย่างแน่นอน กล่าวโดยสรุป หาก Skill ของคุณโหลดขึ้นมาแล้วไม่ได้ทำในสิ่งที่ถูกต้อง นั่นคือบริบทที่สูญเปล่า

ระดับสุดท้ายของความก้าวหน้าคือสคริปต์หรือกรณีพิเศษ เช่น subskills หรือการจัดรูปแบบ (formatting) นี่คือจุดที่คุณต้องการใส่ตรรกะแบบมีเงื่อนไขและแตกแขนงที่ไม่จำกัด เอเจนต์จะใช้งานมันเฉพาะเมื่อจำเป็นเท่านั้น ซึ่งหมายความว่ามีเกณฑ์ที่ต่ำกว่ามากสำหรับสิ่งที่คุณต้องการใส่ไว้ที่นี่

ในดัชนี ทุกโทเค็นมีความสำคัญ เนื้อหา Skill ที่โหลดแล้วจะมีความผ่อนคลายมากขึ้น และรันไทม์จะผ่อนคลายที่สุด ซึ่งอาจเป็น 20,000 โทเค็นหรือศูนย์โทเค็น นี่คือระดับที่คุณอาจคิดถึงการขยายบริบทของโมเดลในลักษณะที่เป็นขั้นเป็นตอน

คุณต้องการ Skill เมื่อใด?

ทีม Agents มักจะถูกขอให้แสดงความคิดเห็นว่าจำเป็นต้องมี Skill จริงหรือไม่สำหรับโดเมนหรือ Use Case ที่กำหนด แทบจะน้อยครั้งมากที่เราจะมีคำตอบที่เด็ดขาดจากหลักการพื้นฐานเพียงอย่างเดียว วิธีเดียวที่จะหาคำตอบนี้ได้อย่างแท้จริงคือการเริ่มต้นด้วยเอเจนต์ของคุณที่ไม่มี Skill รันคิวรีหลัก (hero query) หลายรายการ จากนั้นจึงพิจารณาว่าเอเจนต์ทำงานได้ดีหรือไม่

เมื่อคุณต้องการ Skill

มีงานจำนวนมากที่อยู่ในการกระจายตัว (in distribution) สำหรับโมเดลที่ผ่านการฝึกอบรมมาแล้ว คุณจะต้องใช้ Skill ก็ต่อเมื่อคุณต้องการเปลี่ยนพฤติกรรมนั้นในลักษณะเฉพาะเจาะจงบางประการ ซึ่งคุณไม่สามารถทำได้ด้วยตัวอย่างเช่น หนึ่งประโยคในพรอมต์ของคุณ ดังนั้น คุณจึงต้องการ Skill เมื่อเอเจนต์จะทำงานผิดพลาดหากไม่มีบริบทพิเศษ หรือหากมีความไม่สอดคล้องหรือความไม่แน่นอน (non-determinism) ที่คุณต้องการให้มีความสอดคล้องกันอย่างมากตลอดการรัน

อาจเป็นไปได้ว่าความรู้ของคุณมีความคงทนแต่วิชาความรู้นั้นไม่ได้อยู่ในข้อมูลการฝึกอบรม อาจมีจุดตัด (cutoffs) หรือเวิร์กโฟลว์เฉพาะขององค์กร หรืออาจเป็นเรื่องของรสนิยม ตัวอย่างเช่น เรามี Skill ที่เกี่ยวข้องกับการออกแบบหลายรายการใน Computer ซึ่งเขียนโดย Henry Modisett (หัวหน้าฝ่ายออกแบบของเรา) เหตุผลที่ทุกโทเค็นมีอยู่จริงใน Skill เหล่านั้นก็เพราะ Henry มีรสนิยมที่ดีมากเมื่อพูดถึงการออกแบบเว็บไซต์และ PDF Henry ระบุว่าควรใช้ฟอนต์ใดและไม่ควรใช้ฟอนต์ใด ฟอนต์เหล่านั้นให้ความรู้สึกอย่างไร และเรื่องอื่น ๆ ที่ต้องอาศัยการตัดสินใจซึ่งโมเดลไม่สามารถเรียนรู้ได้จากข้อมูลการฝึกอบรมเพียงอย่างเดียว

เมื่อคุณไม่ต้องการ Skill

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

เราเห็นตัวอย่างที่ Skill ทำซ้ำคำสั่งจากพรอมต์ของระบบ คุณไม่จำเป็นต้องมี Skill สำหรับเรื่องนั้น ความรู้ที่เกี่ยวข้องสำหรับคำขอส่วนใหญ่ควรถูกรวมไว้ในบริบทส่วนกลาง (global context) ไม่ใช่ใน Skill ที่โหลดตามเงื่อนไข

หากมีบางสิ่งที่เปลี่ยนแปลงเร็วกว่าที่คุณจะสามารถดูแลรักษาได้ คุณก็ไม่จำเป็นต้องมี Skill ตัวอย่างเช่น หากคุณกำลังเรียกใช้งานรีโมท MCP ปลายทางบางแห่งและเครื่องมือของมันหรือเวอร์ชันของเครื่องมือเหล่านั้นเปลี่ยนแปลงบ่อยครั้ง คุณไม่ควรแทรกสิ่งเหล่านั้นลงใน Skill หากคุณทำเช่นนั้น คุณจะพบกับความเบี่ยงเบน (drift) และโมเดลจะทำข้อผิดพลาด

ทุก Skill คือภาษี

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

คำคมชื่อดังต่อไปนี้ ซึ่งฟังดูดีกว่ามากในภาษาฝรั่งเศส แปลคร่าว ๆ ได้ว่า “ฉันเขียนจดหมายฉบับนี้ให้ยาวขึ้นเป็นพิเศษ ก็เพราะว่าฉันไม่มีเวลาพอที่จะทำให้มันสั้นลง”

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — Blaise Pascal, Lettres Provinciales, 1657

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

หากคุณพบว่าตัวเองพยายามสร้าง Skill แบบครั้งเดียวจบ (one-shot) และส่งพูลรีเควสต์ (PR) ภายในห้านาที ผลลัพธ์ที่ได้จะต่ำกว่ามาตรฐานอย่างแน่นอน อันที่จริง งานวิจัยเบื้องต้นได้แสดงให้เห็นแล้วว่าหากคุณใช้ LLMs เพื่อเขียน Skill ตัว LLM เองอาจจะไม่ได้รับประโยชน์จากมัน: “Skill ที่สร้างขึ้นเองไม่ได้ให้ประโยชน์ใด ๆ โดยเฉลี่ย ซึ่งแสดงให้เห็นว่าโมเดลไม่สามารถสร้างความรู้เชิงกระบวนการที่พวกมันได้รับประโยชน์จากการบริโภคได้อย่างน่าเชื่อถือ”

วิธีสร้าง Skill

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

ขั้นตอนที่ 0: เขียนการประเมิน (Evals)

เขียนการประเมินบางส่วนก่อน คุณสามารถหาเคสประเมินได้จาก:

คิวรีของผู้ใช้จริง: สุ่มตัวอย่างจากสภาพแวดล้อมการใช้งานจริง (production) หรือกลุ่มมันสมองของคุณ (brain trust)

ความล้มเหลวที่ทราบ: เอเจนต์ล้มเหลวเนื่องจากไม่มี Skill นั้นอยู่

ความสับสนของเพื่อนบ้าน (Neighbor confusion): ใกล้กับขอบเขตโดเมนของคุณแต่ถูกเส้นทาง (route) ไปยัง Skill อื่น

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

เริ่มต้นด้วยตัวอย่างเชิงลบและเชิงบวกที่คล้ายคลึงกัน ตัวอย่างเชิงลบมีพลังอย่างมากและอาจมีความสำคัญมากกว่าตัวอย่างเชิงบวกเสียอีก

ขั้นตอนที่ 1: คำอธิบาย (The Description)

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

อีกครั้ง คำอธิบายที่แย่จะอธิบายว่า Skill ทำอะไรหรือทำไมมันจึงมีประโยชน์ คำอธิบายที่ดีจะบอกว่าเมื่อใดที่เอเจนต์ควรโหลด Skill ตัวอย่างเช่น สมมติว่าคุณมีบางอย่างสำหรับการตรวจสอบพูลรีเควสต์ อย่าเขียนว่า Skill ทำอะไร แต่ให้เขียนสิ่งที่วิศวกรพูดเมื่อพวกเขารู้สึกหงุดหงิดและต้องการให้คุณแน่ใจว่า PR ของพวกเขาใช้งานได้ เช่น “babysit” (ดูแลอย่างใกล้ชิด) หรือ “watch CI” (เฝ้าดู CI) หรือ “make sure this lands” (ทำให้แน่ใจว่ามันผ่าน)

นี่คือรายการตรวจสอบด่วน:

ขึ้นต้นด้วย "Load when..."

ตั้งเป้าไว้ที่ 50 คำหรือน้อยกว่า

อธิบายความตั้งใจของผู้ใช้ โดยอุดมคติแล้วมาจากคิวรีจริง

ไม่สรุปเวิร์กโฟลว์

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

ขั้นตอนที่ 2: เขียนเนื้อหา (Write the Body)

ถัดมา เขียนเนื้อหาของ Skill เอง โปรดสังเกตว่านี่ไม่ใช่ขั้นตอนที่ 0 หรือขั้นตอนที่ 1

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

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

ตัวอย่างเช่น คุณไม่ต้องเขียนว่า “git log # คหาคอมมิต; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”

แทนที่จะเป็นเช่นนั้น ให้เขียนว่า “Cherry-pick the commit onto a clean branch. Resolve conflicts preserving intent. If it can't land cleanly, explain why.”

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

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

สุดท้าย หากมีส่วนใดที่เป็นเงื่อนไขหรือมีเนื้อหาหนักหน่วงเป็นพิเศษ ให้ดึงมันออกจาก SKILL.md ซึ่งเป็นฮับ แล้วใส่ลงในกิ่งก้าน (spokes) ด้านใดด้านหนึ่ง ใส่ลงในไฟล์เสริมที่สามารถโหลดได้อย่างเป็นขั้นเป็นตอน ซึ่งเราจะเจาะลึกกันต่อไป

ขั้นตอนที่ 3: ใช้ลำดับชั้น (Use the Hierarchy)

ใช้ประโยชน์จากลำดับชั้น Skill เมื่อคุณมีสคริปต์ เอกสารอ้างอิง หรือคุณกำลังใช้เครื่องมือเฉพาะบางอย่าง:

การใช้งานที่แนะนำสำหรับสคริปต์, ข้อมูลอ้างอิง, แอสเซ็ต และการกำหนดค่าใน Skill.

สำหรับสิ่งใดก็ตามที่เป็นเงื่อนไขหรือแตกแขนงออกจาก Skill หลัก ให้แยกออกมาเป็นโฟลเดอร์ นอกจากนี้ โปรดจำไว้ว่าลำดับชั้นหลายระดับสามารถใช้สำหรับ Skill ที่มีความซับซ้อนเป็นพิเศษได้ สำหรับสิ่งเหล่านี้ คุณจะต้องพิจารณาอย่างรอบคอบว่าควรใช้งานฟังก์ชันการทำงานแบบเสาหลิว (monolithically) หรือเป็นคอลเลกชันของ Skill (อาจมีความสัมพันธ์ในการโหลดตาม depends:)

ขั้นตอนที่ 4: ทำซ้ำ (Iterate)

ถัดมา ทำการทำซ้ำหลาย ๆ ครั้งบนสาขา (branch) เริ่มต้นบนสาขาหลัก (main branch) โดยไม่มี Skill ทำการทำซ้ำ สร้างชุดคิวรีหลัก (hero query set) ของคุณ และรันการประเมินจำนวนมาก ใครก็ตามที่ตรวจสอบโค้ด Skill ของคุณจะต้องขอบคุณที่คุณส่งชุดการเปลี่ยนแปลง (changeset) เดียวพร้อมชุดการประเมินที่สมบูรณ์ การตรวจสอบการเปลี่ยนแปลงทีละขั้นต่อเนื่องกัน (ยกเว้นข้อควรระวังใหม่) เป็นเรื่องที่ยากมาก ดังนั้นพยายามลดมันให้เหลือน้อยที่สุด

คุณน่าจะทำการเปลี่ยนคำเล็ก ๆ น้อย ๆ หลายครั้ง การเปลี่ยนคำเล็ก ๆ น้อย ๆ ในคำอธิบายอาจส่งผลกระทบอย่างมากต่อการกำหนดเส้นทาง (รวมถึงผลกระทบในวงกว้างต่อ Skill อื่น ๆ) ดังนั้น ห้ทำงานทั้งหมดนั้นให้เสร็จก่อนขั้นตอนที่ 5

ขั้นตอนที่ 5: ส่งมอบ (Ship)

ส่งมอบมันเลย

วิธีดูแลรักษา Skill

ตอนนี้คุณได้เขียน Skill แล้ว คุณต้องดูแลรักษามัน

วงล้อช่วยส่งแรงเหวี่ยงของข้อควรระวัง (The Gotchas Flywheel)

นับจากจุดนี้เป็นต้นไป รายการข้อควรระวังของคุณจะมีแนวโน้มที่จะเติบโตหรือเปลี่ยนแปลงไปมาก เรามักจะเห็นวิศวกรที่สร้าง PR ที่ไม่ได้ผ่านการประเมิน เช่น เปลี่ยนคำอธิบาย หากคุณกำลังเปลี่ยนคำอธิบายหลังจากที่ Skill ของคุณถูกผสาน (merged) แล้ว แสดงว่าคุณกำลังมาผิดทาง หากคุณกำลังทำการเปลี่ยนแปลงกับสิ่งที่ตัดสินใจว่าจะกำหนดเส้นทาง Skill ของคุณหรือไม่ คุณต้องเขียนการประเมินบางส่วนเพื่อสนับสนุนการเปลี่ยนแปลงเหล่านั้น

Skill มีลักษณะเป็นการเพิ่มต่อท้ายเป็นหลัก (append-mostly) ส่วนข้อควรระวังจะสะสมคุณค่ามากที่สุดเมื่อเวลาผ่านไป:

เอเจนต์ล้มเหลวในบางสิ่ง → เพิ่มข้อควรระวัง

เอเจนต์โหลด Skill ออกนอกเป้าหมาย → ทำให้คำอธิบายกระชับขึ้นและเพิ่มการประเมินเชิงลบ

เอเจนต์ไม่โหลด Skill เมื่อควรจะโหลด → เพิ่มคีย์เวิร์ดและการประเมินเชิงบวก

พรอมต์ของระบบเปลี่ยนแปลง → ตรวจสอบการขัดแย้งหรือการซ้ำซ้อน

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

เมื่อคุณย้ายจากการใช้กฎ 80-20 ไปสู่การบรรลุอัตราความสำเร็จ 99.9% หรือ 99.99% มันง่ายมากที่จะทำให้รายการข้อควรระวังนี้เติบโตขึ้น เมื่อคุณเห็นตัวอย่างเชิงลบเหล่านี้ คุณควรจะผนวกเพิ่มลงในส่วนข้อควรระวังเป็นหลัก คุณไม่ควรเพิ่มคำแนะนำที่ยาวขึ้นหรือเปลี่ยนคำอธิบาย

ชุดการประเมิน (Eval Suites)

ที่ Perplexity เราเตอร์การประเมิน (eval suites) จำนวนมากเพื่อตรวจสอบสิ่งต่าง ๆ มีการโหลด Skill และการอ่านไฟล์ Skill ซึ่งจะตรวจสอบความแม่นยำ ความระลึก (recall) และการตรวจสอบสิ่งที่ห้าม (forbidden checks) ของการโหลด Skill เอง เอเจนต์จะกำหนดเส้นทาง Skill ของคุณเมื่อถึงกำหนดหรือไม่? สิ่งเหล่านี้ช่วยให้มั่นใจว่า Skill ใหม่จะไม่ทำลายขอบเขตที่มีอยู่เดิม

นอกจากนี้ยังมีการประเมินที่สามารถตรวจสอบการโหลดแบบก้าวหน้าที่เหมาะสมได้ เอเจนต์อาจโหลด Skill แต่มีการอ่านไฟล์เสริมหรือไม่? ตัวอย่างเช่น หากคุณมี Skill ด้านการเงินสำหรับคิวรีทางการเงิน มันอ่านไฟล์ FORMATTING.md พิเศษหรือไม่

นอกจากนี้ยังมีการประเมินสำหรับ Skill ที่ทดสอบการทำงานจนสำเร็จแบบ end-to-end ภายในโดเมน เราเตอร์ลูปเอเจนต์แบบเต็มและใช้ตัวตัดสิน LLM เพื่อให้คะแนนผลลัพธ์ตามเกณฑ์ที่กำหนดไว้อย่างดี

สุดท้ายนี้ สิ่งสำคัญคือต้องรันการประเมินเหล่านี้กับโมเดลที่แตกต่างกัน Computer รองรับตระกูลโมเดลการประสานการทำงานอย่างน้อยสามตระกูล ได้แก่ GPT, Claude Opus และ Claude Sonnet คุณต้องการรันการโหลด Skill และ Skill ประจำโดเมนของคุณกับตัวประสานการทำงานเอเจนต์ที่แตกต่างกันเหล่านี้เพื่อให้แน่ใจว่าคุณจะไม่ได้รับพฤติกรรมที่แตกต่างกัน Sonnet และ GPT มีพฤติกรรมที่ค่อนข้างแตกต่างกันเมื่อพูดถึง Skill

ความคิดเห็นส่งท้ายและข้อสรุป

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

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

คุณสามารถทำให้กระบวนการหลังการเสียชีวิตของโปรเจกต์ (postmortems) เป็นแบบอัตโนมัติได้หรือไม่? คุณสามารถตรวจสอบพูลรีเควสต์ได้หรือไม่? งานใดก็ตามที่คุณทำ คุณสามารถให้ Agent Skill ทำการประเมินรอบแรกได้อย่างน้อยที่สุด มันจะช่วยประหยัดเวลาให้คุณได้อย่างมาก

ถึงกระนั้น จงจำไว้ว่า Skill ไม่ได้ง่ายและไม่ได้จำเป็นเสมอไป น้อยแต่มาก ข้อสรุปอื่น ๆ:

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

คำอธิบายคือส่วนที่ยาก "Load when..." (ทุกคำต้องแลกมาด้วยความสนใจ)

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

จำไว้ว่ามันง่ายมากที่จะทำให้ Skill ที่มีอยู่เดิมเสียหายด้วยการเพิ่ม Skill ใหม่ แม้ว่าคุณจะไม่ได้แตะต้องมันก็ตาม (ระวังผลกระทบระยะไกล - action at a distance)

ใช้เครื่องมือที่มีอยู่ทั้งหมดทุกครั้งที่คุณเขียนและดูแลรักษา Skill หากคุณต้องการเรียนรู้เพิ่มเติม เว็บไซต์ Agent Skills มีตัวอย่างดี ๆ มากมาย และทั้งคลังข้อมูลภายในของเราและระบบนิเวศสาธารณะต่างก็มีตัวอย่างมากมายของ Skill ที่ได้รับการออกแบบมาเป็นอย่างดี

การอ้างอิง

@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
  author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
  title = {{Designing, refining, and maintaining agent skills at Perplexity}},
  date = {2026-05-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}