เกี่ยวกับลูกค้า
ผู้ให้บริการที่ปรึกษาและโซลูชันด้านความมั่นคงปลอดภัยไซเบอร์ระดับองค์กรในประเทศไทย ดำเนินงานสอดคล้องกับกรอบ NIST Cybersecurity Framework และ ISO/IEC 27001 ส่งมอบโครงการด้านความมั่นคงปลอดภัยไซเบอร์มาแล้วกว่า 500 โครงการ และเป็นพันธมิตรกับผู้ผลิตระดับโลก อาทิ Palo Alto Networks, CrowdStrike, Fortinet, Check Point, CyberArk, Splunk, Zscaler, SentinelOne, Imperva, Trellix และ Devo โดยราว 90% ของบุคลากรเป็นสายเทคนิค
AWS Partner: บริษัท จีเอเบิล จำกัด (มหาชน)
โจทย์ของลูกค้า
งาน presale กลายเป็นคอขวดของรายได้
การจัดทำข้อเสนอสำหรับงานความมั่นคงปลอดภัยไซเบอร์บน AWS หนึ่งฉบับ ต้องให้วิศวกรอาวุโสทำงานด้วยมือตั้งแต่วิเคราะห์ความต้องการ จับคู่รายการอุปกรณ์และบริการ ประเมิน man-day ตั้งราคา เขียนข้อเสนอ ไปจนถึงออกแบบโซลูชัน ลำดับงานนี้ใช้เวลาราว 5 man-day ของสถาปนิกต่อข้อเสนอหนึ่งฉบับ และใช้เวลารวมตั้งแต่รับโจทย์จนส่งข้อเสนอถึง 10.5 วัน
ตามมาด้วยปัญหา 3 ข้อ
ความเร็วเป็นตัวจำกัดจำนวนดีลที่ไล่ตามได้ จำนวนโอกาสทางธุรกิจที่ทีมตามได้ในหนึ่งไตรมาสถูกกำหนดด้วยความเร็วในการผลิตข้อเสนอ ไม่ใช่ด้วยจำนวนโอกาสที่มีอยู่จริง
การประเมินขนาดงานและราคาไม่สม่ำเสมอ มาตรฐานและสมมติฐานเรื่องอัตราอยู่ในหัวของแต่ละคน ไม่ได้อยู่ในระบบที่กำกับได้ วิศวกรสองคนจึงอาจประเมินงานที่ขอบเขตใกล้เคียงกันออกมาต่างกันอย่างมีนัยสำคัญ
การตั้งราคาด้วยมือมีความเสี่ยงทางการเงินจริง ราคา list price ของ AWS เปลี่ยนแปลงตลอด ตัวเลขที่ประกอบขึ้นด้วยมือจากราคาที่ล้าสมัย สุดท้ายกลายเป็นขาดทุนตอนส่งมอบ หรือไม่ก็ต้องไปคุยกับลูกค้าในเรื่องที่ไม่มีใครอยากคุย
หากไม่แก้ไข ความเสี่ยงเฉพาะหน้าคือการเสียโอกาสให้คู่แข่งที่ตอบเร็วกว่า และกำไรที่หายไปจากดีลที่ตั้งราคาต่ำเกินจริง ส่วนความเสี่ยงระยะยาวคือการขยายงาน presale ให้ทันความต้องการไม่ได้ เพราะสถาปนิกอาวุโสที่เขียนข้อเสนอคือคนกลุ่มเดียวกับที่ส่งมอบงานที่เก็บเงินได้ ปริมาณงาน presale กับกำลังการส่งมอบจึงแย่งทรัพยากรก้อนเดียวกันโดยตรง
ทำไมโจทย์นี้ต้องใช้ agentic AI
การผลิตข้อเสนอไม่ใช่งาน generative งานเดียวจบ แต่เป็นลำดับการตัดสินใจที่ต่อเนื่องกัน — เข้าใจความต้องการ เลือกสถาปัตยกรรม ประเมินขนาด ตั้งราคาจากอัตราจริง เขียนออกมา แล้วส่งเข้าสายอนุมัติ แต่ละขั้นต้องใช้ความรู้และเครื่องมือคนละชุด และความผิดพลาดตั้งแต่ต้นทางจะไหลไปถึงปลายทางโดยไม่มีใครเห็น
การใช้ prompt เดียวกับ large language model ทำงานนี้ให้เชื่อถือได้ไม่ได้ เพราะโมเดลไม่มีทางเปิดดูราคา AWS ปัจจุบัน และไม่มีเหตุผลเชิงโครงสร้างใดที่จะทำให้มันปฏิเสธการเดาตัวเลขขึ้นมาเอง สิ่งที่งานนี้ต้องการคือ agent ที่วางแผนได้ เรียกใช้เครื่องมือจริงกับข้อมูลจริง และถูกออกแบบมาให้ผลิตตัวเลขที่พิสูจน์ไม่ได้ไม่ได้ตั้งแต่แรก
โซลูชัน
G-Able ออกแบบและส่งมอบแพลตฟอร์มอัตโนมัติงาน presale แบบ multi-agent เข้าไปใน AWS account ของลูกค้าเอง ที่ Region Asia Pacific (Singapore)
ภาพรวม
Orchestrator วางแผนงานแต่ละชิ้นแล้วส่งต่อให้ sub-agent เฉพาะทาง — ด้านราคา ด้านสถาปัตยกรรมโซลูชัน ด้านการเขียนข้อเสนอ ด้านเอกสารออกแบบ ด้านคำแนะนำการอนุมัติ และด้านการสร้าง repository ที่มี gate กำกับ agent เหล่านี้เรียกเครื่องมือจริงกับข้อมูลสด ไม่ได้สร้างข้อความจากความรู้ในโมเดลเพียงอย่างเดียว ทุกข้อเสนอที่ถึงมือลูกค้าผ่าน gate อนุมัติโดยมนุษย์ และทุกตัวเลขในนั้นย้อนกลับไปหาการ lookup ราคาแบบสดได้
รายละเอียดเชิงเทคนิค
Agent runtime และการควบคุมลำดับงาน agent ทั้งหมดรันบน Amazon Bedrock AgentCore Runtime ทำให้ session ของ agent บริหารโดย AWS แทนที่จะเป็นคอนเทนเนอร์ที่ต้องดูแลเอง Orchestrator ใช้รูปแบบ hub — sub-agent เรียกหากันเองไม่ได้ เส้นทางข้ามที่อนุญาตมีเพียงเส้นเดียวคือจาก agent ด้านสถาปัตยกรรมไปยัง agent ด้านราคา ซึ่งรับประกันว่าไม่มีข้อเสนอแนะเชิงสถาปัตยกรรมใดถึงมือมนุษย์โดยไม่มีราคาที่ตรวจสอบแล้วแนบไปด้วย
การอนุมาน (Inference) ใช้ Amazon Nova Pro ผ่าน Amazon Bedrock สำหรับการอนุมานทั้งหมด และ Cohere Embed 3 Multilingual สร้าง embedding สำหรับการค้นคืนจากคลังมาตรฐานและราคาที่เก็บใน Amazon Bedrock Knowledge Bases การอนุมานทั้งหมดอยู่ในบริการที่ AWS บริหารจัดการภายใน Region เดียวกัน agent พัฒนาบนเฟรมเวิร์ก Strands
การไกล่เกลี่ยเครื่องมือ Amazon Bedrock AgentCore Gateway เปิดให้เข้าถึง knowledge base และเครื่องมือภายนอกผ่าน Model Context Protocol โดยแยกการเรียกใช้เครื่องมือออกจากการควบคุมลำดับงาน AgentCore Identity ให้ตัวตนเฉพาะของแต่ละ agent แทนการใช้ credential ร่วมกัน และ AgentCore Memory เก็บข้อจำกัดของลูกค้าข้าม session ทำให้ข้อจำกัดที่ลูกค้าบอกครั้งเดียวไม่ต้องเรียนรู้ใหม่ทุกครั้ง
การยึดโยงข้อเท็จจริง และเหตุผลที่ตัวเลขถูกกุขึ้นไม่ได้ agent ด้านราคาเรียก AWS Price List API สำหรับราคาต่อหน่วย และ AWS Cost Explorer สำหรับการใช้งานจริง จากนั้นตัว grounding validator เชิง deterministic จะปฏิเสธข้อความเชิงปริมาณใดก็ตามในเอกสารที่สร้างขึ้น หากย้อนกลับไปหาการ lookup สดเหล่านั้นไม่ได้ ส่วน agent ที่ทำหน้าที่เขียน ไม่มีสิทธิ์เข้าถึงเครื่องมือใดๆ เลย โดยการออกแบบ — ทำได้เพียงเรียบเรียงข้อเท็จจริงที่ผ่านการตรวจสอบแล้วเท่านั้น จึงไม่มีทางสร้างตัวเลขขึ้นมาเองในเชิงโครงสร้าง และเมื่อแหล่งข้อมูลราคาใช้งานไม่ได้ แพลตฟอร์มจะไม่ให้ตัวเลขออกมาเลย แทนที่จะให้ตัวเลขที่ยังไม่ได้ตรวจสอบ
สถานะที่คงทน ทุกการเปลี่ยนสถานะถูกเขียนลงบัญชี statusHistory แบบ append-only ใน Amazon DynamoDB ซึ่ง agent ส่วนติดต่อผู้ใช้ และ audit trail อ่านจากแหล่งเดียวกันทั้งหมด งานที่ถูกขัดจังหวะจะกลับมาทำต่อจากสถานะล่าสุดที่บันทึกไว้ ไม่ใช่ประกอบขึ้นใหม่จากความจำของ agent การตรวจสอบเชิงปฏิบัติการกับรายงานเชิงธุรกิจจึงอ้างอิงข้อมูลชุดเดียวกัน
แพลตฟอร์มและเครือข่าย เว็บแอปพลิเคชันที่ผู้ใช้เข้าถึง ชั้น API และ agent ที่รันบน EKS อยู่บน Amazon EKS ใน private subnet กระจายครบ 3 Availability Zone หลัง Application Load Balancer ที่มี AWS WAF ป้องกัน โดย Amazon Cognito ยืนยันตัวตนผู้ใช้ และ token ที่ได้ถูกตรวจสอบที่ AgentCore Gateway ทุก request AWS Lambda รันการเรียกเครื่องมือผ่าน Gateway และเส้นทาง dispatch แบบ event-driven Amazon S3 เก็บคลังมาตรฐาน Amazon ElastiCache รองรับชั้นโต้ตอบ และ Amazon SNS ร่วมกับ AWS Step Functions ประสานงานการแจ้งเตือนขออนุมัติแบบ asynchronous การเข้ารหัสข้อมูลที่จัดเก็บใช้ customer managed key ของ AWS KMS แยกตามโดเมนข้อมูล ส่วน secret เก็บใน AWS Secrets Manager และดึงมาใช้ตอน runtime ไม่ได้ฝังไว้ใน image Amazon CloudWatch และ Amazon Managed Service for Prometheus ดูแล metric log และ alarm
การส่งมอบ สภาพแวดล้อมทั้งหมดสร้างด้วย Terraform ผ่าน CI/CD pipeline ที่มี gate และขั้นอนุมัติด้วยมือ ไม่มีการเปลี่ยนแปลง infrastructure ใดขึ้น production ผ่านหน้า console
การกำกับดูแล: AI เสนอ มนุษย์ตัดสิน
การกำกับดูแลวางอยู่บน 3 กลไก และไม่มีกลไกใดพึ่งพาการที่โมเดลจะประพฤติตัวดี
- Gate อนุมัติโดยมนุษย์แบบบังคับ ทั้งตอนปล่อยข้อเสนอและตอนเปลี่ยนแปลง infrastructure โดยวิศวกรต้องตรวจเอกสารออกแบบที่ระบบสร้างก่อนนำไปใช้จริง
- การบังคับยึดโยงข้อเท็จจริง ตัวเลขที่ไม่มีหลักฐานรองรับถูกปฏิเสธด้วยโค้ดเชิง deterministic ไม่ใช่ด้วยคำสั่งใน prompt
- สิทธิ์ต่ำสุดโดยโครงสร้าง agent ที่เขียนเอกสารเข้าถึงเครื่องมือไม่ได้เลย การขยายขอบเขตตัวเองจึงไม่ใช่ทางเลือกที่มีอยู่
เนื้อหาภายนอกที่ดึงเข้ามาถูกหุ้มไว้ในฐานะ “ข้อมูล” ไม่ใช่ “คำสั่ง” เนื้อหาที่ไม่น่าเชื่อถือในคลังข้อมูลหรือใน input ของลูกค้าจึงเปลี่ยนพฤติกรรมของ agent ไม่ได้
ผลลัพธ์
วัดผลตลอดช่วง pilot และยืนยันโดยทีม presale ของลูกค้า
| ตัวชี้วัด | ก่อน | หลัง | เปลี่ยนแปลง |
| แรงงานสถาปนิกต่อข้อเสนอ | 5 man-day | 1 man-day | ลดลงราว 75% |
| ระยะเวลารวมต่อข้อเสนอ | 10.5 วัน | 2 วัน | เร็วขึ้นราว 81% |
| กำลังสถาปนิกอาวุโสที่คืนกลับมา | — | ~40 man-day/เดือน | ที่ปริมาณข้อเสนอปัจจุบัน |
ที่ปริมาณราว 10 ข้อเสนอต่อเดือน เท่ากับปลดปล่อยแรงงานสถาปนิกราว 4 man-day ออกจากทุกข้อเสนอที่ผลิต แพลตฟอร์มรันบนบริการ AWS แบบคิดตามการใช้งานและ On-Demand ทั้งหมด ไม่มีค่าใช้จ่ายล่วงหน้าและไม่มีข้อผูกมัด โดยค่าใช้จ่ายรายเดือนคืนทุนภายในข้อเสนอฉบับแรกที่ผลิตในแต่ละเดือน
นอกเหนือจากตัวเลข ยังมีผลลัพธ์เชิงคุณภาพอีก 2 ข้อที่สำคัญไม่แพ้กัน
- ความสม่ำเสมอของการตั้งราคา การประเมินขนาดงานและราคาถูกดึงมาจากชุดสมมติฐานที่กำกับได้ชุดเดียว ไม่ใช่จากความทรงจำของแต่ละคน งานที่ขอบเขตใกล้เคียงกันจึงถูกตั้งราคาสอดคล้องกัน
- กำลังคน ไม่ใช่แค่ความเร็ว การดึงแรงงานสถาปนิกราว 4 man-day ออกจากทุกข้อเสนอคือการคืนเวลานั้นกลับสู่งานส่งมอบที่เก็บเงินได้ ซึ่งเป็นข้อจำกัดทางธุรกิจที่แท้จริง และเป็นเหตุผลที่โครงการนี้เกิดขึ้น
เกี่ยวกับ G-Able
บริษัท จีเอเบิล จำกัด (มหาชน) เป็น Tech Enabler ชั้นนำของไทย ด้วยประสบการณ์กว่า 37 ปี ทำงานร่วมกับพันธมิตรเทคโนโลยีระดับโลกกว่า 100 ราย และให้บริการลูกค้าที่ใช้งานจริงกว่า 1,000 ราย งานด้าน AI ของ G-Able ครอบคลุมความมั่นคงปลอดภัยไซเบอร์ การปรับปรุงคลาวด์และศูนย์ข้อมูลให้ทันสมัย ข้อมูลและการวิเคราะห์ ธุรกิจดิจิทัลและแอปพลิเคชัน และบริการเทคโนโลยีแบบ managed ส่งมอบโดยทีมสถาปนิกโซลูชัน ทีม FinOps และทีมส่งมอบที่เชี่ยวชาญ AWS โดยเฉพาะ
สนใจว่า agentic AI จะช่วยงาน presale หรืองานส่งมอบขององค์กรท่านได้อย่างไร [ติดต่อ G-Able]