Automatically translated.View original post

It's an AI Engineer, but it's not an API writer...Can't you?!

1/15 Edited to

... Read moreถ้าถามว่า “AI API คืออะไร” แบบสั้นที่สุดในภาษาคนทำงาน: มันคือ “ตัวกลาง/ท่อส่งข้อมูล” ที่ทำให้โปรแกรมคุยกันได้ และทำให้โมเดล AI ที่เราสร้าง (หรือโมเดลระดับโลกที่เรียกใช้ได้) กลายเป็นบริการที่คนอื่นเรียกใช้งานจริงได้ ไม่งั้นต่อให้เทรนโมเดลเทพแค่ไหน ก็เหมือนทำอาหารเสร็จแต่ไม่มีจาน ไม่มีช้อน ไม่มีทางเสิร์ฟให้คนกิน คำศัพท์ 3 ตัวที่เจอบ่อยและควรรู้ให้ชัด 1) Endpoint = ที่อยู่ URL ที่เราจะยิงไปหา API เช่น /predict หรือ /generate 2) JSON = รูปแบบข้อมูลมาตรฐานที่ใช้ส่ง-รับ (อ่านง่ายทั้งคนและเครื่อง) เช่น {"text":"..."} 3) HTTP Methods = วิธี “คุย” กับปลายทางนั้นๆ ที่เจอบ่อยคือ - GET: ขอข้อมูล (เช่นเช็คสถานะ/health check) - POST: ส่งข้อมูลให้ประมวลผล (เช่นส่งข้อความไปให้โมเดลทำนาย) ตัวอย่างภาพรวมการทำงานแบบที่เราใช้จริงบ่อยๆ - ฝั่งแอป (มือถือ/เว็บ) ส่ง POST ไปที่ Endpoint /predict พร้อม JSON ที่มีข้อความหรือฟีเจอร์ - ฝั่งเซิร์ฟเวอร์รับข้อมูล แล้วเรียกโมเดล (บนเครื่อง/บนคลาวด์) เพื่อ infer - เซิร์ฟเวอร์ตอบกลับเป็น JSON เช่น {"label":"spam","score":0.98} ทำไม AI Engineer ต้องเก่ง API? - Model Deployment: เพราะ “การเอาโมเดลขึ้น production” ส่วนใหญ่จบที่การทำ API ให้ทีมอื่นเรียกใช้งานได้ (ไม่ใช่เปิดโน้ตบุ๊กให้ดู) - LLM Integration: เวลาเรียกใช้โมเดลภาษาขนาดใหญ่ ส่วนมากก็ทำผ่าน REST API เหมือนกัน ขอแค่รู้ Endpoint, key/headers, และรูปแบบ JSON - Data Pipelines: การดึงข้อมูลจากแหล่งต่างๆ (เช่น CRM, payment, analytics) ก็มักมี API ให้ยิงไปเอาข้อมูลมาป้อนโมเดลต่อ แล้ว “Application Engineer คืออะไร” เกี่ยวไหม? ในมุมที่เราเจอ Application Engineer จะโฟกัสการสร้าง/ดูแลแอปให้ใช้งานได้จริง (ระบบ, API, การเชื่อมต่อบริการต่างๆ, ความเสถียร, latency) ซึ่งมันต่อกับงาน AI มาก เพราะโมเดลจะมีคุณค่าก็ต่อเมื่อถูก “ห่อ” ให้เป็นฟีเจอร์ในแอปได้ เช่น แนะนำสินค้า, ค้นหา, สรุปข้อความ, chatbot ฯลฯ อีกคำถามที่คนเสิร์ชเยอะ: ทำไม AI สร้างคอนเทนต์ตามคำสั่งได้? (Prompt engineering ช่วยอะไร) จากประสบการณ์เรา prompt engineering ช่วย “ควบคุมพฤติกรรมของโมเดล” ให้ตอบตรงโจทย์มากขึ้น เช่น - ระบุบทบาท/โทน (ให้เขียนแบบบล็อก/โพสต์) - ใส่บริบทและข้อจำกัด (ความยาว, กลุ่มเป้าหมาย, ห้ามพูดบางอย่าง) - ขอรูปแบบผลลัพธ์ (เช่นให้ตอบเป็น JSON หรือ bullet) เพื่อเอาไปต่อในระบบผ่าน API ได้ง่าย พอ prompt ชัด ผลลัพธ์ก็สม่ำเสมอขึ้น ลดงานแก้ และเอาไปใช้งานจริงในโปรดักต์ได้เร็วขึ้น สรุปแบบคนเคยพลาดมาแล้ว: ทำโมเดลเก่งอย่างเดียวไม่พอ ถ้าอยากให้คนอื่น “ใช้” ต้องทำให้เรียกผ่าน API ได้อย่างน้อยรู้ Endpoint + JSON + GET/POST แล้วค่อยต่อยอดเรื่อง auth, error handling และ monitoring ทีหลัง