LLM คืออวัยวะรับความรู้สึกไม่ใช่สมอง ทำไมสถาปัตยกรรมถึงสำคัญ
การออกแบบระบบ LLM ที่มีความต่อเนื่องของบริการหมายถึงสถาปัตยกรรมที่มอง LLM เป็นเพียงอวัยวะรับความรู้สึกของระบบ ใช้เพื่อแปลงข้อความยุ่งเหยิงจากมนุษย์ให้กลายเป็นสัญญาณข้อมูลที่มีโครงสร้างชัดเจน แล้วส่งต่อให้แกนตรรกะเชิงธุรกิจที่เป็นเชิงกำหนดแน่นอนทำการตัดสินใจ ระบบแบบนี้จะไม่ผูกชะตากรรมกับความไม่แน่นอนของโมเดล ไม่ว่าจะเรื่องการตอบเพี้ยน การเปลี่ยนสคีมาของข้อมูล หรือความหน่วงสูง แต่จะใช้ LLM เท่าที่จำเป็นและเตรียมกลไกสำรองไว้รองรับเมื่อโมเดลหรือการเชื่อมต่อขัดข้องเพื่อให้ผู้ใช้ยังทำงานหลักต่อได้
หนึ่งในความผิดพลาดใหญ่ของวิศวกรรม AI ยุคใหม่คือการสร้างตัวห่อ LLM ที่ทำทุกอย่างตั้งแต่คุยกับผู้ใช้ วิเคราะห์ข้อมูล ไปจนถึงตัดสินใจทางธุรกิจและเขียนฐานข้อมูล เมื่อให้ LLM คุมตรรกะธุรกิจ แอปจะสืบทอดข้อเสียทั้งหมด เช่น ความไม่กำหนดแน่นอน การเพ้อ การเปลี่ยนสคีมาแบบคาดเดาไม่ได้ และความหน่วงสูง สถาปัตยกรรมที่ดีกว่าคือการตั้งกฎชัดว่า LLM เป็นอวัยวะรับความรู้สึกไม่ใช่สมอง ให้หน้าที่เดียวคือแปลงข้อความสนทนาของนักพัฒนาให้เป็นอ็อบเจ็กต์ JSON ที่มีโครงสร้างเฉพาะเช่น { topic, choice } แล้วให้แกน CQRS แบบเชิงกำหนดแน่นอนจัดการคำนวณและตัดสินใจต่อไป
แปลงผลจาก LLM เป็นข้อมูลแบบ typed เพื่อสร้างระบบ AI ที่เชื่อถือได้
หัวใจของระบบ AI ที่เชื่อถือได้ไม่ใช่โมเดลที่ฉลาดที่สุด แต่คือขอบเขตความรับผิดชอบที่คมชัดระหว่าง LLM กับแกนตรรกะแอป การแปลงผลลัพธ์จาก LLM ให้เป็นโครงสร้างข้อมูลที่กำหนดไว้ชัดเจน เช่นอ็อบเจ็กต์ JSON แบบ typed ช่วยให้เราตรวจสอบ บันทึก และใช้ซ้ำได้อย่างปลอดภัย นักพัฒนาสามารถให้ผู้ใช้พิมพ์ข้อความธรรมชาติ เช่น การเลือกฐานข้อมูลหรือเฟรมเวิร์ก แล้วให้ LLM ทำหน้าที่เดียวคือดึงหัวข้อและตัวเลือกที่สำคัญ ผลลัพธ์ที่ออกมาเป็นโครงสร้างข้อมูลจึงกลายเป็นสัญญาณเชิงธุรกิจที่ใช้ได้ต่อ โดยไม่ปล่อยให้คำตอบเชิงภาษาวนกลับไปครอบงำตรรกะระบบ
สถาปัตยกรรมที่มีการกำหนดสคีมาชัดเจนจะกำหนดค่า temperature ต่ำและใช้การบังคับสคีมา JSON ที่ระดับเอ็นจินเพื่อบีบให้โมเดลส่งออกเฉพาะสัญญาณที่ตรงรูปแบบที่ต้องการ เช่น { topic: string, choice: string } พร้อม responseMimeType เป็น application/json ด้วยการตรึงค่า temperature ไว้ที่ 0.1 และให้ runtime บังคับ responseSchema เอาต์พุตจะถูกจำกัดให้เป็น JSON ที่ถูกไวยากรณ์และตามสคีมาที่กำหนด จากนั้นแอปยังสามารถตรวจสอบค่าภายในเพิ่มเติมเพื่อกันความหมายเพี้ยนก่อนคำนวณในแกน CQRS ที่เชิงกำหนดแน่นอน โดยการจำกัด LLM ไว้ที่งาน extraction ทำให้เรากลายคำสนทนายุ่งเหยิงให้เป็นข้อมูลเชิงโครงสร้างที่ผู้ใช้ยินดีจ่ายเพื่อเก็บรักษา
ออกแบบ LLM fallback pattern และ offline parser ให้บริการไม่สะดุด
ปัญหาของหลายแอปที่โฆษณาตัวเองว่าเป็น AI เนทีฟคือเมื่ออินเทอร์เน็ตหาย แอปแทบใช้งานไม่ได้ เพราะทุกการแตะและทุกข้อความของผู้ใช้ถูกส่งไปให้ LLM บนคลาวด์ เกิดวงล้อโหลดไม่จบระหว่างนั่งรถไฟใต้ดิน หรือเดโมพังในงานคอนเฟอเรนซ์ที่สัญญาณไม่เสถียร แนวคิด LLM fallback pattern จึงสำคัญอย่างยิ่ง คือการสร้างสายพานการประมวลผลหลายชั้นที่ลดระดับอย่างนุ่มนวลจาก LLM บนคลาวด์ลงสู่ heuristic ในเครื่อง โดยยังให้ผู้ใช้บันทึกการตัดสินใจและตรวจจับความเบี่ยงเบนได้แม้โมเดลจะล่มหรือไม่มีคีย์
สถาปัตยกรรมที่ดีจะมี Fallback Cascade ที่ชัดเจน เมื่อผู้ใช้พิมพ์ข้อความเข้าช่องระบบ ข้อมูลจะไหลผ่านชั้นแรกคือ LLM บนคลาวด์ที่ทำ extraction แบบมีโครงสร้างและตั้ง circuit breaker เวลาตอบรวมทั้ง backoff กรณีโดน rate limit ถ้าเน็ตล้ม หมดเวลา หรือไม่พบคีย์ API จะเด้งลงชั้นสองคือตัวแยกแบบ heuristic ภายในเครื่องที่เขียนด้วยภาษาโปรแกรมโลคัล ใช้ regex และคีย์เวิร์ด วิเคราะห์ขอบเขตโดเมนและ scope และกรองการคุยเล่นด้วยการส่งคืนค่า null แนวคิดสำคัญคือไม่ปล่อยให้การพร้อมใช้งานของ API ภายนอกกลายเป็นจุดล้มเหลวเดียวของประสบการณ์ผู้ใช้หลัก
ออกแบบ offline parser ให้ทำงานหลักต่อได้แม้ไม่มี LLM
หากเราจริงจังกับความต่อเนื่องของบริการ จำเป็นต้องมี offline parser ที่ทำหน้าที่เป็นสมองสำรองเมื่อ LLM ไม่พร้อมใช้งาน แนวทางที่ได้ผลคือสร้างเอนจินตกผลึกในเครื่องที่ไม่ต้องพึ่งเครือข่ายและไลบรารีภายนอก ให้สามารถจำแนกข้อความผู้ใช้เป็นสัญญาณการตัดสินใจจาก heuristic ที่ชัดเจน เช่น ตรวจว่ามีชื่อฐานข้อมูล คำที่เกี่ยวกับขอบเขตงาน หรือเฟรมเวิร์กฝั่งหน้าเว็บ แล้วกำหนด topic และ choice ให้เหมาะสม ถ้าข้อความดูเป็นการพูดเล่นหรือไม่ใช่การตัดสินใจก็ส่งกลับเป็น null เพื่อไม่ให้แกนระบบปนข้อมูลที่ขาดความหมาย
ตัวอย่าง offline parser จะเริ่มจากแปลงข้อความเป็นตัวพิมพ์เล็ก ตั้งตัวแปร topic ว่าง และใช้ข้อความเป็นค่าเริ่มต้นของ choice จากนั้นตรวจคีย์เวิร์ดเฉพาะฐานข้อมูลอย่าง postgres mongo supabase firebase และตรวจคำขอบเขตเช่น scope mvp mock prototype full crud landing page ถ้าพบคำขอบเขตและไม่พบฐานข้อมูลจะตั้ง topic เป็น Scope แล้วแมป choice ไปเป็น Mock / Prototype Only หรือ Full Feature Build ตามคีย์เวิร์ด ถัดมาคือกฎฐานข้อมูล กฎเฟรมเวิร์กฝั่งหน้าเว็บ เช่น react vue react native และกฎสถาปัตยกรรม เช่น monolith microservices พร้อมตั้ง choice เป็น Microservices หรือ Monolith ตามข้อความ ถ้าไม่เข้าเกณฑ์ใดเลยจะส่งคืน null เพื่อกรองข้อความที่ไม่ใช่การตัดสินใจ เอนจินเช่นนี้รันในเครื่องได้เต็มที่และเก็บสัญญาณทุกอย่างลงสตอเรจโลคัลแม้ไม่มีคลาวด์ช่วย
ติดตามความเบี่ยงเบนของการตัดสินใจและสรุปบทเรียนสถาปัตยกรรม
ประเด็นที่หลายทีมมองข้ามคือการติดตามความเบี่ยงเบนของการตัดสินใจ เมื่อหลายคนในทีมพูดถึงหัวข้อเดียวกันด้วยคำคนละแบบ เช่น DB กับ Database โมเดลอาจแตก topic ออกเป็นหลายชุด ทำให้การคำนวณฉันทามติและการครอบครองงานยุ่งยาก การออกแบบชั้น extraction ให้เป็น typed signal เดียวและให้แกน CQRS รวมความหมายเชิงโดเมนเข้าด้วยกันจึงเป็นวิธีที่ช่วยลดการแตกกระจายของหัวข้อ การมีประวัติสัญญาณที่ต่อเนื่องไม่ว่าจะออนไลน์หรือออฟไลน์ยังช่วยให้ผู้ใช้ตรวจสอบย้อนหลังได้ว่าใครตัดสินใจอะไรเมื่อไร และเห็นได้ชัดเมื่อแนวทางเริ่มเบี่ยงจากข้อตกลงเดิม
เมื่อระบบออกแบบแบบ offline first ผู้ใช้ระดับสมาชิกที่ต้องการความเชื่อถือจะสามารถพึ่งแอปในฐานะบันทึกการทำงานที่เปลี่ยนแปลงไม่ได้ของการส่งงานของทีมได้แม้โมเดลหรือเครือข่ายจะล่ม แนวคิดสำคัญคือการไม่ให้ LLM เป็นศูนย์กลางสมองของระบบ แต่ให้เป็นประสาทสัมผัสที่ส่งสัญญาณแบบมีโครงสร้างไปยังแกนเชิงกำหนดแน่นอนเท่านั้น ส่วน offline parser และ fallback pattern ทำหน้าที่เสริมให้ประสบการณ์ยังไหลลื่นในทุกสภาพสัญญาณ เมื่อทีมออกแบบด้วยมุมมองนี้ ระบบ AI ที่เชื่อถือได้จะไม่ใช่แค่คำโฆษณา แต่กลายเป็นคุณสมบัติพื้นฐานที่ผู้ใช้สัมผัสได้ทุกครั้งที่อินเทอร์เน็ตสะดุด
