LangChain 1.4.6 ให้ AI ขออนุมัติแยกงาน ก่อนลงมือใช้เครื่องมือ

LangChain 1.4.6 เพิ่มทางเลือกให้ผู้ช่วย AI หยุดขออนุมัติแยกทุกครั้งที่เรียกเครื่องมือซึ่งถูกกำหนดให้ต้องตรวจ แทนการหยุดรวมหนึ่งครั้งต่อรอบคำตอบของโมเดล โดยรุ่นนี้มีหน้าเผยแพร่ลงวันที่ 14 ตุลาคม 2026 ครับ (GitHub Release) เรื่องนี้เกี่ยวกับชีวิตประจำวันตรงที่ เมื่อเราให้ AI ทำงานต่อจากการพิมพ์ตอบ เช่น เขียนไฟล์หรือจัดการข้อมูล เราต้องมองเห็นให้ชัดว่ากำลังกดอนุมัติงานไหน เอกสารของโครงการยกงานเขียนไฟล์และสั่งงานฐานข้อมูลเป็นตัวอย่างของงานที่อาจต้องมีคนตรวจก่อนลงมือ (LangChain Docs)

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

สรุป 30 วินาที: เกิดอะไรขึ้น

LangChain เป็นชุดเครื่องมือสำหรับสร้างระบบ AI ตามบริบทของเอกสารนี้ ส่วน AI agent คือผู้ช่วยที่สามารถเรียกเครื่องมือเพื่อทำงานต่อได้ กลไก Human-in-the-Loop หรือ HITL หมายถึงการให้คนเข้ามาตรวจและตัดสินใจก่อนบางงานจะทำต่อ โดยส่วนคั่นการทำงานที่ชื่อ HumanInTheLoopMiddleware จะตรวจคำขอใช้เครื่องมือเทียบกับกติกาที่ผู้พัฒนาตั้งไว้ แล้วหยุดรอคนเมื่อจำเป็น (LangChain Docs)

สิ่งที่เพิ่มเข้ามาในรุ่นนี้คือโหมด per_call ซึ่งหยุดแยกแต่ละคำขอใช้เครื่องมือที่ต้องตรวจ ผู้ตรวจจึงตอบแต่ละงานผ่านรหัสของการหยุดนั้นได้ ส่วนโหมด batched ที่เป็นค่าเริ่มต้นยังรวมงานที่ต้องตรวจในรอบเดียวกันไว้ด้วยกัน และต้องตอบเรียงตามลำดับงาน แต่ละงานในโหมดเดิมก็ยังต้องมีคำตัดสินของตัวเอง ไม่ได้หมายความว่ากดครั้งเดียวแล้วอนุมัติทุกอย่างโดยอัตโนมัติ (LangChain Docs)

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

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

ตัวอย่างในคำขอรวมโค้ดของโครงการมีผู้ช่วยที่เสนอทั้งส่งอีเมล ลบไฟล์ และค้นข้อมูลในรอบเดียวกัน โหมดใหม่แยกคำขออนุมัติของงานส่งอีเมลกับลบไฟล์ออกจากกัน ส่วนงานค้นข้อมูลที่ไม่ได้ตั้งให้ต้องตรวจสามารถทำได้ทันที ตัวอย่างนี้จึงช่วยให้เห็นว่าการมีหน้าขออนุมัติไม่ได้แปลว่าระบบทั้งชุดหยุดนิ่งรอเราอยู่เสมอ (GitHub PR #41062)

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

ทำงานยังไง

ลองนึกถึงแอปธนาคารที่ขอ OTP แยกแต่ละรายการโอน แทนการใช้ OTP หนึ่งชุดกับรายการทั้งตะกร้า จุดที่ยืมมาเปรียบคือการผูกคำยืนยันให้ตรงกับรายการที่กำลังตรวจครับ ใน LangChain โหมดเดิมรวมงานที่ต้องตรวจมาในหนึ่งชุด แล้วจับคู่คำตัดสินตามลำดับ ส่วนโหมดใหม่ให้แต่ละงานมีการหยุดและรหัสของตัวเอง ผู้ตรวจจึงตอบงานนั้นได้โดยตรง (GitHub PR #41062)

เมื่อ AI ขอใช้เครื่องมือที่ต้องผ่านคน ระบบจะส่งสัญญาณหยุดที่มีชนิด tool_approval หมายถึงคำขออนุมัติเครื่องมือ พร้อมข้อมูลว่างานนั้นจะทำอะไร และมี response_schema ซึ่งเป็นแบบกำหนดรูปคำตอบที่ยอมรับได้ เช่น งานหนึ่งอาจอนุญาตให้อนุมัติหรือปฏิเสธเท่านั้น อีกงานอาจยอมให้แก้ไขก่อนทำได้ด้วย ข้อมูลนี้ช่วยให้แอปสร้างแบบฟอร์มตามตัวเลือกที่เครื่องมือนั้นรองรับ (LangChain Docs)

เบื้องหลังการหยุดมี LangGraph ซึ่งดูแลลำดับและสถานะของงาน ระบบต้องมี checkpointer หรือส่วนบันทึกสถานะระหว่างทาง เพื่อกลับมาทำต่อได้หลังคนตอบ เอกสารให้ใช้ตัวบันทึกในหน่วยความจำสำหรับทดสอบหรือลองต้นแบบ และแนะนำตัวบันทึกแบบคงอยู่สำหรับระบบใช้งานจริง พร้อมผูกการทำงานเข้ากับรหัสบทสนทนา (LangChain Docs)

เมื่อผู้ตรวจส่งคำตอบกลับมา LangGraph จะตรวจคำตอบกับแบบที่กำหนดก่อนบันทึก หากผิดรูปแบบจะเกิด ValidationError หรือข้อผิดพลาดจากการตรวจข้อมูล และสามารถส่งคำตอบที่แก้แล้วกลับไปยังรหัสเดิมได้ อย่างไรก็ตาม ขอบเขตการตรวจรายละเอียดที่แก้ไขมีข้อความในเอกสารกับคำขอรวมโค้ดไม่ตรงกัน ซึ่งต้องอ่านร่วมกับข้อจำกัดด้านล่าง (LangChain Docs, GitHub PR #41062)

อีกจุดที่คนออกแบบหน้าจอต้องแยกให้ชัดคือ “ปฏิเสธ” กับ “ตอบแทนเครื่องมือ” เอกสารระบุให้ใช้ reject เมื่อต้องการห้ามงานนั้น ส่วน respond ใช้เมื่อคนกำลังตอบแทนเครื่องมือประเภทถามผู้ใช้ เพราะข้อความจาก respond จะถูกถือเป็นผลสำเร็จของเครื่องมือ การกดตอบกลับจึงไม่ได้มีความหมายเหมือนการสั่งยกเลิกครับ (LangChain Docs)

จุดหักมุม: คำตอบหนึ่งผิด ไม่ได้แปลว่างานอื่นยังไม่เกิด

ข้อควรระวังที่สำคัญอยู่ในคำขอรวมโค้ด: ถ้าส่งคำตอบหลายงานกลับไปพร้อมกัน แล้วคำตอบหนึ่งไม่ผ่านการตรวจ เครื่องมือของคำตอบอื่นอาจทำงานไปแล้ว แม้สถานะยังแสดงว่ารออยู่ สาเหตุมาจากจังหวะการบันทึกสถานะของ LangGraph ที่อาจไม่ทันกัน และถ้าตอบงานเหล่านั้นซ้ำ ก็อาจทำให้เครื่องมือทำงานซ้ำได้ (GitHub PR #41062)

ดังนั้นประโยคว่า “คำตอบผิดแล้วไม่บันทึกอะไร” ต้องอ่านในขอบเขตของคำตอบที่ตรวจไม่ผ่าน อย่าเหมารวมว่าทุกงานในชุดเดียวกันถูกย้อนกลับทั้งหมด แนวทางที่ผู้เขียนคำขอรวมโค้ดเสนอคือ ตรวจคำตอบกับแบบที่กำหนดก่อนส่ง หรือส่งคำตัดสินกลับทีละงาน (GitHub PR #41062)

สำหรับคนใช้งาน ผลในทางปฏิบัติคือเมื่อหน้าจอแจ้งข้อผิดพลาด อย่าเพิ่งตีความว่าไม่มีงานใดเกิดขึ้น ทีมพัฒนาควรทำให้ผู้ตรวจตรวจสอบผลของแต่ละงานได้ก่อนสั่งใหม่ ข้อนี้เป็นคำแนะนำของผมที่ต่อเนื่องจากความเสี่ยงงานซ้ำซึ่งโครงการระบุไว้ ไม่ใช่คุณสมบัติหน้าจอที่ข่าวนี้ยืนยันว่ามีให้แล้ว (GitHub PR #41062)

เรื่องเงิน / ผลกระทบ

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

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

ฝั่งทีมไอทีมีเงื่อนไขที่ต้องเตรียม: โหมดนี้ต้องใช้ LangChain ตั้งแต่ 1.4.6 และการเปลี่ยนแปลงในคำขอรวมโค้ดขยับ LangGraph ขั้นต่ำเป็น 1.2.12 ส่วนการรันแบบ async หรือให้ระบบรอและจัดการงานโดยไม่ต้องค้างรอทีละงาน ต้องใช้ Python 3.11 ขึ้นไปตามที่คำขอรวมโค้ดระบุ (LangChain Docs, GitHub PR #41062)

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

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

จุดที่ต้องระบุอย่างตรงไปตรงมาคือการตรวจข้อมูลหลังผู้ตรวจแก้ไข คำขอรวมโค้ดระบุว่าการแก้ไขไม่สามารถเปลี่ยนไปใช้เครื่องมืออีกตัว และข้อมูลต้องตรงกับ Pydantic schema หรือแบบตรวจชนิดและโครงสร้างข้อมูลที่เครื่องมือประกาศไว้ ข้อมูลส่วนเกินที่เครื่องมือไม่ได้ประกาศจะถูกละไว้ ส่วนเครื่องมือที่นิยามด้วย JSON schema โดยตรงจะแสดงแบบข้อมูลแต่ไม่ตรวจการแก้ไข (GitHub PR #41062)

แต่เอกสารการใช้งานที่ให้มากลับมีข้อความว่า แบบคำตอบแสดงข้อมูลของเครื่องมือ ทว่า LangGraph ไม่ตรวจการแก้ไขเทียบกับข้อมูลเหล่านั้น แม้ส่วนอื่นในหน้าเดียวกันจะอธิบายว่าตรวจคำตอบก่อนบันทึกก็ตาม จึงยังยืนยันจากแหล่งข้อมูลชุดนี้ไม่ได้ว่าการตรวจรายละเอียดทุกชนิดจะทำงานตรงตามคำอธิบายใดในทุกกรณี ทีมที่พึ่งการแก้ไขคำสั่งควรทดลองกับเครื่องมือที่ใช้จริงในสภาพแวดล้อมทดสอบก่อน (LangChain Docs)

ด้านวันเผยแพร่ หน้า release ระบุวันที่ 14 ตุลาคม 2026 โดยไม่มีเวลาและเขตเวลา จึงใช้ได้เพียงวันที่ ส่วนคำขอรวมโค้ดระบุเวลารวมโค้ดชัดเจน ซึ่งแปลงเป็นเวลาไทยได้เป็น 14 ตุลาคม 2026 เวลา 23:49:33 น. ข้อมูลสองส่วนนี้ไม่ได้ขัดกัน แต่ไม่ควรนำเวลารวมโค้ดไปใช้แทนเวลาเผยแพร่แพ็กเกจ (GitHub Release, GitHub PR #41062)

แหล่งข้อมูลไม่ได้ระบุวันแน่นอนของรุ่นใหญ่ที่จะเปลี่ยนค่าเริ่มต้น และไม่ได้ยืนยันว่ามีองค์กรไทยใดนำโหมดนี้ไปใช้แล้ว เราทราบเพียงแผนเรื่องค่าเริ่มต้นจากโครงการ จึงควรติดตามประกาศต่อไปแทนการนับว่าเปลี่ยนแล้วครับ (GitHub PR #41062)

แล้วเราควรทำอะไร

คนใช้ผู้ช่วย AI ในงานประจำ

1. ก่อนกดอนุมัติ ให้อ่านว่างานนั้นจะทำอะไรและรายละเอียดตรงกับความตั้งใจหรือไม่ โหมดใหม่ส่งข้อมูลระบุคำขอแต่ละงานมาให้ แต่การนำเสนอให้อ่านง่ายยังเป็นงานของแอปที่ใช้ข้อมูลเหล่านี้ (LangChain Docs)
2. ถ้าต้องการห้ามงาน ให้ใช้ตัวเลือกปฏิเสธตามที่ระบบจัดไว้ อย่าถือว่าการพิมพ์ตอบผ่านช่องตอบแทนเครื่องมือจะยกเลิกงาน เพราะเอกสารแยกความหมายของสองคำตัดสินนี้ไว้ชัดเจน (LangChain Docs)
3. เมื่อระบบแจ้งว่าคำตอบผิด ให้ตรวจผลของงานอื่นก่อนสั่งซ้ำ โดยเฉพาะกรณีที่แอปส่งหลายคำตัดสินพร้อมกัน ความเสี่ยงที่งานอื่นทำไปแล้วแม้ยังแสดงว่ารออยู่มีระบุในคำขอรวมโค้ด (GitHub PR #41062)

เจ้าของธุรกิจและคนดูแลการนำ AI มาใช้

1. ให้ทีมระบุรายการงานที่ต้องผ่านคนอย่างชัดเจน การมี HITL ไม่ได้บังคับให้ทุกเครื่องมือหยุด เพราะตั้งค่าให้ผ่านอัตโนมัติได้ และยังตั้งเงื่อนไขให้หยุดเฉพาะบางคำขอได้ด้วย (LangChain Docs)
2. ขอให้ทีมสาธิตทั้งกรณีอนุมัติ ปฏิเสธ และตอบผิดในโครงการทดลองก่อนใช้กับงานจริง นี่เป็นข้อเสนอในการทดสอบของผม โดยอิงจากข้อจำกัดเรื่องการตรวจคำตอบและความเสี่ยงทำงานซ้ำที่โครงการแจ้งไว้ (GitHub PR #41062)
3. เริ่มด้วยข้อมูลทดสอบและสิทธิ์สำหรับทดสอบ ห้ามนำข้อมูลรับรองของระบบจริง เช่น รหัสหรือกุญแจเข้าถึงบริการจริง มาใส่ในโครงการทดลอง ข้อนี้เป็นคำแนะนำของผมเพื่อจำกัดผลกระทบระหว่างตรวจพฤติกรรมที่ยังต้องพิสูจน์

ผู้พัฒนาและทีมไอที

1. ตรวจรุ่นที่ใช้และเปิดโหมด per_call อย่างตั้งใจ พร้อมตรวจเงื่อนไข LangGraph ตั้งแต่ 1.2.12 และ Python 3.11 ขึ้นไปหากรันแบบ async ค่าเริ่มต้นยังเป็น batched จึงควรตรวจค่าที่ใช้งานจริงหลังอัปเดต (GitHub PR #41062)
2. วาง HumanInTheLoopMiddleware ก่อนส่วนที่ลองทำงานใหม่เมื่อผิดพลาดหรือส่วนจัดการข้อผิดพลาด เพื่อให้มันครอบการทำงานเหล่านั้น มิฉะนั้นงานที่ลองใหม่อาจถามผู้ตรวจซ้ำ หรือคำตอบผิดอาจถูกส่งกลับไปให้โมเดลเป็นข้อผิดพลาดของเครื่องมือ (LangChain Docs)
3. ตรวจส่วนคั่นการทำงานที่อยู่ก่อน HITL ว่าไม่มีการทำงานที่เปลี่ยนข้อมูลจริงก่อนส่งต่อ เพราะเมื่อกลับมาทำต่อ ส่วนนี้จะรันซ้ำจนถึงจุดหยุด และเงื่อนไขตัดสินว่าควรหยุดหรือไม่ต้องให้ผลเดิมสำหรับคำขอเดิมด้วย เอกสารเตือนว่าถ้าเงื่อนไขเปลี่ยนเป็นให้ผ่านตอนทำต่อ คำตอบของผู้ตรวจอาจถูกละเลยแม้เป็นการปฏิเสธ (LangChain Docs)
4. ตรวจคำตอบก่อนส่งกลับ หรือส่งทีละงานตามคำแนะนำในคำขอรวมโค้ด แล้วทดสอบการแก้ข้อมูลกับชนิดเครื่องมือที่ใช้จริง รวมถึงเตรียมส่วนบันทึกสถานะให้เหมาะกับการทดลองหรือการใช้งานจริง (GitHub PR #41062, LangChain Docs)

หลักฐานความปลอดภัยและความเสี่ยงที่ยังเหลือ

ด้านที่มา ข่าวนี้อ้างอิงคลังโค้ดทางการ langchain-ai/langchain บน GitHub หน้า release ที่มีแท็ก langchain==1.4.6 ลงวันที่ 14 ตุลาคม 2026 และคำขอรวมโค้ด #41062 ที่ระบุรายละเอียดโหมดใหม่และเวลารวมโค้ด หลักฐานเหล่านี้ช่วยตรวจสอบที่มาของการเปลี่ยนแปลง แต่ไม่ได้เป็นผลรับรองว่าทุกระบบที่นำไปใช้จะปลอดภัย (GitHub Release, GitHub PR #41062)

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

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

ความเสี่ยงที่ยังเหลือจึงมีทั้งเงื่อนไขหยุดที่เปลี่ยนผลตอนทำต่อ การทำงานของส่วนคั่นก่อนถึงจุดอนุมัติ และกรณีส่งหลายคำตอบแล้วบางงานอาจเกิดขึ้นก่อนระบบแจ้งข้อผิดพลาด ผมแนะนำให้ลองในโครงการที่ทิ้งได้หรือสภาพแวดล้อมทดสอบก่อน ใช้ข้อมูลจำลอง และไม่ใช้ข้อมูลรับรองของระบบจริง การมีคนกดอนุมัติเป็นส่วนหนึ่งของการควบคุม ยังรับรองความปลอดภัยทั้งหมดไม่ได้ครับ (LangChain Docs, GitHub PR #41062)

ผมมองว่า…

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

ผมยังคิดว่าทีมควรให้ความสำคัญกับหน้าจอตอนผิดพลาดพอ ๆ กับหน้าจอตอนกดอนุมัติ เพราะข้อจำกัดที่แจ้งไว้ทำให้สถานะ “รออยู่” อาจไม่เพียงพอจะบอกว่างานยังไม่เกิด การให้คนตรวจได้จริงต้องมีข้อมูลพอให้ตัดสินใจด้วย คนกดอนุมัติไม่ควรได้งานพิเศษเป็นนักเดาสถานะระบบครับ (GitHub PR #41062)

ปิดท้าย: สิ่งที่ต้องจับตา

เรื่องที่ควรติดตามต่อคือโครงการจะเปลี่ยน per_call เป็นค่าเริ่มต้นในรุ่นใหญ่เมื่อใด และจะอธิบายขอบเขตการตรวจข้อมูลที่แก้ไขให้ตรงกันอย่างไร ระหว่างนี้ทีมควรยึดค่าที่ตั้งจริง ทดสอบคำตอบผิด และตรวจการทำงานซ้ำก่อนนำไปผูกกับงานสำคัญ เพราะทั้งแผนเปลี่ยนค่าเริ่มต้นและข้อจำกัดการส่งหลายคำตอบยังอยู่ในข้อมูลที่โครงการเผยแพร่ (GitHub PR #41062, LangChain Docs)

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

Recap

• LangChain 1.4.6 เพิ่มโหมดขออนุมัติแยกแต่ละคำขอใช้เครื่องมือที่ต้องตรวจ (GitHub Release)
• ต้องเปิดโหมดใหม่เอง ค่าเริ่มต้นยังเป็น batched และแต่ละงานในชุดรวมยังต้องมีคำตัดสินของตัวเอง (LangChain Docs)
• โหมดใหม่ผูกคำตอบกับรหัสการหยุดของแต่ละงาน พร้อมแบบกำหนดคำตอบที่ยอมรับได้ (GitHub PR #41062)
• ใช้การปฏิเสธเมื่อต้องการห้ามงาน ส่วนการตอบแทนเครื่องมือมีความหมายต่างกัน (LangChain Docs)
• ส่งหลายคำตอบพร้อมกันแล้วบางคำตอบผิด งานอื่นอาจเกิดขึ้นแล้ว จึงควรตรวจคำตอบก่อนหรือส่งทีละงาน (GitHub PR #41062)
• ตรวจเงื่อนไข LangGraph ตั้งแต่ 1.2.12 และ Python 3.11 ขึ้นไปสำหรับการรันแบบ async (GitHub PR #41062)
• ทดสอบขอบเขตการตรวจข้อมูลที่แก้ไข เพราะเอกสารกับคำขอรวมโค้ดมีข้อความไม่ตรงกัน (LangChain Docs, GitHub PR #41062)
• ลองในโครงการทดสอบโดยไม่ใช้ข้อมูลรับรองของระบบจริง และตรวจประกาศความปลอดภัยก่อนตัดสินใจใช้งาน (GitHub Security)