- Octomind ใช้ AI Agent เพื่อสร้างและแก้ไขการทดสอบแบบ end-to-end ใน Playwright โดยอัตโนมัติ
- ในช่วงแรกใช้เฟรมเวิร์ก LangChain แต่เมื่อเวลาผ่านไป ระดับการทำ abstraction ที่สูงของ LangChain กลับก่อให้เกิดปัญหา
ปัญหาของ LangChain
- abstraction ของ LangChain มีประโยชน์ในช่วงแรก แต่เมื่อมีความต้องการที่ซับซ้อนขึ้น ก็ทำให้การทำความเข้าใจโค้ดและการบำรุงรักษายากขึ้น
- ต้องใช้เวลามากในการทำความเข้าใจโครงสร้างภายในของ LangChain และการดีบัก
- ตัวอย่างเช่น แม้แต่โค้ดที่แค่แปลคำภาษาอังกฤษง่ายๆ เป็นภาษาอิตาลี หากใช้ LangChain ก็ทำให้ความซับซ้อนเพิ่มขึ้น
ปัญหาจาก abstraction ของ LangChain
- LangChain ใช้ abstraction หลายชั้นซ้อนกัน ทำให้ความซับซ้อนของโค้ดเพิ่มขึ้น
- abstraction เหล่านี้ทำให้การทำความเข้าใจโค้ดและการดีบักยากขึ้น
- ตัวอย่างเช่น แม้แต่งานง่ายๆ อย่างดึงข้อมูล JSON จาก API หากใช้ LangChain ก็ทำให้ความซับซ้อนเพิ่มขึ้น
ผลกระทบต่อทีมพัฒนา
- เมื่อพยายามนำสถาปัตยกรรม Agent ที่ซับซ้อนมาใช้งาน LangChain กลับกลายเป็นข้อจำกัด
- หลังจากถอด LangChain ออก ก็สามารถเขียนโค้ดได้อย่างอิสระตามความต้องการ
การสร้าง AI application จำเป็นต้องมีเฟรมเวิร์กหรือไม่?
- LangChain มีประโยชน์ในช่วงแรก แต่ในระยะยาว การพัฒนาโดยไม่มีเฟรมเวิร์กน่าจะดีกว่า
- AI application ส่วนใหญ่สามารถสร้างได้ด้วยโค้ดที่เรียบง่ายและ external package เพียงไม่กี่ตัว
- แนะนำให้ใช้แนวทางที่เรียบง่ายไปก่อน จนกว่ารูปแบบการใช้งาน Agent จะเริ่มชัดเจน
การพัฒนาที่รวดเร็วและกระชับด้วย modular building block
- เฟรมเวิร์กบังคับโครงสร้าง แต่ AI application ยังไม่มีรูปแบบการใช้งานที่เป็นมาตรฐานชัดเจน
- แนวทาง modular building block ให้ความสำคัญกับโค้ดระดับล่างที่เรียบง่าย และช่วยเพิ่มความเร็วในการพัฒนา
- ใช้องค์ประกอบแบบโมดูล เช่น vector database เพื่อให้ codebase ยังคงกระชับและปรับตัวได้ง่าย
ความเห็นของ GN⁺
- ข้อจำกัดของ LangChain: abstraction ระดับสูงของ LangChain มีประโยชน์ในช่วงแรก แต่เมื่อมีความต้องการที่ซับซ้อนขึ้น ก็อาจกลายเป็นอุปสรรคได้
- ข้อดีของแนวทางแบบโมดูล: แนวทาง modular building block ช่วยให้การทำความเข้าใจโค้ดและการบำรุงรักษาง่ายขึ้น พร้อมทั้งเพิ่มความเร็วในการพัฒนา
- ทบทวนความจำเป็นของเฟรมเวิร์ก: ไม่ใช่ทุก AI application ที่ต้องใช้เฟรมเวิร์ก และหลายกรณีก็สามารถสร้างได้เพียงด้วยโค้ดที่เรียบง่ายและ external package
- ความสำคัญของความเร็วในการพัฒนา: ในสายงาน AI การทดลองและทำต้นแบบอย่างรวดเร็วเป็นเรื่องสำคัญ และเฟรมเวิร์กอาจเป็นข้อจำกัดต่อสิ่งนี้
- รูปแบบการใช้งาน Agent ในอนาคต: จนกว่ารูปแบบการใช้งาน Agent จะชัดเจน การคงแนวทางที่เรียบง่ายไว้จะเป็นทางเลือกที่ดี
2 ความคิดเห็น
ได้ยินกันว่ามันเป็นสถาปัตยกรรมที่ล้มเหลว แล้วตอนนี้ก็มาเห็นใน GeekNews จนได้
ความคิดเห็นจาก Hacker News
สร้างเอเจนต์ LLM เชิงพาณิชย์ตัวแรกเมื่อเดือนตุลาคม/พฤศจิกายนปีที่แล้ว: การสร้างเอเจนต์ขึ้นเองตั้งแต่ต้นโดยไม่ใช้ LangChain ช่วยให้ได้ผลลัพธ์ที่ดีกว่า
ความซับซ้อนของเฟรมเวิร์ก LLM: เฟรมเวิร์ก LLM อย่าง LangChain มีแนวโน้มจะนำความซับซ้อนแบบ Java หรือ Python เข้ามา
การเปรียบเทียบระหว่าง LangChain กับ ChatGPT: LangChain ถูกสร้างขึ้นก่อนการมาของ ChatGPT แต่เมื่อ ChatGPT มอบโมเดลการสนทนาที่ดีกว่า ความจำเป็นของ LangChain จึงลดลง
ข้อถกเถียงเรื่องคุณค่าของ LangChain: LangChain พยายามวางตัวอยู่ระหว่างนักพัฒนากับ LLM แต่ในทางปฏิบัติไม่ได้เพิ่มคุณค่าที่ชัดเจน และกลับเพิ่ม abstraction ที่ไม่จำเป็น
abstraction ที่ดีกับ abstraction ที่ไม่ดี: abstraction ที่ดีควรจัดการตรรกะของแอปพลิเคชัน ส่วน abstraction ที่ไม่ดีคือการนามธรรมสิ่งที่จำเป็นต้องลงมือทำจริงจนทำให้สูญเสียความเข้าใจ
ปัญหาของการใช้เอเจนต์: สำหรับการสร้างคอนเทนต์ การใช้ prompt แบบลำดับขั้นทำได้ง่ายและมีประสิทธิภาพมากกว่าการใช้เอเจนต์
แนะนำเฟรมเวิร์ก Ragged: มีการแนะนำ Ragged ซึ่งเป็นคอนเน็กเตอร์น้ำหนักเบาที่เชื่อมต่อกับ LLM ได้ง่าย และให้อินเทอร์เฟซแบบรวมศูนย์คล้าย ORM
การขาดประโยชน์ใช้สอยของ LangChain: แม้แนวทางของ LangChain จะน่าสนใจ แต่ในทางปฏิบัติการใช้ไลบรารีรันไทม์ของ LLM โดยตรงมีประสิทธิภาพมากกว่า
เฟรมเวิร์กเอเจนต์ที่เปลี่ยนแปลงอย่างรวดเร็ว: เฟรมเวิร์กเอเจนต์ที่ใช้อยู่เปลี่ยนแปลงเร็วมาก และแม้แต่การเปลี่ยนเวอร์ชันเล็กน้อยก็อาจทำให้การตั้งค่าปัจจุบันพังได้
ปัญหาความซับซ้อนของ LangChain: LangChain ซับซ้อนเกินไปสำหรับกรณีใช้งานง่าย ๆ และก็ปรับให้เข้ากับกรณีใช้งานที่ซับซ้อนได้ยาก ดังนั้นหลายครั้งการเขียนโค้ดเองจึงดีกว่า