Blog

  • ลองสร้าง AI Chatbot บน AWS: จาก Bedrock ถึง Next.js แบบ Serverless

    ลองสร้าง AI Chatbot บน AWS: จาก Bedrock ถึง Next.js แบบ Serverless

    ช่วงนี้ผมกำลังทดลองสร้าง AI Chatbot โดยใช้ AWS เป็น Backend หลัก

    โจทย์ไม่ได้ซับซ้อนมาก

    ผมต้องการ Chatbot ที่รับคำถามจากหน้าเว็บ เช่น

    “IMOTIF ให้บริการอะไรบ้าง?”

    แล้วส่งคำถามไปให้ AI ประมวลผล ก่อนส่งคำตอบกลับมาแสดงบนหน้าเว็บ

    Architecture ที่ใช้ตอนนี้ประมาณนี้

    Next.js → API Gateway → AWS Lambda → Amazon Bedrock

    ข้อดีคือไม่ต้องเปิด Server รันตลอดเวลา และแต่ละส่วนสามารถแยกออกจากกันได้ค่อนข้างชัดเจน

    1. Amazon Bedrock ทำหน้าที่เป็น AI Engine

    Amazon Bedrock เป็นบริการของ AWS สำหรับเรียกใช้งาน Foundation Model ผ่าน API

    แทนที่จะต้องติดตั้งหรือ Host LLM เอง เราสามารถส่ง Prompt ไปยัง Model แล้วรับคำตอบกลับมาได้เลย

    Concept ง่าย ๆ คือ

    User Question
          ↓
    Amazon Bedrock
          ↓
    AI Response
    

    แต่ในระบบจริง เราไม่ควรให้ Browser เรียก Bedrock โดยตรง

    เพราะจะมีเรื่อง Credentials, Security และ Business Logic เข้ามาเกี่ยวข้อง

    จึงต้องมี Backend คั่นกลาง

    2. ใช้ AWS Lambda เป็น Backend

    ใน POC นี้ผมเลือกใช้ AWS Lambda

    Lambda คือ Serverless Compute ของ AWS

    เราเขียน Function ขึ้นมา เช่น

    POST /chat
    

    เมื่อได้รับข้อความ

    {
      "message": "IMOTIF ให้บริการอะไรบ้างครับ"
    }
    

    Lambda จะนำข้อความไปเรียก Amazon Bedrock

    แล้วคืน Response กลับมา

    ตัวอย่าง

    {
      "answer": "IMOTIF ให้บริการ Odoo ERP, Software Development, Cloud Service และ AI Integration"
    }
    

    ข้อดีของ Lambda สำหรับงานลักษณะนี้คือ

    • ไม่ต้องดูแล Server
    • ไม่ต้องเปิด EC2 ทิ้งไว้
    • Scale ตาม Request
    • เหมาะกับ Prototype และ API ที่ไม่ได้มี Traffic ตลอดเวลา

    สำหรับการเริ่มทำ AI Application ผมมองว่านี่เป็น Architecture ที่ค่อนข้างน่าสนใจ

    3. ใช้ API Gateway เปิด Endpoint ให้ Frontend เรียก

    Lambda อย่างเดียว Browser ยังเรียกใช้งานได้ไม่สะดวก

    จึงใช้ Amazon API Gateway เป็นตัวรับ HTTP Request

    Architecture จึงกลายเป็น

    Next.js
       ↓
    POST /chat
       ↓
    API Gateway
       ↓
    Lambda
       ↓
    Amazon Bedrock
    

    ในกรณีนี้ผมใช้ HTTP API

    สำหรับ API เล็ก ๆ แบบ Chat Endpoint ผมมองว่า HTTP API เพียงพอ และ Setup น้อยกว่า REST API

    เมื่อ Deploy แล้วจะได้ URL ลักษณะประมาณ

    https://xxxxx.execute-api.ap-southeast-7.amazonaws.com/default/chat
    

    เราสามารถ Test ด้วย curl ก่อนต่อ Frontend

    curl -X POST \
      https://xxxxx.execute-api.ap-southeast-7.amazonaws.com/default/chat \
      -H "Content-Type: application/json" \
      -d '{"message":"IMOTIF ให้บริการอะไรบ้างครับ"}'
    

    ถ้าได้ Response กลับมา แปลว่า Backend Pipeline ทำงานแล้ว

    4. ทำไมต้อง Test ด้วย curl ก่อน

    จุดนี้สำคัญกว่าที่คิด

    ตอนแรกผมพยายามต่อ Frontend เลย

    ผลคือ

    Bad Request

    แล้วก็เริ่มไล่ดู Next.js
    ไล่ดู Environment Variable
    ไล่ดู API Gateway
    ไล่ดู Lambda

    ทั้งที่วิธี Debug ที่ง่ายกว่าคือแยกระบบออกเป็นชั้น ๆ

    เริ่มจาก

    Lambda → Bedrock
    

    ให้ทำงานก่อน

    จากนั้น

    API Gateway → Lambda → Bedrock
    

    แล้ว Test ด้วย curl

    เมื่อ Backend ทำงานแน่นอนแล้ว ค่อยต่อ

    Next.js → API Gateway
    

    วิธีนี้ลดพื้นที่ในการหา Bug ได้เยอะมาก

    เป็นหลักพื้นฐาน แต่พอทำระบบหลาย Layer พร้อมกัน เรามักลืมมัน

    5. ต่อ Next.js เป็น Chat UI

    เมื่อ API ใช้งานได้แล้ว Frontend ค่อนข้างตรงไปตรงมา

    Concept คือ

    const response = await fetch(`${apiBaseUrl}/chat`, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        message,
      }),
    });
    

    รับ JSON กลับมา

    const data = await response.json();
    

    แล้วแสดง

    data.answer
    

    แค่นี้เราก็ได้ AI Chatbot พื้นฐานที่ Frontend และ Backend แยกออกจากกันแล้ว

    6. โครงสร้างนี้เหมาะกับ Production ไหม

    ถ้าเป็น POC หรือ MVP ผมคิดว่าเหมาะมาก

    แต่ถ้าจะใช้จริง ยังมีหลายเรื่องที่ต้องเพิ่ม

    เช่น

    Authentication

    ใครสามารถเรียก Chat API ได้บ้าง

    ถ้าเปิด Public Endpoint ทิ้งไว้ ใครก็สามารถเรียก API และทำให้เกิดค่าใช้จ่ายได้

    Rate Limit

    ควรกำหนดจำนวน Request ต่อ User หรือ IP

    Conversation History

    ตอนนี้แต่ละคำถามอาจเป็น Stateless

    แต่ Chatbot จริงควรเข้าใจ Conversation ก่อนหน้า

    Knowledge Base

    ถ้าอยากให้ Bot ตอบเรื่องบริษัทได้แม่นขึ้น ไม่ควรเอาข้อมูลทั้งหมดใส่ Prompt

    แต่ควรใช้แนวทางอย่าง

    RAG — Retrieval-Augmented Generation

    ให้ระบบค้นข้อมูลที่เกี่ยวข้องก่อน แล้วส่งเฉพาะ Context ที่จำเป็นให้ AI

    Logging

    ต้องรู้ว่า User ถามอะไร

    AI ตอบอะไร

    ใช้ Token เท่าไร

    และ Error เกิดที่ Layer ไหน

    7. ขั้นต่อไปคือทำให้ AI รู้จักข้อมูลของบริษัท

    Chatbot ที่เรียก LLM ได้ยังไม่ได้แปลว่าเป็น Business AI

    สิ่งที่น่าสนใจกว่าคือ

    ถ้า Chatbot สามารถเข้าถึง

    • Product
    • Service
    • FAQ
    • CRM
    • Sales
    • ERP
    • Inventory
    • Accounting

    ของบริษัทได้ จะเกิดอะไรขึ้น

    ตัวอย่างเช่น

    แทนที่จะถามว่า

    IMOTIF ให้บริการอะไรบ้าง

    อาจถามได้ว่า

    เดือนนี้มี Lead ใหม่กี่ราย

    หรือ

    ลูกค้ารายไหนมี Quotation ที่ยังไม่ได้ Follow up

    หรือ

    Product ตัวไหน Stock ต่ำกว่าระดับที่กำหนด

    ตรงนี้ทำให้ Chatbot เริ่มเปลี่ยนจาก

    AI Chat

    ไปเป็น

    AI Business Interface

    และนี่เป็นส่วนที่ผมคิดว่าน่าสนใจกว่า Chatbot ทั่วไปมาก

    เพราะเป้าหมายสุดท้ายของ AI ในองค์กรอาจไม่ใช่การมี Chatbot อีกหนึ่งตัว

    แต่คือการทำให้คนสามารถ คุยกับข้อมูลและระบบของตัวเองได้โดยตรง

  • Yordja กลับมาแล้ว: Technology, Business & Sound

    หลายปีที่ผ่านมา ผมใช้เวลาส่วนใหญ่อยู่กับการทำงานด้าน Technology และการสร้างธุรกิจ ตั้งแต่ Software Development, ERP, Cloud ไปจนถึง Artificial Intelligence

    ระหว่างทางมีหลายเรื่องที่ผมได้ลองทำ ได้เรียนรู้ และบางครั้งก็ทำพลาด แต่กลับไม่ได้เขียนหรือบันทึกมันเอาไว้มากนัก

    วันนี้เลยอยากกลับมาเขียนอีกครั้ง

    และนี่คือเหตุผลที่ Yordja.com กลับมา

    ทำไมถึงกลับมาเขียน Blog?

    ทุกวันนี้เวลาอยากรู้อะไร เราสามารถถาม AI แล้วได้คำตอบภายในไม่กี่วินาที

    ผมเองก็ใช้ AI แทบทุกวัน ทั้งในการเขียน Code, Research, วิเคราะห์ Business Idea ไปจนถึงช่วยคิด Architecture ของระบบ

    ยิ่ง AI เก่งขึ้น ผมกลับยิ่งรู้สึกว่า ประสบการณ์จริงของคนมีคุณค่ามากขึ้น

    AI สามารถอธิบายได้ว่า AWS Lambda คืออะไร

    แต่สิ่งที่ผมอยากอ่านมากกว่าคือ

    คนที่ลองเอา Lambda ไปสร้าง Product จริง เลือก Architecture อย่างไร เจอปัญหาอะไร และสุดท้ายมันเวิร์กหรือไม่เวิร์ก

    AI สามารถอธิบายว่า ERP คืออะไร

    แต่ประสบการณ์จากการ Implement ERP จริง ตั้งแต่คุย Requirement, Estimate, Customize, UAT จนถึงวันที่ระบบขึ้น Production เป็นเรื่องอีกแบบหนึ่ง

    ผมจึงอยากให้ Yordja เป็นพื้นที่สำหรับเรื่องเหล่านี้

    ไม่ใช่แค่ What is…

    แต่รวมถึง I tried this. Here’s what happened.

    Technology

    Technology เป็นเรื่องหลักที่ผมน่าจะเขียนมากที่สุด

    ช่วงนี้ผมสนใจเป็นพิเศษกับ AI, AI Agents, Software Development, ERP, Odoo, AWS และ Cloud

    ตัวอย่างหนึ่งคือช่วงที่ผ่านมา ผมเริ่มทดลองสร้าง AI Application ตั้งแต่ศูนย์

    จากการเขียน API ด้วย FastAPI ไปจนถึงการทดลอง AWS Bedrock, Lambda และ API Gateway

    สิ่งที่น่าสนใจสำหรับผมไม่ได้มีแค่ Code

    แต่เป็นคำถามว่า

    เราจะเอา Technology เหล่านี้ไปสร้างสิ่งที่มีประโยชน์กับธุรกิจจริงได้อย่างไร?

    นี่เป็นหัวข้อที่ผมน่าจะกลับมาเขียนอีกเยอะ

    Business

    อีกโลกหนึ่งของผมคือ Business

    การทำบริษัท Technology ทำให้ผมต้องสลับบทบาทอยู่ตลอดเวลา

    วันหนึ่งอาจกำลังคุย Requirement กับลูกค้า

    อีกวันหนึ่งกำลังดู Architecture กับ Developer

    บางวันคิดเรื่อง Sales, Marketing และ SEO

    และบางคืนกลับมานั่งคิดว่า Product ที่กำลังจะสร้างนั้น มีใครยอมจ่ายเงินจริงหรือเปล่า

    Technology ที่น่าสนใจจึงไม่ได้แปลว่าจะเป็น Business ที่ดีเสมอไป

    ผมอยากใช้พื้นที่นี้บันทึกเรื่องการสร้างบริษัท IT, Product, SaaS, ERP, Digital Transformation รวมถึงการทดลองสร้าง AI Product จากมุมของคนที่กำลังลงมือทำจริง

    ทั้งสิ่งที่ได้ผลและสิ่งที่ไม่ได้ผล

    แล้ว Sound มาเกี่ยวอะไรด้วย?

    นอกจาก Technology กับ Business แล้ว อีกสิ่งหนึ่งที่ผมชอบมานานคือดนตรี โดยเฉพาะ Synthesizers และ Keyboards

    ถ้ามองเผิน ๆ มันอาจไม่เกี่ยวกับ ERP หรือ AI เลย

    แต่สำหรับผมมันมีบางอย่างคล้ายกัน

    การนั่งอยู่หน้า Synthesizer แล้วเริ่มจากเสียงธรรมดา ๆ ก่อนจะปรับ Oscillator, Filter, Envelope และ Effect จนกลายเป็นเสียงใหม่

    ให้ความรู้สึกไม่ต่างจากการเริ่ม Project ด้วย Repository ว่าง ๆ แล้วค่อย ๆ สร้างบางอย่างขึ้นมา

    มันคือการทดลอง

    การเรียนรู้

    และการสร้าง

    เพราะฉะนั้นบางวัน Yordja อาจมีบทความเรื่อง AI Agent

    บางวันอาจเป็น Odoo หรือ AWS

    และบางวันอาจเป็น Synthesizer หรือ Keyboard ที่ผมกำลังเล่นอยู่

    ผมคิดว่านั่นแหละคือความเป็น Yordja

    แล้วต่อจากนี้?

    ผมไม่ได้ตั้งเป้าว่าจะทำ Yordja ให้เป็นเว็บไซต์ข่าว Technology หรือ Content Farm ที่ต้องมีบทความใหม่ทุกวัน

    ตรงกันข้าม

    ผมอยากเขียนจากสิ่งที่ กำลังทำจริง

    ถ้ากำลังทดลอง AI Agent ก็เขียนเรื่อง AI Agent

    ถ้ากำลัง Deploy ระบบบน AWS แล้วเจอปัญหา ก็เขียนสิ่งที่ได้เรียนรู้

    ถ้าเจอแนวคิดน่าสนใจจากการ Implement ERP ก็เอามาเล่า

    หรือถ้าวันนั้นกำลังสนุกกับ Synthesizer ตัวใหม่ ก็อาจเขียนเรื่องนั้นแทน

    เป้าหมายง่าย ๆ คือทำให้ Yordja กลายเป็น Digital Garden ของผมเอง

    พื้นที่สำหรับเก็บความคิด การทดลอง และสิ่งที่ได้เรียนรู้ระหว่างทาง

    และถ้าสิ่งเหล่านั้นเป็นประโยชน์กับคนอื่นด้วย ก็ยิ่งดี

    Technology, Business & Sound.

    Welcome to Yordja.