ผมนำ AI Agent มาใช้จัดการกับตั๋วสนับสนุนย้อนหลัง 20 ปี

เรามีระบบ helpdesk ที่มีตั๋ว (tickets) กว่าหนึ่งล้านรายการ มีคู่มือ 2,400 เล่ม และมี codebase ขนาดใหญ่สองชุด

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

ผมจึงสร้าง AI agent ขึ้นมาเพื่อจัดการกับข้อมูลทั้งหมดนี้ และตอนนี้มันถูกนำไปใช้งานจริง (production) แล้ว นี่คือสิ่งที่เกิดขึ้นจริง

ข้อมูลไม่ใช่ส่วนที่ยากที่สุด แต่การรู้ว่าต้องไปหาที่ไหนต่างหากที่ยาก และการทำให้ agent เลิก "มโน" (hallucinate) ข้อมูลขึ้นมาเองนั้นยากยิ่งกว่า

วิธีการทำงาน:

  • agent ตัวเดียวที่รับอินพุตเป็นภาษาธรรมชาติ
  • อ่านฐานข้อมูล helpdesk, เครื่องมือจัดการโปรเจกต์, GitLab และ SVN
  • ทำการค้นหาแบบ vector (vector searches) จากคู่มือและตั๋วเก่าๆ
  • สามารถสร้างไฟล์อย่าง .xlsx หรือ .docx ได้
  • เลือกใช้เครื่องมือด้วยตัวเองและทำงานแบบขนาน (parallel)

สถาปัตยกรรมนั้นเรียบง่าย มันทำงานใน Node container ที่แยกออกจากแอปหลัก ผมทำแบบนี้เพื่อแยกส่วนความล้มเหลว (failure isolation) หาก AI ทำงานผิดพลาด ระบบ helpdesk ก็ยังคงทำงานต่อไปได้

บทเรียนที่สำคัญที่สุดคือเรื่อง prompt ผมเริ่มจากการใช้ข้อความยาวเหยียดเพียงชุดเดียว ซึ่งมีขนาดถึง 40,000 tokens มันดูแลรักษายากและทำให้ agent เสียสมาธิ (lost focus)

ผมเปลี่ยนวิธีการใหม่ โดยแบ่ง prompt ออกเป็นไฟล์ทักษะ (skill files) ขนาดเล็ก

  • การค้นหาตั๋วคือหนึ่งไฟล์
  • ประวัติโค้ดคืออีกหนึ่งไฟล์
  • การจัดการโปรเจกต์คือไฟล์ที่สาม

Prompt หลักจะทำหน้าที่เป็น router โดยจะโหลดทักษะเฉพาะเมื่อจำเป็นเท่านั้น วิธีนี้ช่วยลดจำนวน tokens จาก 40,000 เหลือเพียง 8,000 ต่อการร้องขอ (request) ทำให้ agent จดจ่อกับงานได้ดีขึ้นและโค้ดก็อัปเดตได้ง่าย

ผมยังเพิ่ม user profiles เข้าไปด้วย นักพัฒนาจะได้รับเส้นทางของโค้ด (code paths) ส่วนผู้จัดการโปรเจกต์จะได้รับสรุปสถานะ โดยที่ agent จะรู้เองว่าใครเป็นคนถามโดยไม่ต้องบอก

มันไม่ได้สมบูรณ์แบบ เราพบกับความล้มเหลวที่เกิดขึ้นจริง:

  • Hallucinations: agent สร้าง URL ปลอมขึ้นมา วิธีแก้: กำหนดรูปแบบที่แน่นอน (pin exact patterns) หรือบังคับให้ทำการค้นหาข้อมูล (lookup)
  • Memory loss: agent ลืมกฎเกณฑ์ในการสนทนาที่ยาวนาน วิธีแก้: ใส่รายการสิ่งที่ต้องทำ (to-do list) ที่มีโครงสร้างชัดเจนเข้าไปในทุกๆ รอบการสนทนา
  • Infinite loops: agent เรียกใช้เครื่องมือมากเกินไป วิธีแก้: กำหนดงบประมาณ (budget) ที่เข้มงวดต่อการร้องขอหนึ่งครั้ง
  • Safety: ผู้ใช้พยายามหลอกล่อมัน วิธีแก้: อย่าพึ่งพาแค่ prompt ในเรื่องความปลอดภัย แต่ให้ใช้สิทธิ์การเข้าถึงฐานข้อมูลแบบอ่านอย่างเดียว (read-only) ในโครงสร้างพื้นฐานของคุณแทน

งานที่แท้จริงคือการทำลูปรายสัปดาห์ ผมอ่าน log, ให้คะแนนเซสชัน (sessions), ปรับแต่งทักษะ และอัปเดตโปรไฟล์

หากคุณข้ามลูปนี้ไป คุณจะได้แค่ตัวสาธิต (demo) แต่ถ้าคุณทำมัน คุณจะได้ผลิตภัณฑ์ (product)

เป้าหมายไม่ใช่แค่การได้คำตอบที่เร็วขึ้น แต่คือการรักษาความรู้ขององค์กร (institutional knowledge) เอาไว้ เมื่อคนลาออกไป ความรู้ของเขาก็ยังคงอยู่ในบันทึกการสนทนา

สรุปสำหรับการสร้างของคุณ:

  • เริ่มต้นด้วย RAG จากประวัติข้อมูลของคุณเอง
  • ใช้ไฟล์ทักษะแบบ lazy-loaded แทนการใช้ prompt ขนาดใหญ่เพียงอันเดียว
  • ใช้ user profiles เพื่อบริบทที่ปรับแต่งตามบุคคล
  • แยก AI ไว้ใน container ของตัวเอง
  • บังคับใช้ความปลอดภัยผ่านโครงสร้างพื้นฐาน ไม่ใช่ผ่านคำสั่ง
  • อ่าน log ของคุณทุกสัปดาห์

Source: https://dev.to/nunc/i-put-an-ai-agent-in-front-of-20-years-of-support-tickets-heres-what-actually-broke-5gdd

Optional learning community: https://t.me/GyaanSetuAi