Architecture and Generative AI (สถาปัตยกรรมกับ Generative AI)

ขณะที่เรากำลังเขียนหนังสือเล่มนี้ฉบับพิมพ์ครั้งที่สองในต้นปี 2025 generative artificial intelligence (Gen AI) และ large language models (LLMs) ได้แทรกซึมเข้าไปในโลกของการพัฒนาซอฟต์แวร์และการออกแบบซอฟต์แวร์ หลายบริษัทกำลังนำสิ่งเหล่านี้เข้ามาผสานในระบบเพื่อทำงานที่แต่ก่อนต้องทำด้วยมนุษย์เท่านั้น ไม่น่าแปลกใจที่ Gen AI มาบรรจบกับสถาปัตยกรรมซอฟต์แวร์ด้วยเช่นกัน สถาปนิกกำลังนำ LLM เข้ามาผสานในสถาปัตยกรรมซอฟต์แวร์ และบางคนก็ใช้เครื่องมือ Gen AI ช่วยคิดแก้ปัญหายากๆ ด้วย

Incorporating Generative AI into Architecture (การนำ Generative AI มาผสานในสถาปัตยกรรม)

แนวทางหนึ่งที่เราแนะนำสำหรับการนำ Gen AI มาผสานในสถาปัตยกรรมคือการใช้ประโยชน์จาก abstraction และ modularity สิ่งสำคัญคือต้องสามารถแทนที่ LLM ตัวหนึ่งด้วยอีกตัวหนึ่งได้อย่างรวดเร็ว และต้องเปิดทางให้มี guardrail (rails) และประเมินผลลัพธ์ (evals) จาก LLM หลายตัวได้

ตัวอย่างเช่น สมมติว่าบริษัทหางานต้องการใช้ Gen AI เพื่อทำให้ résumé เป็นแบบไม่ระบุตัวตน (anonymize) โดยมีเป้าหมายเพื่อลด bias และมุ่งเน้นไปที่ทักษะของผู้หางานมากกว่าข้อมูลประชากรหรือปัจจัยอื่นๆ ในลักษณะนั้น งานนี้ปกติทำโดยมนุษย์ แต่ LLM สามารถทำได้ง่ายเช่นกัน แต่ผลลัพธ์ของ LLM แม่นยำหรือไม่? มันลบข้อมูลออกจาก résumé มากเกินไปหรือเปล่า? มันเก็บข้อมูลประชากรไว้มากเกินไปหรือไม่? สำหรับระบบประเภทนี้ การรวบรวมตัวอย่างและ metric แล้วเปรียบเทียบ LLM engine เป็นเรื่องสำคัญมาก เครื่องมืออย่าง Langfuse ช่วยสร้าง observability แบบนี้ภายในสถาปัตยกรรมได้

Generative AI as an Architect Assistant (Generative AI ในฐานะผู้ช่วยสถาปนิก)

เมื่อได้รับ prompt ที่เหมาะสม LLM (เช่น Copilot ) สามารถสร้าง source code ที่ช่วยประหยัดเวลาและความพยายามของ developer ได้มาก มันเหมาะกับการแก้ปัญหาที่เจาะจงและมี deterministic ชัดเจน เช่น “เขียน source code ในภาษา C# ที่สร้างเลข PIN สี่หลักที่ไม่ซ้ำกันและไม่มีตัวเลขซ้ำ” แต่เทคโนโลยี LLM สามารถช่วยสถาปนิกซอฟต์แวร์ในงานทั่วไปได้หรือไม่? ต่อไปนี้เป็นตัวอย่าง prompt ทั่วไปที่เกี่ยวข้องกับสถาปัตยกรรม

  • Risk assessment: “มีพื้นที่เสี่ยงในสถาปัตยกรรมนี้หรือไม่?”

  • Risk mitigation: “ฉันควรจัดการความเสี่ยงนี้อย่างไร?”

  • Antipatterns: “มี antipattern ทั่วไปในสถาปัตยกรรมนี้หรือไม่?”

  • Decisions: “ฉันควรใช้ orchestration หรือ choreography สำหรับ workflow นี้?”

ณ เวลาที่เขียนฉบับพิมพ์ครั้งที่สองนี้ (ต้นปี 2025) เรายังไม่ประสบความสำเร็จมากนักกับความพยายามนี้ การถาม LLM ว่า microservices หรือ space-based architecture เหมาะสมที่สุดสำหรับสถานการณ์หนึ่งๆ นั้นแทบจะไม่เคยให้คำตอบที่ถูกต้อง เพราะเหตุใด? เพราะดังที่เราแสดงให้เห็นตลอดทั้งเล่มนี้ ทุกอย่างในสถาปัตยกรรมซอฟต์แวร์ล้วนเป็น trade-off LLM เก่งเรื่องการเข้าใจ ความรู้ แต่จนถึงทุกวันนี้ยังขาด ปัญญา (wisdom) ที่จำเป็นในการตัดสินใจอย่างเหมาะสม ปัญญานั้นรวมถึงบริบทมากมายจนสถาปนิกแก้ปัญหาทางธุรกิจด้วยตัวเองได้เร็วกว่าการสอน LLM ให้เข้าใจปัญหาและสภาพแวดล้อมและบริบทที่ขยายออกไปทั้งหมด การที่เราได้รวมจุดตัดอื่นอีกแปดจุดที่ต้องกังวลไว้ในหนังสือเล่มนี้ก็เพียงพอที่จะเป็นหลักฐานว่านี่เป็นงานที่หนักหนาสาหัส

กระนั้นก็ตาม เราเห็นเครื่องมือบางตัวที่มีความหวัง ตัวอย่างเช่น Thoughtworks Haiven สามารถตีความ diagram สถาปัตยกรรมและอธิบายสถาปัตยกรรมซอฟต์แวร์ได้อย่างครบถ้วน ช่วยประหยัดงานที่ต้อง export diagram เป็น machine-readable format อย่าง XML แล้วนำไป prompt LLM เมื่อ import ข้อมูลนั้นแล้ว ผู้ใช้สามารถถามคำถามง่ายๆ เกี่ยวกับสถาปัตยกรรมกับ Haiven ได้ เช่น ว่ามันสามารถระบุ bottleneck หรือปัญหาใดๆ ได้หรือไม่ ความพยายามอื่นๆ รวมถึงการใช้ LLM แปล diagram แบบ PlantUML หรือคำอธิบายสถาปัตยกรรมแบบ pseudolanguage ให้เป็น executable ArchUnit code เพื่อควบคุมโครงสร้างของระบบ กิจกรรมมากมายกำลังเกิดขึ้นในด้านนี้ จึงคาดว่าจะมีการเปลี่ยนแปลงอย่างรวดเร็วในปีต่อๆ ไป ว่า Gen AI จะช่วยสถาปนิกได้อย่างไร .