LLM วิธีเขียนโค้ดที่มั่นคงกว่าคือเขียน DSL ก่อน

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

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

ภาษาธรรมชาติเหมาะแก่การพูดถึงปัญหาเท่านั้น

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

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

DSL เปลี่ยนการตัดสินโดยนัยเป็นอินพุตที่ชัดเจน

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

scenario: payment_timeout
steps:
  - send: order.created
  - wait: 3s
  - if: payment_missing
    then: cancel_order
    audit: required

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

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

LLM เหมาะสำหรับการมีส่วนร่วมในการเติบโตของ DSL

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

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

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

เลเยอร์ความหมายก็จะเทอะทะเช่นกัน

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

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