LangChain หรือ LlamaIndex: งาน RAG ซับซ้อนกับงานค้นคืนเลือกคนละตัว

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

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

จุดต่างอยู่ที่ส่วนซึ่งทีมใช้จัดระบบ

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

คำอธิบาย RAG ของ LlamaIndex วางงานเป็นการโหลดข้อมูล ทำดัชนี จัดเก็บ ค้นคืน และประเมินผล โดยใช้ Document, Node, connector, index และ retriever เชื่อมช่วงเหล่านั้นเข้าด้วยกัน แนวคิดนี้ช่วยให้ทีมที่เริ่มจากคลังข้อมูลมองตามได้ว่าเนื้อหาถูกแปลงเป็นหน่วยค้นคืนอย่างไร และหน่วยใดถูกส่งให้โมเดลใช้ตอบ อย่างไรก็ดี โครงสร้างที่เตรียมไว้ไม่ได้เลือกวิธีแบ่งข้อความหรือ metadata ที่เหมาะกับข้อมูลจริงให้โดยอัตโนมัติ

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

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

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

เมื่อข้อมูลต้นทางเป็นภาระหลัก

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

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

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

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

ข้อได้เปรียบด้านการพัฒนาจะเกิดจริงเมื่อทีมใช้โครงสร้าง Document, Node, index และ retriever ไปกับงานของตนได้ต่อเนื่อง หากระบบมีผลค้นจากบริการอื่นที่จัดรูปแบบและดูแลไว้อยู่แล้ว การสร้างดัชนีอีกชุดอาจเพิ่มจุดซิงก์โดยไม่ได้แก้ปัญหาหลัก ในกรณีนั้น ควรพิจารณาว่าจะนำผลค้นเดิมมาใช้โดยตรงได้หรือไม่ ก่อนย้ายวงจรข้อมูลเข้ามาอยู่ในเฟรมเวิร์กใหม่

รูปแบบการค้นคืนเปลี่ยนคำตอบเรื่องเฟรมเวิร์ก

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

บางคลังข้อมูลต้องเลือกวิธีค้นตามคำถาม เช่น คำถามหนึ่งต้องหาข้อความในคู่มือ อีกคำถามต้องค้นจากชุดข้อมูลที่จัดหมวดต่างกัน การเลือก retriever การใช้ตัวกรอง metadata และการจัดลำดับข้อความหลังค้น ล้วนเป็นงานด้าน retrieval แม้จะมีทางแยกหลายทาง ความซับซ้อนลักษณะนี้ยังอยู่ในขอบเขตการค้นข้อมูล จึงไม่จำเป็นต้องขยับไปใช้ agent เพียงเพราะมีทางเลือกมากกว่าหนึ่งทาง

ตรงกันข้าม หากผู้ช่วยต้องตัดสินใจระหว่างค้นเอกสาร เรียก API และใช้ผลจากฐานข้อมูลเพื่อทำงานต่อ ปัญหาหลักเริ่มขยายจากการค้นข้อความไปสู่การควบคุมพฤติกรรม ตัวอย่างแบบสมมติคือคำถามเกี่ยวกับข้อกำหนดสินค้าที่ตอบจากคู่มือได้ เทียบกับคำถามสถานะคำสั่งซื้อที่ต้องเรียกข้อมูลปัจจุบัน ระบบต้องรู้ว่าจะใช้แหล่งใด และต้องไม่เอาข้อความในคู่มือไปแทนสถานะรายการจริง

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

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

เมื่อการประสานเครื่องมือกลายเป็นงานหลัก

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

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

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

แนวคิดหลักของ LlamaIndex ระบุทั้ง query engine, agent และ Workflow จึงใช้สร้างงานหลายขั้นตอนได้เช่นกัน ความต่างในการเลือกจึงเป็นเรื่องศูนย์ถ่วงของระบบ หากทีมจัดข้อมูลเป็นดัชนีและใช้ query engine อยู่แล้ว การต่อยอดการประสานงานภายในโครงสร้างนั้นอาจลดรอยต่อได้ แต่หากแอปมีเครื่องมือหลายชนิดที่อยู่นอกคลังเอกสาร การวางการประสานงานเป็นแกนตั้งแต่แรกอาจอ่านและดูแลได้ง่ายกว่า

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

ต้นทุนความซับซ้อนอยู่ตรงไหนหลังเริ่มใช้

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

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

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

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

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

ตาราง benchmark ไม่ใช่คำตอบแทนสถาปัตยกรรม

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

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

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

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

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

ทางเลือกตามภาระที่ต้องรับจริง

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

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

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

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