สรุปจากคลิป ดูคลิปต้นฉบับ

Build Deep Research Agent ใช้จริงในธุรกิจ ไม่ใช่แค่ AI เขียนโพสต์

ปัญหาใหญ่ของการใช้ AI ทำคอนเทนต์ไม่ใช่แค่ “มันเขียนได้ไหม” แต่คือ “มันเขียนแล้วมีประโยชน์จริงหรือเปล่า” เพราะสิ่งที่หลายองค์กรเจอเหมือนกันคือ ได้ข้อความที่ดูเรียบร้อย แต่กลวง ซ้ำ เชย และเต็มไปด้วยภาษาที่ทำให้รู้ทันทีว่าเป็น AI เขียน

คลิปเวิร์กช็อปจากช่อง AI Engineer พาไล่ตั้งแต่การสร้าง deep research agent ไปจนถึง workflow สำหรับเขียนคอนเทนต์ที่อิงข้อมูลจริง มีแหล่งอ้างอิง และผ่านกระบวนการรีวิวหลายรอบ จุดที่น่าสนใจมากคือ ทีมผู้สอนไม่ได้ขายฝันว่า AI จะมาแทนคนทั้งหมด แต่ชี้ชัดว่าอะไรควรเป็น agent อะไรควรเป็น workflow และตรงไหนยังต้องมีคนอยู่ในลูป

สำหรับเจ้าของธุรกิจและคนทำงาน ประเด็นสำคัญไม่ใช่โค้ด แต่คือวิธีคิดในการออกแบบระบบ AI ให้ “ช่วยงานจริง” เช่น วิจัยคู่แข่ง สรุปตลาด ทำ draft บทความภายใน หรือร่างโพสต์ LinkedIn ที่ไม่ดูเป็นขยะดิจิทัล บทความนี้จะสรุปและวิเคราะห์ให้เห็นว่า เราจะหยิบแนวคิดนี้ไปใช้กับธุรกิจไทยได้ยังไง

สารบัญ

• Step 1: เริ่มจากปัญหาจริงก่อน ไม่ใช่เริ่มจากอยากมี agent
• Step 2: แยกให้ออกว่าอะไรคือ prompt, workflow และ agent
• Step 3: ใช้ agent เฉพาะงานที่ต้องค้นหา วางแผน และปรับตัว
• Step 4: จัดการ context ให้ดี เพราะข้อมูลเยอะไม่ได้แปลว่าฉลาดขึ้น
• Step 5: สร้าง research agent ด้วยเครื่องมือที่มีอยู่แล้ว
• Step 6: เปลี่ยนผลวิจัยให้เป็นงานเขียนด้วย workflow ที่คุมได้
• Step 7: ใช้ reviewer loop เพื่อลด AI slop แทนการหวังให้ร่างแรกดีเลย
• Step 8: สังเกตระบบให้ได้ เพราะ AI ที่เดาไม่ออก แก้ไม่ได้
• Step 9: ทำ evals เพื่อให้รู้ว่าระบบดีขึ้นจริง ไม่ใช่รู้สึกว่าดีขึ้น
• Step 10: แปลแนวคิดนี้ให้เข้ากับธุรกิจไทย
• Actionable Insights
• Troubleshooting
• การต่อยอด
• สรุป Checklist ทั้งหมด

Step 1: เริ่มจากปัญหาจริงก่อน ไม่ใช่เริ่มจากอยากมี agent

จุดตั้งต้นของเวิร์กช็อปนี้ดีมาก เพราะไม่ได้เริ่มจากเทคโนโลยี แต่เริ่มจากของจริงที่หลายบริษัทเจอ คือคอนเทนต์ที่สร้างจาก AI แบบสำเร็จรูปมักมี 4 ปัญหา

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

นี่เป็นจุดที่หลายธุรกิจไทยมักเข้าใจผิด เราชอบถามว่า “ใช้ ChatGPT เขียนโพสต์ได้ไหม” แต่คำถามที่ควรถามกว่าคือ “เรามีระบบเก็บข้อมูล ตรวจข้อมูล และคุมคุณภาพข้อความหรือยัง” ถ้ายังไม่มี ต่อให้ใช้ model ดีแค่ไหน ผลลัพธ์ก็มักออกมาแบน

มุมที่น่าคิดคือ ทีมนี้สร้างระบบขึ้นมาเพราะต้นทุนการผลิตคอนเทนต์เทคนิคสูงมาก ต้องมีทั้ง AI engineer นักเขียน และ editor มาทำงานร่วมกัน ธุรกิจทั่วไปก็คล้ายกัน เพียงแต่เปลี่ยนจากคอนเทนต์เทคนิคเป็นงานประเภทอื่น เช่น รายงานขาย บทวิเคราะห์คู่แข่ง เอกสารสินค้า หรือโพสต์สื่อสารแบรนด์

Step 2: แยกให้ออกว่าอะไรคือ prompt, workflow และ agent

หนึ่งในส่วนที่มีค่าที่สุดของคลิปนี้ คือการอธิบายว่าไม่ใช่งานทุกแบบต้องใช้ agent เสมอไป หลายเคสใช้แค่ prompt ดีๆ หรือ workflow ที่กำหนดขั้นตายตัวก็พอ

ทีมผู้สอนเสนอวิธีคิดแบบ “autonomy slider” หรือพูดง่ายๆ คือยิ่งระบบมีอิสระมาก ก็ยิ่งควบคุมยาก ต้นทุนสูง และเสี่ยงมากขึ้น

• Prompting เหมาะกับงานตรงไปตรงมา เช่น สรุปข้อความ จัดหมวดหมู่ ตอบคำถามพื้นฐาน
• Workflow เหมาะกับงานที่มีลำดับขั้นชัด เช่น รับเรื่อง จัดประเภท ตรวจนโยบาย ร่างคำตอบ
• Agent เหมาะกับงานที่ต้องตัดสินใจเองระหว่างทาง ต้องเลือกเครื่องมือ ต้องสำรวจ ต้องเปลี่ยนแผนตามข้อมูลใหม่

นี่เป็นบทเรียนสำคัญสำหรับธุรกิจไทย เพราะหลายองค์กรอยากมี “multi-agent” เร็วมาก ทั้งที่โจทย์จริงอาจเป็นแค่ workflow การตอบลูกค้า หรือระบบทำสรุปรายงานประจำสัปดาห์ ถ้าเริ่มใหญ่เกินไป เราจะได้ต้นทุนและความซับซ้อนเพิ่ม แต่ไม่ได้ผลลัพธ์เพิ่มตาม

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

Step 3: ใช้ agent เฉพาะงานที่ต้องค้นหา วางแผน และปรับตัว

สิ่งที่เรียกว่า deep research agent ในคลิปนี้ ไม่ใช่ chatbot ที่ตอบเก่งขึ้นนิดหน่อย แต่เป็นระบบที่มีเป้าหมายชัด คือรับหัวข้อมา 1 เรื่อง แล้วไปหาข้อมูลจากหลายแหล่ง ประเมินความเกี่ยวข้อง อ้างอิงแหล่งที่มา และสังเคราะห์ออกมาเป็น research artifact ที่นำไปใช้ต่อได้

ความเป็น agent ของระบบนี้อยู่ที่มันทำ 5 อย่างได้เอง

• วางแผนว่าจะต้องค้นอะไรบ้าง
• เลือกใช้เครื่องมือให้เหมาะกับงาน
• หาข้อมูลเพิ่มเมื่อพบช่องว่าง
• สรุปและเรียบเรียงผลวิจัย
• วนกลับไปค้นใหม่หากข้อมูลยังไม่พอ

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

• ทีมการตลาดใช้วิจัยคู่แข่งในหมวดสินค้าเดียวกัน
• ทีมขายใช้รวบรวมข้อมูลลูกค้าอุตสาหกรรมหนึ่งก่อนเข้าไป pitch
• ทีมบริหารใช้สรุปเทรนด์ตลาดจากเว็บ ข่าว และวิดีโอสัมมนา
• ทีมคอนเทนต์ใช้เก็บข้อมูลอ้างอิงก่อนเขียนบทความหรือสคริปต์

ข้อดีของวิธีนี้คือ เราไม่ได้หวังให้ AI “รู้อยู่แล้ว” แต่ให้มัน “ไปค้นมา” แล้วเอาหลักฐานกลับมา นี่ทำให้คำตอบมีน้ำหนักกว่าการถามลอยๆ ในหน้าแชต

Step 4: จัดการ context ให้ดี เพราะข้อมูลเยอะไม่ได้แปลว่าฉลาดขึ้น

อีกประเด็นที่เจ้าของธุรกิจควรรู้คือ ปัญหาใหญ่ของระบบ AI ไม่ใช่แค่เลือก model แต่คือการจัดการ context ถ้าโยนข้อมูลทุกอย่างเข้าไปพร้อมกัน ผลลัพธ์ไม่ได้ดีขึ้นเสมอ บ่อยครั้งกลับแย่ลง

ทีมผู้สอนพูดถึงอาการที่เรียกว่า context rot คือยิ่ง context ยาว ระบบยิ่งสับสน โดยเฉพาะเมื่อผ่านจุดหนึ่งไปแล้ว แม้ยังไม่ชนเพดาน token ก็ตาม

ดังนั้นระบบที่ดีต้องรู้จัก:

• ตัดข้อมูลที่ไม่จำเป็น
• สรุปข้อมูลก่อนส่งต่อ
• ดึงเฉพาะข้อมูลที่เกี่ยวกับคำถามนั้น
• แยกงานออกไปให้ tool หรือ sub-agent รับผิดชอบแทน

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

Step 5: สร้าง research agent ด้วยเครื่องมือที่มีอยู่แล้ว

ด้าน implementation ทีมนี้เลือกวิธีที่ค่อนข้าง pragmatic มาก คือไม่สร้างทุกอย่างเอง แต่หยิบของที่มีมาเชื่อมกันผ่าน MCP หรือ Model Context Protocol

แกนของ research agent มี 3 เครื่องมือหลัก

• Deep research tool สำหรับค้นข้อมูลบนเว็บแบบมีแหล่งอ้างอิง
• Analyze YouTube video tool สำหรับวิเคราะห์วิดีโอและดึงสาระสำคัญหรือ transcript
• Compile research tool สำหรับรวมทุกอย่างเป็นไฟล์สรุป research.md

ฝั่งเทคโนโลยี ทีมนี้ใช้ Gemini เป็นหลัก เพราะรองรับการอ้างอิงข้อมูลจากเว็บ และรองรับ YouTube URL ได้โดยตรง ส่วนการดึงข้อมูลจาก GitHub ก็ใช้ library ที่แปลง repo ให้เป็น Markdown

ถ้าตัดศัพท์เทคนิคออก แก่นของเรื่องนี้คือ “ให้ AI มีแขนขา” ไม่ใช่ให้มันมีแต่สมอง เพราะถ้าระบบมีแต่ model แต่ไม่มีทางไปค้นเว็บ อ่านวิดีโอ หรือดึงไฟล์มาใช้ มันก็ทำงานวิจัยจริงไม่ได้

Step 6: เปลี่ยนผลวิจัยให้เป็นงานเขียนด้วย workflow ที่คุมได้

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

โครงสร้างของระบบเขียนมีอินพุต 2 ส่วนหลัก

• guideline.md หรือคำสั่งจากคน ว่าต้องการเขียนเรื่องอะไร มุมไหน โทนแบบใด
• research.md หรือผลสรุปจาก research agent

จากนั้นระบบจะเติมชั้นควบคุมเพิ่มเข้าไปอีก เช่น

• โปรไฟล์โครงสร้างของโพสต์
• โปรไฟล์คำศัพท์และคำต้องห้าม
• โปรไฟล์บุคลิกการเขียน
• few-shot examples ของโพสต์ดีๆ ที่เคยเขียนมาก่อน

ประเด็นนี้ใช้กับธุรกิจไทยได้ตรงมาก ถ้าเราต้องการให้ AI ช่วยร่างโพสต์เพจ ร่างอีเมลขาย หรือร่างบทความภายใน สิ่งที่ห้ามข้ามคือการทำ guideline template ให้ชัด ไม่อย่างนั้นข้อความจะออกมา generic ทุกครั้ง

ตัวอย่างของ guideline ที่ดีควรระบุอย่างน้อย:

• หัวข้อหลัก
• มุมที่ต้องการเล่า
• กลุ่มเป้าหมาย
• ประเด็นที่ต้องมี
• น้ำเสียง
• ข้อจำกัดเรื่องความยาว

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

Step 7: ใช้ reviewer loop เพื่อลด AI slop แทนการหวังให้ร่างแรกดีเลย

อีกเทคนิคที่มีประโยชน์มากคือ evaluator-optimizer pattern หรือพูดง่ายๆ คือให้ model ตัวหนึ่งเขียน แล้วให้อีกตัวหนึ่งตรวจ จากนั้นค่อยส่งกลับไปแก้ วนอยู่หลายรอบ

ระบบนี้มี 2 บทบาทหลัก

• Writer สร้างร่างแรก
• Reviewer ตรวจว่าร่างนั้นตรง guideline ตรง research และตรงโปรไฟล์หรือไม่

สิ่งที่น่าสนใจคือ reviewer ไม่ได้ปล่อยให้วิจารณ์แบบลอยๆ แต่บังคับให้ออกมาเป็น object ที่มีโครงสร้าง เช่น ผิดตรง profile ไหน อยู่ตรงส่วนใดของข้อความ และควรแก้อย่างไร

นี่เป็นแนวคิดที่เอาไปใช้กับงานอื่นได้เลย เช่น

• ร่างข้อเสนอขาย แล้วให้ reviewer เช็กว่ามีประเด็นผลลัพธ์ทางธุรกิจครบไหม
• ร่างประกาศภายใน แล้วให้ reviewer เช็กว่าใช้ภาษาตรงนโยบายองค์กรหรือไม่
• ร่างสรุปรายงานประชุม แล้วให้ reviewer เช็กว่ามี action item ครบหรือยัง

มุมที่ผู้เขียนเห็นด้วยมากคือ งานเขียนไม่ควรใช้เกณฑ์คะแนนอัตโนมัติมากเกินไป เพราะความสร้างสรรค์มีความ subjective สูง สุดท้ายทีมนี้เลือกใช้จำนวนรอบคงที่ เช่น 3 หรือ 4 รอบ แทนการ loop จนได้คะแนนถึง threshold ซึ่งสมเหตุสมผลกว่าสำหรับงานคอนเทนต์

Step 8: สังเกตระบบให้ได้ เพราะ AI ที่เดาไม่ออก แก้ไม่ได้

เมื่อระบบมีหลายขั้น ทั้งค้นเว็บ อ่านวิดีโอ เขียน ตรวจ และแก้ ปัญหาจะเริ่มซับซ้อน การดูแค่ log ใน terminal ไม่พออีกต่อไป ทีมนี้จึงเพิ่ม observability ด้วยเครื่องมืออย่าง Opik เพื่อดู trace ของแต่ละรอบการทำงาน

สิ่งที่ติดตามได้มีตั้งแต่

• ใช้ model อะไรบ้าง
• แต่ละขั้นกิน token เท่าไร
• แต่ละขั้นใช้เวลานานแค่ไหน
• input และ output ของแต่ละขั้นคืออะไร
• เครื่องมือไหนถูกเรียกใช้บ่อย

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

Step 9: ทำ evals เพื่อให้รู้ว่าระบบดีขึ้นจริง ไม่ใช่รู้สึกว่าดีขึ้น

ส่วนสุดท้ายของคลิปพูดเรื่องที่คนใช้ AI มักละเลย คือ evaluation หรือการวัดผลแบบเป็นระบบ

ทีมนี้ทำสิ่งที่ถูกต้องมาก คือสร้าง dataset จากโพสต์จริง แยกเป็น train, dev, test แล้วใช้ LLM judge มาช่วยตัดสินว่าผลลัพธ์ผ่านหรือไม่ผ่าน พร้อมเหตุผลสั้นๆ

ใจความสำคัญมี 3 ข้อ

• ถ้าจะวัดระบบ AI ต้องมีข้อมูลตัวอย่างที่มี label
• อย่าให้ AI สร้าง output มาทดสอบตัวเอง ควรใช้ output จากระบบจริง
• ต้องแยก dev กับ test เพื่อดูว่า judge overfit หรือไม่

แปลเป็นภาษาธุรกิจคือ ถ้าเรากำลังสร้าง AI ช่วยตอบลูกค้า ช่วยคัด lead หรือช่วยร่างเอกสาร เราควรมีชุดตัวอย่าง “งานดี” และ “งานพลาด” ของตัวเอง แล้วใช้มันเป็นมาตรฐาน ไม่ใช่ตัดสินด้วยความรู้สึกวันต่อวัน

จุดที่ควรพูดตรงๆ คือในคลิปมีตัวอย่างที่ judge ยังพลาดกับข้อมูล live อยู่บ้าง ซึ่งกลับเป็นเรื่องดี เพราะสะท้อนความจริงว่า evals ไม่ใช่เวทมนตร์ ต้องปรับ dataset และตัวอย่างไปเรื่อยๆ นี่ทำให้เนื้อหาของเวิร์กช็อปนี้น่าเชื่อถือกว่าคลิปที่ทำเหมือนทุกอย่างสมบูรณ์ตั้งแต่วันแรก

Step 10: แปลแนวคิดนี้ให้เข้ากับธุรกิจไทย

ถ้าตัดเรื่องโค้ดออกไป สิ่งที่เหลือคือ framework สำหรับสร้างระบบ AI ใช้งานจริงในองค์กร

สูตรย่อคือ: แยก “งานค้นหา” ออกจาก “งานเขียน” แล้วเพิ่มชั้นตรวจสอบและวัดผลเข้าไป

หน้าตาในธุรกิจไทยอาจเป็นแบบนี้

• บริษัท B2B ใช้ research agent เก็บข้อมูลอุตสาหกรรมลูกค้า แล้วให้ writing workflow ร่างอีเมลเปิดการขาย
• เอเจนซี ใช้ research agent รวบรวมข้อมูลตลาดและคู่แข่ง แล้วให้ workflow ทำ draft strategy memo
• สื่อหรือทีมคอนเทนต์ ใช้วิจัยหัวข้อจากเว็บและ YouTube ก่อนร่างบทความหรือโพสต์โซเชียล
• องค์กรที่มีองค์ความรู้เยอะ ใช้ workflow ทำคู่มือภายในหรือสรุปเอกสารนโยบายให้อ่านง่ายขึ้น

ข้อสำคัญคืออย่าเพิ่งเริ่มจากคำว่า “สร้าง agent” ให้เริ่มจากคำถามว่า “งานนี้มีขั้นคงที่หรือไม่” ถ้ามี ก็ใช้ workflow ก่อน ถ้าไม่มี และต้องค้นหา-ตัดสินใจ-เปลี่ยนทิศทางระหว่างทาง ค่อยขยับไปสู่ agent

Actionable Insights

• เลิกสั่ง AI แบบกว้างๆ แล้วทำ guideline template สำหรับงานแต่ละประเภท เช่น โพสต์ อีเมล รายงาน
• แยกงานวิจัยออกจากงานเขียน อย่าหวังให้ prompt เดียวทำทุกอย่างแล้วออกมาดี
• เก็บตัวอย่างงานดีขององค์กร เพื่อนำมาเป็น few-shot examples แทนการหวังให้ model เดาสไตล์เราเอง
• ใส่ชั้น reviewer loop แม้จะเป็นรอบสั้นๆ ก็ช่วยลดข้อความกลวงและภาษาซ้ำได้มาก
• วัดต้นทุนและคุณภาพควบคู่กัน ไม่ใช่ดูแค่ผลลัพธ์สวย แต่ต้องรู้ด้วยว่ากินเวลาและ token เท่าไร

Troubleshooting

ปัญหา: ได้คอนเทนต์ที่อ่านลื่นแต่ไม่มีสาระ

สาเหตุ: ระบบเขียนจากความรู้เดิมของ model ไม่ได้อิง research ที่เช็กแหล่งมาแล้ว

วิธีแก้: แยกขั้นค้นข้อมูลออกมาต่างหาก บังคับให้มีแหล่งอ้างอิง และส่งเฉพาะข้อมูลที่เกี่ยวข้องเข้า workflow เขียน

ปัญหา: ข้อความออกมาเหมือน AI ทุกครั้ง

สาเหตุ: ไม่มีโปรไฟล์ภาษา ไม่มีคำต้องห้าม และไม่มีตัวอย่างงานเขียนของจริง

วิธีแก้: สร้าง writing profiles ระบุโครงสร้าง น้ำเสียง คำที่ไม่ควรใช้ และเพิ่ม few-shot examples จากงานจริงขององค์กร

ปัญหา: ระบบแพงและช้าเกินไป

สาเหตุ: ส่ง context เยอะเกิน จำทุกอย่างไว้ตลอด และใช้ model แพงกับทุกขั้นตอน

วิธีแก้: ตัด context ให้สั้น ใช้ model คนละระดับตามงาน และแยกงานบางส่วนให้ tool ทำแทนการยัดทุกอย่างในรอบเดียว

ปัญหา: แก้ prompt ไปเรื่อยๆ แต่ไม่รู้ว่าดีขึ้นจริงไหม

สาเหตุ: ไม่มีชุดทดสอบและไม่มีเกณฑ์วัดผลคงที่

วิธีแก้: สร้าง dataset ขนาดเล็กก่อน แยกตัวอย่างผ่านและไม่ผ่าน แล้วใช้ judge หรือ checklist วัดผลทุกครั้งที่ปรับระบบ

ปัญหา: ระบบพังเป็นบางครั้งแต่หาสาเหตุไม่เจอ

สาเหตุ: มองไม่เห็นว่าแต่ละขั้นตอนส่งอะไรเข้าออกและเรียก tool ตัวไหนบ้าง

วิธีแก้: เพิ่ม observability เก็บ trace ของทุกขั้น ดู latency ต้นทุน และ output ของแต่ละรอบให้ย้อนตรวจได้

การต่อยอด

• ต่อยอดจาก LinkedIn post ไปสู่ workflow สำหรับร่างข้อเสนอขาย ข้อเสนอราคา หรือ executive summary
• เพิ่มแหล่งข้อมูลภายในองค์กร เช่น knowledge base, CRM, หรือเอกสารสินค้า เพื่อให้ research agent ใช้ข้อมูลเฉพาะธุรกิจได้
• สร้าง dashboard วัดผล AI ภายในทีม ว่าช่วยประหยัดเวลาจริงกี่ชั่วโมง และงานประเภทไหนควรใช้หรือไม่ควรใช้

สรุป Checklist ทั้งหมด

☐ นิยามก่อนว่างานที่ต้องการเป็น prompt, workflow หรือ agent

☐ แยก “งานค้นข้อมูล” ออกจาก “งานเขียน”

☐ ออกแบบ guideline template สำหรับแต่ละประเภทงาน

☐ เตรียมแหล่งข้อมูลที่เชื่อถือได้และดึงมาใช้ได้จริง

☐ สร้าง writing profiles เพื่อคุมโครงสร้าง น้ำเสียง และคำต้องห้าม

☐ เพิ่ม few-shot examples จากงานจริงขององค์กร

☐ ใช้ reviewer loop เพื่อตรวจและแก้หลายรอบ

☐ ตัด context ให้พอดี อย่ายัดทุกอย่างเข้าไปพร้อมกัน

☐ ติดตาม trace, ต้นทุน, เวลา และ output ของแต่ละขั้น

☐ สร้าง dataset และ evals เพื่อวัดว่าระบบดีขึ้นจริง

☐ เริ่มจาก use case เล็กที่มีผลต่อธุรกิจจริง แล้วค่อยขยาย

สรุปแล้ว เวิร์กช็อปนี้ไม่ได้สอนแค่สร้าง deep research agent แต่สอนวิธีคิดที่สำคัญกว่า คือ AI ที่ใช้จริงในธุรกิจต้องมีทั้งการค้นหา การควบคุม การตรวจสอบ และการวัดผล ถ้าเราหยิบแค่ส่วน “ให้ AI เขียน” ไปใช้ เรามักได้ข้อความสวยแต่ไร้น้ำหนัก แต่ถ้าออกแบบเป็นระบบแบบที่คลิปนี้เสนอ AI จะเริ่มกลายเป็นผู้ช่วยทำงาน ไม่ใช่แค่เครื่องผลิตคำพูด