Name: Intermediate: สร้าง AI Agent จริง ต่อ RAG และเชื่อมด้วย MCP · หลักสูตร AI Agents อย่างมืออาชีพ
Author: จักริน นพรุจนธาดา

2.1

โมดูล 2.1

Tool-calling / Function-calling: กลไกที่ทำให้ agent ลงมือทำ

วงจรเบื้องหลังที่ทำให้ agent เลือกและเรียกใช้เครื่องมือเองได้ เป็นรากฐานของ agent ทุกตัวในปี 2026

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนช่างซ่อมที่มีกล่องเครื่องมือวางอยู่ข้างตัว เขามองงานตรงหน้าแล้วเลือกหยิบไขควงหรือค้อนเองว่าจะใช้อันไหน AI ก็มองคำถามแล้วเลือกหยิบ 'เครื่องมือ' ที่คุณเตรียมไว้ให้มันมาใช้เอง

🎯

ทำไมต้องรู้: นี่คือจุดที่ทำให้ AI 'ลงมือทำ' ได้จริง ไม่ใช่แค่พิมพ์ตอบ เช่น ไปดึงข้อมูลลูกค้า ส่งอีเมล หรือค้นราคาให้อัตโนมัติ ซึ่งเป็นหัวใจของ agent ทุกตัว

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

อธิบายวงจรของ tool-calling ได้ครบทั้งรอบ: บอกเครื่องมือด้วย JSON Schema, AI ตัดสินใจ, ส่งคำสั่งเรียกออกมา, ระบบทำงานจริง, แล้วป้อนผลลัพธ์กลับไปให้ AI
รู้ว่าแต่ละเจ้าเรียกไม่เหมือนกันแต่คือเรื่องเดียวกัน: OpenAI เรียก function calling, Anthropic เรียก tool use, Gemini ใช้ response_schema
บอกสาเหตุได้ว่าทำไมบางครั้ง agent ถึงวนไม่หยุด (loop) ค้างกลางทาง (stall) หรือเรียกเครื่องมือถี่เกินไป (over-call)

เนื้อหา

การให้ AI เรียกใช้เครื่องมือเอง (tool-calling หรือ function-calling) คือรากฐานของ agent ทุกตัว ของระบบ RAG และของการดึงข้อมูลแบบมีรูปแบบในปี 2026 พูดง่าย ๆ มันทำงานแบบนี้: คุณบอก AI ไว้ก่อนว่ามีเครื่องมืออะไรให้ใช้บ้าง โดยเขียนอธิบายเครื่องมือแต่ละตัว (function) เป็นแบบฟอร์มมาตรฐานที่เรียกว่า JSON Schema จากนั้นพอมีคำถามเข้ามา ตัว AI (model) ก็จะดูคำถามพร้อมรายการเครื่องมือทั้งหมด แล้วตัดสินใจเองว่าจะหยิบเครื่องมือไหนมาใช้ไหม พอตัดสินใจแล้วมันก็ส่งคำสั่งเรียกออกมาชัด ๆ ว่าจะใช้ตัวไหนและใส่ค่าอะไร ต่อมาโค้ดหรือ workflow ของคุณก็ไปทำงานนั้นจริง แล้วส่งผลลัพธ์กลับมาให้ AI ซึ่งมันอาจจะเรียกเครื่องมืออีกรอบ หรือตอบเลยก็ได้ วนแบบนี้ไปเรื่อย ๆ จนจบ แต่ละเจ้าเรียกไม่เหมือนกันแต่กลไกเดียวกันหมด: OpenAI เรียกว่า function calling (มี tools array กับ tool_calls อยู่ใน response), Claude ของ Anthropic เรียกว่า tool use, ส่วน Gemini ของ Google ใช้ response_schema ทั้ง OpenAI และ Anthropic ยังเรียกหลายเครื่องมือพร้อมกันในรอบเดียวได้ด้วย (parallel tool calls) ถ้าคุณใช้เครื่องมือแบบลากวางไม่ต้องเขียนโค้ด (no-code) คุณแทบไม่ต้องยุ่งกับเรื่องพวกนี้เลย เพราะ AI Agent node ของ n8n/Make/Zapier เขาเปิดคำสั่ง (action) ต่าง ๆ ให้ AI เลือกใช้เป็นเครื่องมือให้อยู่แล้ว แต่ถ้าคุณเข้าใจวงจรนี้ คุณจะเดาออกทันทีว่าทำไมบางทีเจ้า agent ถึงวนไม่หยุด ค้างกลางทาง หรือเรียกเครื่องมือถี่เกินจำเป็น

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Tool-calling / Function-callingความสามารถของ AI ที่เลือกและสั่งเรียกใช้เครื่องมือ (เช่น ค้นข้อมูล ส่งอีเมล) ได้เอง แทนที่จะแค่ตอบเป็นข้อความ

JSON Schemaแบบฟอร์มบอกกติกาว่าเครื่องมือแต่ละตัวชื่ออะไร ต้องกรอกข้อมูลอะไรบ้าง เขียนในรูปแบบมาตรฐานที่คอมพิวเตอร์อ่านเข้าใจ

Modelตัว AI สมองกล เช่น ChatGPT หรือ Claude ที่รับคำสั่งแล้วคิดและตัดสินใจ

Structured tool callคำสั่งเรียกเครื่องมือที่ AI ปล่อยออกมาแบบมีระเบียบชัดเจน บอกว่าจะใช้ตัวไหนและใส่ค่าอะไร ให้ระบบทำต่อได้ทันที

Argument (typed)ค่าที่ส่งให้เครื่องมือใช้ทำงาน โดยระบุชนิดชัดเจนว่าเป็นตัวเลข ข้อความ หรือวันที่ เพื่อลดข้อผิดพลาด

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

นิยาม tool ด้วย JSON Schema

นิยาม tool สำหรับให้ agent เช็คสถานะออเดอร์: { "name": "check_order_status", "description": "ตรวจสอบสถานะออเดอร์จากเลขที่ออเดอร์", "input_schema": { "type": "object", "properties": { "order_id": {"type": "string", "description": "เลขที่ออเดอร์ เช่น ORD-12345"} }, "required": ["order_id"] } }

✅ ผลลัพธ์ที่ได้

พอลูกค้าถามว่า "ออเดอร์ ORD-12345 ถึงไหนแล้ว" ตัว AI ก็จะปล่อยคำสั่งเรียกเครื่องมือออกมา: check_order_status({"order_id": "ORD-12345"}) → workflow ไปเรียก API จริง → ป้อนผลลัพธ์กลับมา → AI ก็ตอบลูกค้าเป็นภาษาไทย

💡 จุดสอน

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

เข้าใจว่าทำไม agent over-call

สถานการณ์: agent ตอบคำถามง่ายๆ แต่เรียก search tool ซ้ำ 5 ครั้งก่อนตอบ ทำให้ช้าและแพง เพราะอะไร?

✅ ผลลัพธ์ที่ได้

สาเหตุที่เจอบ่อย: (1) คำอธิบายเครื่องมือกว้างเกินจน AI คิดว่าต้องใช้ตลอด (2) ในคำสั่งไม่มีเงื่อนไขบอกให้หยุดชัด ๆ (3) ผลลัพธ์ที่เครื่องมือคืนมาไม่ชัดจน AI เรียกซ้ำ วิธีแก้: เขียนคำอธิบายให้แคบลง ใส่คำแนะนำว่าตอนไหนไม่ต้องเรียก และทำให้เครื่องมือคืนผลลัพธ์ที่ชัดเจน

💡 จุดสอน

ถ้าเข้าใจวงจรนี้ คุณจะไล่หาสาเหตุพฤติกรรมของ agent ได้ ปัญหาวนไม่หยุดหรือเรียกถี่เกิน มักแก้ที่คำอธิบายเครื่องมือกับตัวคำสั่ง (prompt) ไม่ใช่ที่ตัว AI

แบบฝึกหัดท้ายโมดูล

เขียน JSON Schema สำหรับเครื่องมือ 2 ตัวที่ agent ฝ่ายซัพพอร์ตควรมี (เช่น ค้นนโยบายคืนเงิน, เปิดใบแจ้งปัญหา) พร้อมคำอธิบายที่ชัดเจน
วิเคราะห์บันทึกการทำงาน (log) ของ agent ที่ให้มา (แบบสมมติ) ชี้ว่าจุดไหนที่ agent เรียกเครื่องมือถี่เกิน แล้วเสนอวิธีแก้ที่คำอธิบายเครื่องมือหรือที่ตัวคำสั่ง

2.2

โมดูล 2.2

สร้าง AI Agent บน n8n ด้วย AI Agent Node

ประกอบ agent ตัวจริงที่เลือกเครื่องมือเองได้ โดยวางไว้ในกรอบงานชั้นนอกที่เราคุมได้

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนจ้างผู้ช่วยฉลาดมานั่งในสายการผลิตของโรงงาน ตัวสายพาน (workflow) คุมว่างานเริ่มตรงไหน จบตรงไหนแบบเป๊ะ ๆ ส่วนผู้ช่วยตรงกลางมีอิสระเลือกหยิบเครื่องมือมาทำงานตามสถานการณ์

🎯

ทำไมต้องรู้: ทำให้คุณได้ agent ที่ทั้งฉลาดและควบคุมได้ ไม่หลุดกรอบ เหมาะกับงานจริงในบริษัทที่ต้องการทั้งความยืดหยุ่นและความปลอดภัย โดยแทบไม่ต้องเขียนโค้ด

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

ตั้งค่า AI Agent node บน n8n พร้อมเครื่องมือ (tool) ที่ให้ agent เรียกใช้
ออกแบบ agent แบบผสม (hybrid): กรอบนอกเป็นแบบตายตัว (deterministic) แล้ววางส่วนที่ให้ AI คิดเอง (agentic layer) ไว้ข้างใน
ทดสอบและไล่หาสาเหตุ (debug) เวลา agent เลือกเครื่องมือผิดพลาด

เนื้อหา

n8n มีกล่องสำเร็จรูปชื่อ AI Agent node ที่ปล่อยให้ AI (model) เลือกและเรียกใช้เครื่องมือได้เอง โดยเครื่องมือก็คือ node หรือคำสั่ง (action) อื่น ๆ ที่คุณเปิดให้มันหยิบไปใช้ ในโมดูลนี้เราจะพาคุณประกอบ agent จริงตามแนวคิดแบบผสม (hybrid) ที่เรียนมาตั้งแต่ระดับพื้นฐาน คือ กรอบชั้นนอกให้เป็นแบบตายตัว (จุดเริ่มชัด ผลลัพธ์ชัด มีรั้วกันพลาดคอยกั้นที่ขอบ) แล้ววาง AI Agent node ไว้เป็นส่วนที่ปล่อยให้คิดเองเฉพาะตรงจุดที่ต้องใช้การตัดสินใจจริง ๆ เท่านั้น คุณจะได้ลงมือฝึกเขียนคำสั่งประจำตัวให้ agent (system prompt) ให้ชัด เลือกเครื่องมือให้มัน ตั้งค่าโมเดล แล้วทดสอบว่ามันเลือกเครื่องมือถูกไหม พร้อมเรียนวิธีหาสาเหตุเวลามันเลือกผิดหรือวนซ้ำ ซึ่งส่วนใหญ่แก้ได้ที่ system prompt กับคำอธิบายเครื่องมือ เหมือนที่เรียนไปในโมดูล 2.1

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

n8nโปรแกรมต่อ 'บล็อกงาน' เข้าด้วยกันเป็นระบบอัตโนมัติแบบลากวาง แทบไม่ต้องเขียนโค้ด

AI Agent nodeกล่องสำเร็จรูปใน n8n ที่ใส่ AI ให้เลือกและเรียกใช้เครื่องมือได้เองในระบบของคุณ

Outer workflowโครงงานชั้นนอกที่กำหนดว่างานเริ่มยังไง จบยังไง ทำหน้าที่เป็นกรอบคุม agent อีกที

Deterministicแบบตายตัว คาดเดาได้ ใส่แบบเดิมก็ได้ผลแบบเดิมทุกครั้ง ตรงข้ามกับปล่อยให้ AI ตัดสินเอง

Guardrailsรั้วกันพลาด กฎที่กั้นไม่ให้ agent ทำอะไรออกนอกขอบเขตที่อนุญาต

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

โครง AI Agent สำหรับตอบคำถามลูกค้า

AI Agent node (n8n): System prompt: "คุณเป็นผู้ช่วยลูกค้าของร้าน ตอบเป็นภาษาไทยสุภาพ ใช้ tool เมื่อจำเป็นเท่านั้น ถ้าไม่แน่ใจให้ส่งต่อพนักงาน" Tools ที่เชื่อม: - check_order_status (HTTP Request node) - search_faq (Vector Store node) - create_ticket (Database node) Model: โมเดลที่เลือก

✅ ผลลัพธ์ที่ได้

พอลูกค้าถามอะไรมา agent จะตัดสินใจเองว่าต้องเรียกเครื่องมือตัวไหน เช่น ถามเรื่องออเดอร์ → เรียก check_order_status, ถามนโยบาย → เรียก search_faq, เจอปัญหาซับซ้อน → create_ticket แล้วเรียบเรียงคำตอบเป็นภาษาไทยให้

💡 จุดสอน

AI Agent node จัดการวงจรเรียกเครื่องมือให้อัตโนมัติ หน้าที่คุณคือออกแบบคำสั่งประจำตัว (system prompt) เลือกเครื่องมือให้เหมาะ และวางกรอบงานชั้นนอกให้คุมสิ่งที่เข้าและออกที่ขอบเขต

วาง outer workflow ล้อม agent

ออกแบบ hybrid: outer workflow ล้อม AI Agent node อย่างไร?

✅ ผลลัพธ์ที่ได้

Trigger: Webhook (ข้อความจาก LINE) → Guardrails node (กรอง input อันตราย) → Set (จัดรูป context) → AI Agent node (agentic layer) → Guardrails node (กรอง output) → IF (ต้องส่งจริงไหม) → LINE reply ส่วน agentic อยู่แค่ตรงกลาง ที่เหลือ deterministic ทั้งหมด

💡 จุดสอน

หลักของแบบผสม (hybrid): ให้ส่วนที่ปล่อยให้ AI คิดเองเล็กที่สุดเท่าที่จำเป็น แล้วล้อมด้วยส่วนตายตัวและรั้วกันพลาดที่ขอบ ทำให้ระบบทั้งยืดหยุ่นและตรวจสอบย้อนหลังได้

แบบฝึกหัดท้ายโมดูล

สร้าง AI Agent node ที่มีเครื่องมืออย่างน้อย 2 ตัว แล้วทดสอบด้วยคำถาม 5 แบบ จดว่า agent เลือกเครื่องมือถูกทุกครั้งไหม
ปรับคำสั่งประจำตัว (system prompt) เพื่อลดการเรียกเครื่องมือถี่เกินไป แล้วเทียบจำนวนครั้งที่เรียกก่อนและหลังปรับ

2.3

โมดูล 2.3

RAG พื้นฐาน: ให้ agent ตอบจากข้อมูลบริษัท

วิธีที่ครองวงการอยู่ตอนนี้ สำหรับทำให้ agent ตอบจากข้อมูลจริงของคุณ ไม่ใช่การเดามั่ว

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนให้พนักงานเปิดคู่มือบริษัทดูก่อนตอบลูกค้า แทนที่จะตอบจากความจำที่อาจจำผิด เขาไปเปิดหน้าที่เกี่ยวข้องแล้วตอบตามนั้น

🎯

ทำไมต้องรู้: ทำให้ AI ตอบจากข้อมูลจริงของคุณ เช่น นโยบายบริษัท คู่มือสินค้า ลดการ 'มั่ว' ลงมาก เชื่อถือได้พอที่จะเอาไปตอบลูกค้าจริง

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

อธิบาย 4 ขั้นตอนของ RAG ได้: นำข้อมูลเข้า (ingestion), ไปหยิบออกมา (retrieval), เอามาประกอบ (augmentation), แล้วตอบ (generation)
เข้าใจกลไกเบื้องหลัง: การหั่นเอกสารเป็นชิ้น (chunking), การแปลงเป็นตัวเลขแทนความหมาย (embedding), คลังแบบ vector (vector database) และการค้นหาความหมายใกล้เคียง (similarity search)
สร้าง RAG chatbot ที่ตอบจากเอกสารบริษัท (บน Google Drive หรือ Notion) ได้จริงบน n8n

เนื้อหา

RAG (ให้ AI ไปค้นเอกสารของเรามาอ่านก่อนแล้วค่อยตอบ) คือวิธีที่นิยมที่สุดในการทำให้ agent ตอบจากข้อมูลจริงที่เชื่อถือได้ของคุณ มันมี 4 ขั้นตอน คือ นำข้อมูลเข้าคลัง (ingestion — โหลดเอกสารเข้าไปเก็บใน vector DB), ไปหยิบออกมา (retrieval — ค้นหาชิ้นเอกสารที่เกี่ยวกับคำถาม), เอามาประกอบเข้าด้วยกัน (augmentation — เอาชิ้นเอกสารไปแปะเพิ่มในคำสั่งที่ส่งให้ AI), แล้วตอบ (generation — AI ตอบโดยอิงจากชิ้นเอกสารเหล่านั้น) เบื้องหลังมันทำงานแบบนี้: เอกสารจะถูกหั่นเป็นชิ้นเล็ก ๆ (chunk) แต่ละชิ้นแปลงให้เป็นชุดตัวเลขที่แทนความหมาย (embedding) เก็บไว้ในคลังแบบพิเศษที่ค้นด้วยความหมายได้ (vector) พอมีคำถามเข้ามา คำถามก็ถูกแปลงเป็นตัวเลขแบบเดียวกัน แล้วเอาไปเทียบหาชิ้นเอกสารที่ความหมายใกล้กันที่สุด (similarity search) ในโมดูลนี้คุณจะได้สร้าง RAG chatbot จริงที่คุยกับเอกสารบน Google Drive หรือ Notion แล้วดึงคำตอบที่แม่นยำออกมาจากเอกสารที่ไม่ได้จัดระเบียบอะไรมาก่อนเลย ซึ่งเป็นงานที่ใช้กันจริงแพร่หลายมาก

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

RAGวิธีให้ AI ไปค้นเอกสารของคุณมาอ่านก่อน แล้วค่อยตอบ เพื่อให้คำตอบอิงข้อมูลจริงไม่ใช่การเดา

Vector DBคลังเก็บเอกสารแบบพิเศษ ที่ค้นหาด้วย 'ความหมายใกล้เคียง' ได้ ไม่ใช่แค่ตรงคำเป๊ะ ๆ

Chunkการหั่นเอกสารยาว ๆ ออกเป็นชิ้นเล็ก ๆ เพื่อให้ค้นและหยิบเฉพาะส่วนที่เกี่ยวข้องได้ง่าย

Retrievalขั้นตอนไปหยิบชิ้นเอกสารที่เกี่ยวกับคำถามออกมาจากคลัง

Authoritative dataข้อมูลต้นทางที่เชื่อถือได้และเป็นทางการ เช่น เอกสารจริงของบริษัทคุณ

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

โครง RAG ingestion บน n8n

Workflow ingestion: 1. Trigger: Google Drive (ไฟล์ใหม่/แก้ไข) 2. Node: Download file → Extract text 3. Node: Text Splitter (แบ่ง chunk ตามย่อหน้า/หัวข้อ) 4. Node: Embeddings (แปลง chunk เป็น vector) 5. Node: Vector Store (บันทึกลง pgvector/Qdrant พร้อม metadata)

✅ ผลลัพธ์ที่ได้

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

💡 จุดสอน

คุณภาพของ RAG ขึ้นกับขั้นตอนนำข้อมูลเข้าเป็นหลัก โดยเฉพาะการหั่นชิ้นที่ดีและข้อมูลกำกับที่ครบ ซึ่งเราจะเจาะลึกในโมดูลถัดไป

โครง RAG retrieval + generation

Workflow ตอบคำถาม: 1. Trigger: คำถามจากผู้ใช้ "นโยบายลาพักร้อนกี่วัน?" 2. Node: Embeddings (แปลงคำถามเป็น vector) 3. Node: Vector Store (ดึง top-k chunk ที่ใกล้ที่สุด) 4. AI node: LLM Chain Prompt: "ตอบคำถามโดยอิงเฉพาะข้อมูลต่อไปนี้:\n{{chunks}}\n\nคำถาม: {{question}}\nถ้าข้อมูลไม่พอ ให้บอกว่าไม่ทราบ"

✅ ผลลัพธ์ที่ได้

agent ไปหยิบชิ้นเอกสารที่เกี่ยวกับนโยบายลาพักร้อนออกมา แล้วตอบว่า "พนักงานมีสิทธิลาพักร้อน 10 วันต่อปี..." โดยอิงจากเอกสารจริง ไม่ใช่การเดา และถ้าไม่มีข้อมูลก็จะบอกว่าไม่ทราบ

💡 จุดสอน

การสั่งให้ AI ตอบเฉพาะจากข้อมูลที่ดึงมา และยอมรับตรง ๆ เมื่อไม่รู้ คือหัวใจที่ทำให้ RAG ลดการมั่วข้อมูล (hallucination) ได้ การผูกคำตอบเข้ากับชิ้นเอกสารจริงนี่แหละ คือสิ่งที่ทำให้ RAG ต่างจาก AI ธรรมดา

แบบฝึกหัดท้ายโมดูล

สร้าง RAG chatbot ที่นำเอกสาร 3-5 ไฟล์ของคุณเข้าคลัง (นโยบาย/คู่มือ) แล้วตอบคำถามได้อย่างน้อย 5 คำถามโดยอิงจากเอกสารจริง
ลองถามคำถามที่ไม่มีคำตอบอยู่ในเอกสาร แล้วเช็กว่า chatbot ตอบว่าไม่ทราบแทนการเดา ถ้ายังเดาอยู่ก็ปรับคำสั่ง (prompt)

2.4

โมดูล 2.4

Vector Database: เลือก pgvector, Qdrant หรือ Pinecone

เลือกคลัง vector ให้เหมาะกับปริมาณข้อมูลและงบ พร้อมหั่นเอกสารให้ถูกวิธี

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนเลือกตู้เก็บเอกสารให้เหมาะกับบ้าน ถ้าของน้อยก็ใช้ลิ้นชักที่มีอยู่แล้วก็พอ ถ้าของเยอะมากก็ต้องซื้อตู้ใหญ่แบบมืออาชีพ เลือกให้พอดีกับปริมาณและงบ

🎯

ทำไมต้องรู้: เลือกถูกตัวช่วยประหยัดเงินและทำให้ระบบเร็ว ไม่ต้องจ่ายแพงเกินจำเป็น และการหั่นเอกสารให้ถูกวิธีทำให้ AI ค้นเจอคำตอบที่ตรงกว่าเดิม

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

เลือกคลัง vector ได้ตามปริมาณข้อมูล: pgvector (ต่ำกว่า 1 ล้านชิ้น), Qdrant (ตัวเลือกสายกลาง), Pinecone (แบบคลาวด์ที่เขาดูแลให้)
เข้าใจว่าคลัง vector แบบเฉพาะทางจะทิ้งห่างตัวอื่นชัดเจนเมื่อข้อมูลเกินราว 10 ล้านชิ้น
หั่นเอกสารตามขอบเขตธรรมชาติและเก็บข้อมูลกำกับแบบเป็นลำดับชั้น (hierarchical metadata) ตามหลักที่ควรทำ

เนื้อหา

ทุกวันนี้คลังแบบ vector (vector DB) เหลือตัวเลือกหลัก ๆ อยู่ 3 ตัว ตัวแรกคือ pgvector ซึ่งเป็นส่วนเสริมของฐานข้อมูล Postgres เหมาะที่สุดถ้าคุณใช้ Postgres อยู่แล้วและมีข้อมูลไม่ถึงราว 1 ล้านชิ้น มันวัดความใกล้เคียงได้หลายแบบ (cosine/L2/inner-product) และมีเทคนิคค้นของใกล้เคียงให้เร็ว (HNSW indexing) ถูกและง่ายที่สุดสำหรับธุรกิจเล็ก-กลาง (SMB) ตัวที่สองคือ Qdrant เด่นเรื่องการกรองข้อมูล รองรับข้อมูลกำกับ (metadata) ที่หลากหลายมาก ประหยัดหน่วยความจำ และเอาไปรันเองบนเครื่องคุณ (ผ่าน Docker/K8s) หรือใช้แบบคลาวด์ที่เขาดูแลให้ก็ได้ เป็นตัวเลือกสายกลางที่ดี ตัวที่สามคือ Pinecone เป็นแบบคลาวด์ที่เขาดูแลให้หมด (managed/serverless) ขึ้นระบบจริงได้ง่ายที่สุด ตอบเร็วมาก (p99 ต่ำกว่า 50ms) เมื่อข้อมูลไม่ถึงราว 10 ล้านชิ้น ก็คือจ่ายเพิ่มหน่อยเพื่อแลกกับความสบาย ทั้งนี้คลัง vector แบบเฉพาะทางจะทิ้งห่างตัวอื่นชัดเจนเมื่อข้อมูลเกินราว 10 ล้านชิ้น (บีบข้อมูลให้เล็กลง ค้นเร็วขึ้น 10-100 เท่า) ส่วนแนวทางที่ควรทำจริงคือ ให้หั่นเอกสารตามขอบเขตธรรมชาติ (ทีละย่อหน้าหรือทีละหัวข้อ) อย่าไปนับตัวอักษรตัดดื้อ ๆ และใส่ข้อมูลกำกับแบบเป็นลำดับชั้นให้แต่ละชิ้น เพื่อให้กรองและประกอบข้อมูลได้ดีขึ้น เพราะการหั่นชิ้นแบบมั่ว ๆ คือสาเหตุอันดับหนึ่งที่ทำให้ RAG ใช้ไม่ได้ผล

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

pgvectorส่วนเสริมของฐานข้อมูล Postgres ที่ทำให้เก็บและค้นแบบ vector ได้ เหมาะถ้าคุณใช้ Postgres อยู่แล้ว

Qdrant / Pineconeบริการคลังเก็บ vector สำเร็จรูป เด่นเรื่องกรองข้อมูลและรองรับปริมาณมาก

HNSW indexingเทคนิคจัดระเบียบข้อมูลให้ค้นหาของที่ใกล้เคียงเจอเร็วมาก แม้ข้อมูลจะเยอะ

Metadataข้อมูลกำกับชิ้นเอกสาร เช่น วันที่ ผู้เขียน หมวดหมู่ ใช้ช่วยกรองผลค้นหา

SMBธุรกิจขนาดเล็กถึงกลาง (Small and Medium Business)

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

เลือก vector DB จากโจทย์

3 โจทย์: A. ร้านค้าเล็กมีเอกสารราว 500 ไฟล์ ใช้ Postgres อยู่แล้ว B. บริษัทกลางต้องการ filtering ตาม metadata เยอะ และอยาก self-host C. startup ต้องการขึ้น production เร็ว ไม่อยากดูแล infra เลือก vector DB ให้แต่ละโจทย์

✅ ผลลัพธ์ที่ได้

A → pgvector (ถูก ง่าย มี Postgres แล้ว vector น้อยกว่า 1M) B → Qdrant (filtering ดี, metadata high-cardinality, self-host ได้) C → Pinecone (managed/serverless ขึ้น production ง่ายที่สุด)

💡 จุดสอน

เลือกจากปริมาณข้อมูล ระบบที่คุณมีอยู่แล้ว และงบ ไม่จำเป็นต้องไปเลือกคลังแบบเฉพาะทางตั้งแต่แรกถ้าข้อมูลยังไม่ถึง 1 ล้านชิ้น เพราะเลือกเกินความจำเป็นก็คือจ่ายแพงเปล่า ๆ

chunk ที่ขอบเขตธรรมชาติ + metadata

เอกสาร: คู่มือพนักงาน มีหัวข้อ "3.2 การลาป่วย" แบ่ง chunk แบบไหนดี?

✅ ผลลัพธ์ที่ได้

ดี: chunk = ทั้งย่อหน้าของหัวข้อ 3.2 พร้อม metadata {"doc": "คู่มือพนักงาน", "section": "3.2 การลาป่วย", "chapter": "3 สวัสดิการ"} ไม่ดี: ตัด chunk ทุก 500 ตัวอักษรโดยไม่สนขอบเขต ทำให้ประโยคขาดกลางและ context หาย

💡 จุดสอน

การหั่นชิ้นตามขอบเขตธรรมชาติ บวกกับข้อมูลกำกับแบบเป็นลำดับชั้น ช่วยให้ทั้งค้นเจอแม่นและกรองได้ นี่คือตัวป้องกันปัญหา RAG ใช้ไม่ได้ผลอันดับหนึ่ง

แบบฝึกหัดท้ายโมดูล

ทำตารางตัดสินใจเลือกคลัง vector สำหรับ 3 สถานการณ์ในองค์กรของคุณ โดยดูจากปริมาณข้อมูล ระบบเดิมที่มี และงบประมาณ
ลองหั่นเอกสารเดียวกัน 2 แบบ (แบบนับตัวอักษรตัดตายตัว เทียบกับแบบตามหัวข้อ + ใส่ข้อมูลกำกับ) แล้วเทียบคุณภาพคำตอบของ RAG

2.5

โมดูล 2.5

MCP เบื้องต้น: เชื่อมเครื่องมือด้วยมาตรฐานเดียว

เปรียบเหมือนหัวชาร์จ USB-C สำหรับเครื่องมือ AI มาตรฐานเปิดที่กลายเป็นวิธีเชื่อมต่อมาตรฐานข้ามทุกผู้ให้บริการ

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนหัวชาร์จ USB-C หัวเดียวเสียบได้กับอุปกรณ์เกือบทุกยี่ห้อ แทนที่จะต้องหาสายเฉพาะของแต่ละเครื่อง MCP คือหัวเสียบมาตรฐานที่ทำให้ AI ต่อเข้ากับเครื่องมือต่าง ๆ ได้ด้วยวิธีเดียว

🎯

ทำไมต้องรู้: ประหยัดเวลามหาศาล เพราะต่อเครื่องมือใหม่ครั้งเดียวก็ใช้ได้ข้ามหลายเจ้า ไม่ต้องเขียนโค้ดเชื่อมใหม่ทุกครั้ง และย้ายไปใช้ AI เจ้าอื่นก็ยังต่อได้

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

อธิบายได้ว่า MCP คืออะไร และทำไมมันถึงมาแทนโค้ดกาว (glue) ที่ต้องเขียนเชื่อมทีละเจ้าแบบเดิม
เชื่อม MCP server เข้ากับ n8n ผ่าน Standalone MCP Client node ได้
เข้าใจ MCP ระดับทั้งระบบ (instance-level): เปิด workflow ให้เป็นเครื่องมือที่ AI ทุกตัวที่รองรับ MCP เรียกใช้ได้

เนื้อหา

MCP (Model Context Protocol) เป็นมาตรฐานเปิดที่ Anthropic ประกาศออกมาเมื่อ พ.ย. 2024 เอาไว้เชื่อม AI หรือ agent เข้ากับเครื่องมือและข้อมูลต่าง ๆ ผ่านช่องทางมาตรฐานเดียวกันหมด เปรียบได้กับหัวชาร์จ USB-C สำหรับเครื่องมือ AI มันมาแทนโค้ดกาว (glue) ที่เมื่อก่อนต้องมานั่งเขียนเชื่อมทีละเจ้า ตอนนี้หลายเจ้าหันมาใช้กันกว้างขวางแล้ว: OpenAI รับมาใช้ (มี.ค. 2025 ทั้งใน Agents SDK, Responses API และ ChatGPT เวอร์ชันเดสก์ท็อป) ส่วน Gemini ของ Google DeepMind และ Microsoft Copilot ก็รองรับ มีรายงานว่ายอดดาวน์โหลดชุดเครื่องมือ (SDK) สูงราว 97 ล้านครั้งต่อเดือน (ธ.ค. 2025) และมีทะเบียน MCP ทางการที่คัดมาแล้วราว 2,000 server ส่วนทั้งวงการรวมกันมีมากกว่า 10,000 server (ธ.ค. 2025) พูดถึงเรื่องใช้งานจริงสำหรับคนสร้างระบบ: n8n 2.0 มี Standalone MCP Client node ที่ไปเรียก MCP server ตัวที่อยู่ไกล ๆ ได้จากทุกจุดในงาน ไม่ใช่แค่ใน Agent เท่านั้น แถมยังมี MCP ระดับทั้งระบบ ที่เปิด workflow ที่คุณเลือกไว้ ให้แพลตฟอร์ม AI ตัวที่รองรับ MCP เรียกไปใช้ได้ ผ่านการเชื่อมต่อจุดเดียวที่ล็อกด้วย OAuth เท่ากับว่าเชื่อมเครื่องมือทีเดียว ก็ใช้ได้กับ AI ทุกตัวที่พูดภาษา MCP ได้ ซึ่งเป็นทิศทางที่ควรออกแบบมุ่งไปหา

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

MCP (Model Context Protocol)มาตรฐานกลางสำหรับเชื่อม AI เข้ากับเครื่องมือและข้อมูลด้วยวิธีเดียวกันหมด

Open standardมาตรฐานเปิดที่ใครก็เอาไปใช้ได้ฟรี ไม่ผูกขาดกับเจ้าใดเจ้าหนึ่ง

Interfaceจุดเชื่อมต่อ ช่องทางมาตรฐานที่ให้สองระบบคุยกันได้

Integrationการเชื่อมระบบสองอันให้ทำงานร่วมกัน เช่น ต่อ AI เข้ากับ Gmail หรือ Google Sheets

Glue (glue code)โค้ดกาวเล็ก ๆ น้อย ๆ ที่ต้องเขียนเชื่อมสองระบบเข้าด้วยกันแบบเดิม ๆ ซึ่ง MCP มาช่วยลดภาระนี้

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

เชื่อม MCP server เข้า n8n

ใช้ Standalone MCP Client node ใน n8n เชื่อม remote MCP server: MCP Client node config: - Server URL: (endpoint ของ MCP server) - Authentication: OAuth - Operation: List tools / Call tool จากนั้นเรียก tool ที่ server นั้น expose ได้จาก step ใดก็ได้ใน workflow

✅ ผลลัพธ์ที่ได้

workflow เรียกเครื่องมือจาก MCP server ได้ (เช่น ค้นฐานข้อมูลภายใน หรือเรียกระบบ CRM) โดยไม่ต้องมานั่งเขียนโค้ดเชื่อมเฉพาะ และเครื่องมือตัวเดียวกันนี้ก็ใช้ได้กับ agent ทุกตัวที่พูดภาษา MCP ได้

💡 จุดสอน

Standalone MCP Client node ใน n8n 2.0 ทำให้เรียก MCP server ได้จากทุกจุดในงาน ไม่จำกัดแค่ใน Agent ช่วยให้ออกแบบระบบได้ยืดหยุ่นขึ้นมาก

expose workflow เป็น MCP tool

ต้องการให้ workflow n8n "ค้นสต็อกสินค้า" ใช้ได้จาก Claude Desktop และ ChatGPT ทำอย่างไร?

✅ ผลลัพธ์ที่ได้

ใช้ MCP ระดับทั้งระบบของ n8n: เปิด workflow "ค้นสต็อกสินค้า" ผ่านการเชื่อมต่อจุดเดียวที่ล็อกด้วย OAuth แล้ว AI ทุกตัวที่รองรับ MCP (Claude, Gemini, Copilot) ก็เรียก workflow นี้เป็นเครื่องมือได้ทันที โดยไม่ต้องมานั่งเชื่อมแยกทีละแพลตฟอร์ม

💡 จุดสอน

การออกแบบให้รองรับ MCP มาแต่แรก หมายความว่าเชื่อมทีเดียว ก็เปิดให้เป็นเครื่องมือของ AI ทุกตัวได้ เป็นการลงทุนที่คุ้มในระยะยาวเมื่อ MCP กลายเป็นมาตรฐานกลาง

แบบฝึกหัดท้ายโมดูล

เชื่อม MCP server (เช่นตัวอย่างจากทะเบียน registry) เข้ากับ n8n ผ่าน MCP Client node แล้วเรียกเครื่องมืออย่างน้อย 1 ตัวให้สำเร็จ
ออกแบบว่า workflow ไหนในองค์กรของคุณควรเปิดเป็นเครื่องมือ MCP ผ่าน MCP ระดับทั้งระบบ และอธิบายว่า AI ตัวไหนบ้างจะได้ประโยชน์

2.6

โมดูล 2.6

ควบคุมต้นทุน LLM, rate-limit และ error handling พื้นฐาน

จุดปรับลดต้นทุน (cost lever) ที่ทุกคนควรใช้ และวิธีรับมือเพดานเรียกใช้ (rate limit) ไม่ให้งานล้ม

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนคุมค่าน้ำค่าไฟในบ้าน ยิ่งเปิดใช้มากยิ่งจ่ายมาก จึงต้องเลือกเครื่องประหยัดไฟให้เหมาะงาน และตั้งเบรกเกอร์กันไฟเกินไม่ให้ทั้งบ้านดับ

🎯

ทำไมต้องรู้: ช่วยไม่ให้บิลค่า AI บานปลายโดยไม่รู้ตัว และทำให้ระบบไม่ล้มกลางทางเวลามีงานถาโถมเข้ามาพร้อมกัน ซึ่งสำคัญมากกับงานที่ใช้จริงทุกวัน

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

ลดต้นทุนด้วยการเก็บคำสั่งที่ซ้ำไว้ใช้ซ้ำ (prompt/context caching ลดค่าขาเข้าที่เก็บไว้ราว 90%) และการส่งงานเป็นชุด (batch API ลดราว 50%)
รับมือเพดานเรียกใช้ (rate limit) ด้วย Retry On Fail คู่กับ Wait Between Tries หรือ Loop Over Items คู่กับ Wait
เข้าใจช่องว่างระหว่าง "รันบนเครื่องตัวเองแล้วเวิร์ก" กับ "รับงานผู้ใช้จริงจำนวนมากไหว"

เนื้อหา

ค่าใช้จ่ายของ AI (LLM) เขาคิดกันต่อทุก ๆ 1 ล้าน token โดยแยกเป็นขาเข้า (input — ข้อความที่คุณส่งไป) กับขาออก (output — คำตอบที่ได้กลับมา) และราคาก็เปลี่ยนเร็วมาก เพราะฉะนั้นเช็กราคาล่าสุดก่อนอ้างอิงทุกครั้ง ยกตัวอย่างช่วงราคาพอให้เห็นภาพ: Claude Haiku ราว 1/5 ดอลลาร์, Claude Sonnet ราว 3/15, GPT-4o mini ราว 0.15/0.60 (ถูกที่สุดในกลุ่มที่คนใช้ทั่วไป), Gemini Flash-Lite ราว $0.10/$0.40 ต่อ 1M tokens (ย้ำว่าให้ตรวจราคาล่าสุดเสมอ) วิธีลดต้นทุนก้อนใหญ่ที่ทุกคนควรใช้มีสองอย่าง อย่างแรกคือเก็บส่วนของคำสั่งที่ซ้ำ ๆ ไว้ใช้ซ้ำ (prompt/context caching ซึ่งช่วยลดค่าข้อความขาเข้าส่วนที่เก็บไว้ได้ราว 90% ทั้งบน OpenAI, Anthropic และ Gemini) อย่างที่สองคือส่งงานเป็นชุดทีเดียว (batch API ลดได้ราว 50% สำหรับงานที่ไม่ต้องรีบเอาคำตอบทันที มีทั้งบน Gemini และเจ้าอื่น ๆ) รวมถึงใช้โมเดลรุ่นถูก (Haiku/GPT-4o-mini/Flash-Lite) กับงานง่าย ๆ อย่างส่งต่อและแยกประเภท แล้วเก็บโมเดลตัวเก่งไว้ทำงานยาก ๆ ส่วนการรับมือเพดานเรียกใช้ (rate limit) ใน n8n ทำได้สองวิธี คือ (1) เปิด Retry On Fail ที่ node แล้วตั้ง Wait Between Tries (มิลลิวินาที) ให้ช้ากว่าเพดานที่เขากำหนด (เช่น 1000ms ถ้าเพดานคือ 1 ครั้งต่อวินาที) และ (2) ใช้ Loop Over Items คู่กับ Wait node เพื่อคุมความเร็วในการยิงงาน สุดท้าย การก้าวจาก "รันบนเครื่องตัวเองแล้วเวิร์ก" ไปสู่ "รับงานจริงจากผู้ใช้จำนวนมากไหว" เป็นก้าวที่ใหญ่มาก ระบบ agent ที่ใช้จริงต้องมีของพวกนี้ครบ: ทางรับมือเวลาเกิดข้อผิดพลาด (error), การลองใหม่, การเฝ้าดูระบบ (monitoring), การตั้งเวลาหมดอายุ (timeout), การเก็บงานที่ทำไม่สำเร็จไว้ตรวจย้อนหลัง และการดูแลรักษา อย่าลืมเผื่องบส่วนนี้ไว้ด้วย เพราะเป็นส่วนที่คนมักประเมินค่าต่ำไปมากที่สุด

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Tokenหน่วยนับคำ/ชิ้นข้อความที่ AI คิดเงิน ยิ่งข้อความยาวยิ่งใช้ token มากและจ่ายมาก

Input / Output (pricing)ค่าใช้จ่ายแยกสองส่วน คือข้อความที่คุณส่งเข้าไป (input) กับคำตอบที่ AI ส่งกลับมา (output) มักคิดราคาต่างกัน

Rate limitเพดานจำกัดว่าเรียกใช้ AI ได้กี่ครั้งต่อช่วงเวลา ถ้าเกินระบบจะปฏิเสธชั่วคราว

Error handlingการเตรียมทางรับมือเมื่อมีข้อผิดพลาด เช่น ลองใหม่หรือแจ้งเตือน แทนที่จะปล่อยให้ระบบพังทั้งสาย

Cost leverจุดที่ปรับเพื่อลดต้นทุนได้ เช่น เลือกรุ่น AI ที่ถูกลงสำหรับงานง่าย ๆ

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ตั้ง rate-limit handling ใน n8n

API ที่เรียกอนุญาต 1 request/วินาที แต่ workflow ประมวลผล 500 รายการ ตั้งค่าอย่างไรไม่ให้โดน rate limit?

✅ ผลลัพธ์ที่ได้

แนวทาง 1: HTTP node เปิด Retry On Fail, ตั้ง Wait Between Tries = 1000ms แนวทาง 2: ใช้ Loop Over Items แล้วใส่ Wait node 1000ms ในแต่ละรอบ เพื่อคุม throughput ให้ไม่เกิน 1 req/sec แบบที่ 2 คุมได้แม่นกว่าเมื่อประมวลผลจำนวนมาก

💡 จุดสอน

การรับมือเพดานเรียกใช้แบบเชิงรุก (Loop คู่กับ Wait) ช่วยกัน workflow ไม่ให้ล้มกลางคัน สำคัญมากเวลาประมวลผลงานจำนวนมากในระบบจริง

ใช้ caching และเลือกโมเดลลดต้นทุน

workflow ตอบคำถามลูกค้า โดยมี system prompt + คู่มือบริษัทยาว (context เดิมทุกครั้ง) วันละ 5,000 ครั้ง ลดต้นทุนอย่างไร?

✅ ผลลัพธ์ที่ได้

1. เปิด prompt/context caching สำหรับส่วน system prompt + คู่มือที่ซ้ำทุกครั้ง (ลด cached input ~90%) 2. ใช้โมเดลถูกสำหรับจำแนกคำถามก่อน route 3. ถ้าเป็นงาน async ที่ไม่ต้อง real-time ใช้ batch API (~50% off)

💡 จุดสอน

ส่วนของข้อมูลที่ซ้ำทุกครั้งที่เรียก คือเป้าหมายชั้นดีของการเก็บไว้ใช้ซ้ำ (caching) พอรวมการทำ caching เข้ากับการเลือกโมเดลให้เหมาะกับงาน ก็ลดต้นทุนได้เยอะโดยไม่กระทบคุณภาพ

แบบฝึกหัดท้ายโมดูล

ตั้งค่ารับมือเพดานเรียกใช้ให้ workflow ที่เรียก API 200 ครั้งไม่ให้โดนบล็อก แล้วจดว่าใช้แนวทางไหนและเพราะอะไร
คำนวณต้นทุนต่อเดือนของ workflow สมมติ ทั้งก่อนและหลังเปิด prompt caching บวกกับเปลี่ยนไปใช้โมเดลรุ่นถูกสำหรับขั้นตอนแยกประเภทคำถาม

🎯 Capstone ระดับกลาง: AI Support Agent พร้อม RAG, MCP และ HITL

สร้าง AI Agent บน n8n ที่ตอบคำถามลูกค้าเป็นภาษาไทย โดยมีเครื่องมืออย่างน้อย 3 ตัว (check_order, search_faq ที่ต่อผ่าน RAG, create_ticket)
ต่อ RAG เข้ากับเอกสารบริษัทจริง เลือกคลัง vector (pgvector/Qdrant/Pinecone) พร้อมบอกเหตุผล และหั่นเอกสารตามขอบเขตธรรมชาติพร้อมใส่ข้อมูลกำกับ (metadata)
เชื่อมเครื่องมือภายนอกอย่างน้อย 1 ตัวผ่าน MCP Client node แล้ววางกรอบงานชั้นนอกแบบผสม (hybrid) ล้อมตัว agent ไว้
ใส่ขั้นตอนให้คนตรวจก่อน (Human-in-the-Loop) ก่อนส่งคำตอบจริงถึงลูกค้า พร้อมตั้งเวลาหมดอายุและทางสำรอง (timeout + fallback) และเปิด prompt caching เพื่อคุมต้นทุน จากนั้นทดสอบด้วยเคสจริง 10 เคส

ก้าวต่อไป

Advanced: การวางสถาปัตยกรรมสำหรับใช้งานจริง (production), การทำงานหลาย agent ร่วมกัน (multi-agent) และการกำกับดูแล (governance)

ไปต่อ →