Contact
Line : comsiam
Contact
Line : comsiam

เวลาถาม Google Gemini เรื่องที่ต้องอาศัยข้อมูลหลายส่วน ปัญหาที่พบบ่อยคือ AI อาจ รีบสรุปคำตอบเร็วเกินไป ก่อนตรวจว่าข้อมูลที่มีเพียงพอหรือไม่ มีจุดขัดแย้งตรงไหน หรือสาเหตุที่กำลังพูดถึงเป็นข้อเท็จจริงจริง ๆ หรือเป็นเพียงการคาดเดา
ตัวอย่างเช่น
ยอดขายเดือนนี้ลดลง 20% ช่วยบอกสาเหตุให้หน่อย
คำถามนี้อาจทำให้ Gemini รีบเสนอว่า
แต่ถ้าเราไม่ได้ให้ข้อมูลเกี่ยวกับ Traffic, Conversion Rate, ราคา, Campaign หรือจำนวนลูกค้า ข้อสรุปเหล่านี้ยังเป็นเพียง Hypothesis
Prompt ที่ดีกว่าคือ
วิเคราะห์ข้อมูลที่ฉันให้ก่อน อย่าเพิ่งสรุปสาเหตุ แยก Fact, Pattern, Anomaly, Missing Information และ Hypothesis จากนั้นค่อยเสนอ Conclusion เฉพาะส่วนที่ข้อมูลรองรับ
นี่เปลี่ยน Gemini จากการเป็นเพียง “เครื่องตอบคำถาม” ให้กลายเป็น “ผู้ช่วยวิเคราะห์ข้อมูลอย่างเป็นขั้นตอน”
บทความนี้จะอธิบาย วิธีสั่ง Gemini วิเคราะห์ข้อมูลก่อนสรุปคำตอบ พร้อม Prompt Template สำหรับข้อมูลธุรกิจ การตลาด SEO Coding Report และงานวิเคราะห์ทั่วไป
เพราะคำตอบที่เร็วไม่จำเป็นต้องเป็นคำตอบที่แม่น
งานวิเคราะห์ที่ดีควรมีขั้นตอนประมาณนี้
Data → Observation → Pattern → Hypothesis → Evidence → Conclusion → Action
แต่ถ้าเราใช้ Prompt กว้าง ๆ Gemini อาจกระโดดจาก
Data → Conclusion
ทันที
ปัญหาคือระหว่างสองจุดนี้ยังมีคำถามสำคัญ เช่น
ดังนั้นการบอก Gemini ให้ “วิเคราะห์ก่อน” ช่วยลดการสรุปเร็วเกินไป
ใช้โครงสร้าง
Input + Analysis Steps + Evidence Rule + Conclusion Rule
ตัวอย่าง
จากข้อมูลด้านล่าง:
[DATA]ทำตามลำดับ:
- สรุป Facts ที่เห็นจากข้อมูล
- หา Patterns และ Anomalies
- ระบุ Missing Information
- สร้าง Hypotheses
- ระบุ Evidence ที่สนับสนุนหรือขัดแย้งแต่ละ Hypothesis
- ค่อยสรุปเฉพาะสิ่งที่ข้อมูลรองรับ
ห้ามสรุป Root Cause หากยังไม่มี Evidence เพียงพอ
เพียงเท่านี้คำตอบก็มักมีโครงสร้างการวิเคราะห์ที่ดีขึ้นมาก
เริ่มจาก
สรุปสิ่งที่ข้อมูล “บอกตรง ๆ” ก่อน โดยยังไม่ตีความสาเหตุ
ตัวอย่าง
จากตารางยอดขายนี้ สรุปเฉพาะ:
- ยอดขายรวม
- การเปลี่ยนแปลงรายเดือน
- ช่วงที่สูงสุด
- ช่วงที่ต่ำสุด
ยังไม่ต้องอธิบายสาเหตุ
นี่ช่วยแยก Observation ออกจาก Interpretation
Prompt:
แบ่งคำตอบเป็น:
Facts — ข้อมูลที่ยืนยันได้โดยตรง
Interpretations — ความหมายที่อาจตีความจากข้อมูล
Unknowns — สิ่งที่ข้อมูลยังตอบไม่ได้
ตัวอย่าง
Conversion Rate ลดจาก 3% เหลือ 2%
หน้า Landing Page อาจมีปัญหา
สองอย่างไม่เหมือนกัน
Fact ยืนยันได้จากตัวเลข
Interpretation ยังต้องตรวจเพิ่ม
Prompt:
สำหรับทุก Finding ให้ระบุว่าเป็น Observation หรือ Cause
หากเป็น Cause ต้องมี Evidence สนับสนุน หากไม่มี ให้ Label เป็น Hypothesis
ช่วยป้องกันคำตอบแบบ
“ยอดขายลดเพราะโฆษณาไม่ดี”
ทั้งที่เรารู้เพียงว่า
ยอดขายลด
Prompt:
วิเคราะห์ข้อมูลนี้เพื่อหา Pattern เช่น Trend, Repetition, Seasonality, Relationship และ Change Point โดยยังไม่สรุปสาเหตุ
เหมาะกับ
Anomaly คือค่าหรือเหตุการณ์ที่ผิดไปจาก Pattern ปกติ
Prompt:
หา Data Points ที่ผิดจากแนวโน้มปกติอย่างชัดเจน และอธิบายว่าทำไมจึงควรตรวจเพิ่ม โดยยังไม่สรุปว่าเป็น Error
ตัวอย่าง
ยอดขายแต่ละวันประมาณ
80,000–100,000 บาท
แต่วันหนึ่งเหลือ
15,000 บาท
ถือเป็นจุดที่ควรตรวจ
แต่ไม่ควรสรุปทันทีว่า
ระบบล่ม
จนกว่าจะมี Evidence
Prompt ที่มีประโยชน์มากคือ
ก่อน Conclusion ระบุข้อมูลที่ยังขาดและสามารถเปลี่ยนข้อสรุปได้
ตัวอย่างยอดขายลดลง อาจต้องดู
ถ้าไม่มีข้อมูลเหล่านี้ คำตอบควรมีข้อจำกัด
Prompt:
อย่าระบุ Root Cause ทันที ให้สร้าง Hypotheses ที่เป็นไปได้ก่อน
ตัวอย่าง
| Hypothesis | สิ่งที่ต้องตรวจ |
|---|---|
| Traffic ลด | Sessions |
| Conversion ลด | Conversion Rate |
| AOV ลด | Average Order Value |
| Stock Out | Inventory |
| Checkout Error | Error Log |
นี่ทำให้การวิเคราะห์สามารถนำไปตรวจต่อได้
Prompt:
เรียง Hypothesis จาก:
- มี Evidence สนับสนุนมากที่สุด
- มี Evidence บางส่วน
- ยังไม่มี Evidence
จะดีกว่าการเรียงตามสิ่งที่ AI “คิดว่าน่าจะเป็น”
อย่าดูแต่ข้อมูลที่สนับสนุน
Prompt:
สำหรับแต่ละ Hypothesis ให้ระบุทั้ง:
- Evidence For
- Evidence Against
- Missing Evidence
ช่วยลด Confirmation Bias
Prompt:
สร้างสาเหตุที่เป็นไปได้อย่างน้อย 3 แบบที่แข่งขันกัน แล้วบอกว่าข้อมูลอะไรจะแยกแต่ละ Hypothesis ออกจากกันได้
เหมาะกับ Troubleshooting และ Business Analysis
Prompt:
สร้าง Section ชื่อ “สิ่งที่ยังสรุปไม่ได้จากข้อมูลนี้” ก่อน Final Recommendation
นี่เป็นเทคนิคง่ายแต่มีประโยชน์มาก
เพราะคำตอบที่ดีควรบอกทั้ง
สิ่งที่รู้
และ
สิ่งที่ยังไม่รู้
Prompt:
แบ่งข้อมูลเป็น:
Known
สิ่งที่ข้อมูลยืนยันUnknown
สิ่งที่ยังไม่มีข้อมูลNeed to Verify
สิ่งที่มีสัญญาณแต่ยังต้องตรวจ
เหมาะกับการวิเคราะห์ที่ข้อมูลไม่สมบูรณ์
ก่อนวิเคราะห์ ควรถามว่า Data ใช้ได้หรือไม่
Prompt:
ตรวจ Data Quality ก่อนวิเคราะห์ โดยดู:
- Missing Values
- Duplicate Data
- Outliers
- Inconsistent Units
- Invalid Values
- Date Range
หากพบปัญหา ให้แยกออกก่อน Conclusion
เพราะ Analysis ที่ดีบน Data ผิดก็ยังได้คำตอบผิด
ตัวอย่าง
บาง Row เป็น
บาท
บาง Row เป็น
ดอลลาร์
แต่ถ้าไม่ได้บอก AI อาจนำมารวมกัน
Prompt:
ตรวจ Unit และ Currency ก่อนคำนวณหรือเปรียบเทียบ หากไม่ตรงกันให้หยุดและแจ้งก่อน
Prompt:
ตรวจว่าข้อมูลทุกชุดอยู่ในช่วงเวลาเดียวกันหรือไม่ หากเปรียบเทียบคนละช่วงให้ระบุข้อจำกัดก่อนสรุป
เช่น
มกราคม–มีนาคม 2025
เทียบกับ
มกราคม–มิถุนายน 2026
ไม่ควรสรุปง่าย ๆ โดยไม่ Normalize
คำว่า “เพิ่มขึ้น” หรือ “ลดลง” ต้องเทียบกับอะไร
Prompt:
ก่อนสรุป Trend ให้ระบุ Baseline ที่ใช้เปรียบเทียบ เช่น Previous Month, Previous Year หรือ Target
ตัวอย่าง
ยอดขายเพิ่ม 10%
แต่เพิ่มจาก
ความหมายต่างกัน
Prompt:
หากมีการคำนวณ ให้แสดง Formula, Input และ Result แยกก่อนนำค่าที่ได้ไปใช้ใน Conclusion
ตัวอย่าง
Conversion Rate = Sales / Visitors × 100
ช่วยให้ตรวจเลขง่ายขึ้น
หนึ่งในข้อผิดพลาดสำคัญในการวิเคราะห์ข้อมูลคือ
A เกิดพร้อม B จึงสรุปว่า A ทำให้ B
Prompt:
หากพบความสัมพันธ์ระหว่างตัวแปร ให้เรียกว่า Correlation ก่อน และห้ามสรุป Causation หากไม่มีหลักฐานด้านเหตุและผล
เช่น
Traffic ลดพร้อมยอดขายลด
ไม่ได้แปลว่า Traffic เป็นสาเหตุเดียวเสมอไป
Prompt:
ก่อนสรุปสาเหตุ ให้เสนอ Alternative Explanations อย่างน้อย 3 แบบที่อาจอธิบายข้อมูลเดียวกันได้
ช่วยลดการยึดติดกับคำอธิบายแรก
Prompt:
หาก Hypothesis นี้เป็นจริง เราคาดว่าจะเห็นข้อมูลอะไรเพิ่ม? และหากไม่จริง เราควรเห็นอะไร?
ตัวอย่าง
ถ้าสาเหตุคือ
Traffic ลด
เราควรเห็น
Sessions ลด
ถ้า Sessions ไม่ลด ก็ต้องมองสาเหตุอื่น
5 Whys มีประโยชน์ แต่ถ้าไม่มีข้อมูล AI อาจเดาต่อเป็นทอด ๆ
Prompt ที่ดีกว่า
ใช้ 5 Whys แต่หยุดทันทีเมื่อขั้นถัดไปไม่มี Evidence และระบุข้อมูลที่ต้องตรวจแทนการเดา
นี่สำคัญมาก
Prompt:
สร้าง Root Cause Tree สำหรับ
[Problem]แบ่ง Possible Causes เป็นหมวด และระบุ Evidence ที่ใช้ตัดแต่ละ Branch
ตัวอย่าง
ยอดขายลด
อาจแบ่งเป็น
Traffic ลด
Conversion ลด
AOV ลด
Repeat Purchase ลด
Stock / Checkout / Delivery
มีระบบกว่ารายการสาเหตุแบบสุ่ม
เหมาะมากกับธุรกิจและ Marketing
ตัวอย่าง Funnel:
Traffic → Lead → Sale → Repeat
Prompt:
วิเคราะห์ Funnel ทีละ Stage ก่อน และหาว่า Stage ไหนเปลี่ยนมากที่สุดเมื่อเทียบกับ Baseline จากนั้นค่อยสร้าง Hypotheses เฉพาะ Stage นั้น
ช่วยลดพื้นที่ค้นหาสาเหตุ
ตัวอย่าง
Visitors = 100,000
Leads = 5,000
Sales = 500
Prompt:
คำนวณ Conversion Rate แต่ละ Stage แล้วเปรียบเทียบกับ Period ก่อน จากนั้นระบุว่าความเปลี่ยนแปลงหลักเกิดที่ Stage ไหน
นี่ดีกว่าถามว่า
ทำไมยอดขายลด?
เพราะเริ่มจากตำแหน่งปัญหา
Revenue มักแยกได้เป็น
Traffic × Conversion Rate × Average Order Value
Prompt:
วิเคราะห์ว่าการเปลี่ยน Revenue อธิบายได้จาก Traffic, Conversion หรือ AOV มากที่สุด โดยใช้ข้อมูลที่ให้เท่านั้น
ช่วยวิเคราะห์เป็นส่วนประกอบ
Prompt:
แยกการเติบโตเป็น Drivers เช่น Customer Count, Frequency, Price และ Average Basket แล้วระบุว่าตัวใดเปลี่ยนมากที่สุด
เหมาะกับธุรกิจ Retail และ Ecommerce
Prompt:
อย่าเสนอ Action Plan จนกว่าจะสรุป Trend และ Problem Area จากข้อมูลก่อน
นี่ช่วยไม่ให้ Recommendation เป็น Generic
Prompt:
ทุก Recommendation ต้องระบุว่าแก้ Finding หรือ Hypothesis ข้อใด หากเชื่อมโยงไม่ได้ ให้ตัด Recommendation นั้นออก
ทำให้คำแนะนำมีเหตุผลมากขึ้น
รูปแบบ Output ที่ดีคือ
| Finding | Evidence | Confidence | Recommended Next Step |
|---|
Prompt:
ตอบทุก Finding ใน Format นี้
ช่วยลดคำตอบแบบลอย ๆ
อีกโครงสร้างหนึ่ง
| Observation | Hypothesis | Test | Expected Signal |
|---|
เหมาะกับงาน Diagnosis
Prompt:
หลังวิเคราะห์ข้อมูลแล้ว ให้ระบุคำถามถัดไป 3 ข้อที่ถ้าได้คำตอบจะลดความไม่แน่นอนได้มากที่สุด
ช่วยให้เราเก็บข้อมูลอย่างมีเป้าหมาย
Prompt:
หากสามารถขอ Data เพิ่มได้เพียง 3 อย่าง ควรขออะไรเพื่อแยก Hypotheses ที่มีอยู่ได้ดีที่สุด?
มีประโยชน์มากกับ Data Analysis ที่ข้อมูลไม่ครบ
Prompt:
จัดลำดับ Data ที่ควรเก็บเพิ่มตามว่าข้อมูลใดมีโอกาสเปลี่ยน Conclusion หรือแยกสาเหตุได้มากที่สุด
นี่ช่วยลดการเก็บ Data ทุกอย่างโดยไม่จำเป็น
Prompt:
ระบุ Assumptions สำคัญใน Conclusion และวิเคราะห์ว่าถ้า Assumption เปลี่ยน Recommendation จะเปลี่ยนหรือไม่
เหมาะกับ Forecast และ Business Decision
Prompt:
สร้าง Conservative, Base และ Upside Scenario โดยแสดง Assumptions แยกกัน และอย่านำ Scenario ไปเขียนเหมือน Actual Data
ช่วยวิเคราะห์ความไม่แน่นอนอย่างชัดเจน
Prompt:
ระบุ Worst-case Scenario ที่สมเหตุสมผลจากข้อมูลและข้อจำกัดที่ให้ พร้อม Early Warning Indicators
เหมาะกับ Risk Analysis
Prompt:
สร้าง Upside Scenario โดยใช้เฉพาะ Assumptions ที่ระบุชัด ห้ามสร้าง Growth Rate โดยไม่มี Basis
Prompt:
สมมติว่า Plan นี้ล้มเหลวในอีก 6 เดือน วิเคราะห์สาเหตุที่เป็นไปได้จากข้อมูลปัจจุบัน และ Label ทุกข้อว่าเป็น Scenario ไม่ใช่ Fact
ช่วยหา Risk ที่อาจมองข้าม
Prompt:
ก่อน Final Recommendation ให้ท้าทายข้อสรุปของตัวเอง โดยหา Evidence หรือ Scenario ที่อาจทำให้ Recommendation นี้ผิด
นี่ช่วยลดการสรุปทางเดียว
Prompt:
เสนอ Argument ที่แข็งแรงที่สุดต่อ Recommendation นี้ แล้วบอกว่าต้องมีข้อมูลอะไรจึงจะตัดสินได้ดีขึ้น
เหมาะกับ Decision Making
ถ้าเรามีข้อมูลลูกค้า
อย่าเริ่ม
เขียน Marketing Copy
ทันที
ใช้
วิเคราะห์ Customer Pain Points และ Buying Objections จากข้อมูลนี้ก่อน แล้วค่อยสร้าง Message ที่เชื่อมกับ Findings
ช่วยให้ Content มี Context จริง
Prompt:
จาก Keyword/Query Data นี้ ให้จัดกลุ่ม Intent, Questions และ Problems ก่อน แล้วค่อยเสนอ Content Topics โดยห้ามสร้าง Search Volume ใหม่
ช่วยลดการคิด Topic แบบเดา
Prompt:
วิเคราะห์ Traffic, Engagement และ Conversion เพื่อหาหน้าที่มีปัญหาก่อน อย่าเสนอการ Redesign ทั้งเว็บไซต์ทันที
ช่วยหา Page ที่ควรแก้จริง
Prompt:
ก่อนแนะนำเพิ่ม Budget ให้ตรวจ CPA, Conversion, Revenue, Margin และ Trend เทียบกับ Baseline แล้วระบุข้อจำกัดของ Data
การเพิ่มงบโดยดูเพียง ROAS ตัวเดียวอาจไม่พอ
Prompt:
จัด Feedback เป็น Themes, Frequency, Severity และ Evidence ก่อนสรุป Top Problems ห้ามนับข้อความเดียวซ้ำหลาย Theme โดยไม่มีเหตุผล
Prompt:
จัด Ticket ตาม Issue Category แล้วนับ Frequency จากข้อมูลจริง ก่อนเสนอ Priority แก้ปัญหา
ช่วยให้ Priority มาจาก Data
Prompt:
แยก Quantitative Results กับ Open-text Themes และอย่าสรุปว่าความเห็นกลุ่มเล็กแทนผู้ตอบทั้งหมด
สำคัญกับ Survey Data
Prompt:
สรุป Positive Themes, Negative Themes และ Repeated Complaints จาก Reviews ที่ให้เท่านั้น ห้ามสร้าง Customer Sentiment ที่ไม่มีข้อความรองรับ
Master rule ที่ใช้ได้กว้างคือ
No Recommendation Before Diagnosis.
ใน Prompt สามารถเขียนว่า
ห้ามเสนอ Recommendation ก่อนจบ Analysis Section และทุก Recommendation ต้องอ้าง Finding ที่เกี่ยวข้อง
<OBJECTIVE>[คำถามหรือสิ่งที่ต้องการตัดสินใจ]</OBJECTIVE>
<DATA>[ข้อมูล]</DATA>ทำงานตามลำดับ:
- ตรวจ Data Quality
- สรุป Facts
- หา Trends และ Patterns
- หา Anomalies
- ระบุ Missing Information
- แยก Observation ออกจาก Interpretation
- สร้าง Hypotheses
- ระบุ Evidence For / Against แต่ละ Hypothesis
- ระบุสิ่งที่ยังสรุปไม่ได้
- สร้าง Conclusion เฉพาะส่วนที่ข้อมูลรองรับ
- เสนอ Next Checks หรือ Actions
Constraints:
- ห้ามสร้างข้อมูล
- ห้ามเปลี่ยน Correlation ให้เป็น Causation
- ห้ามเรียก Hypothesis ว่า Root Cause หากยังไม่มี Evidence
- หากข้อมูลไม่พอ ให้ระบุ Missing Data แทนการเดา
ธุรกิจ:
[BUSINESS]ปัญหา:
[PROBLEM]Data:
[DATA]ก่อน Recommendation ให้:
- สรุป Facts
- เปรียบเทียบกับ Baseline
- ระบุ Metrics ที่เปลี่ยนมากที่สุด
- สร้าง Possible Causes
- ระบุ Data ที่ต้องตรวจเพิ่ม
- แยก Root Cause ที่ยืนยันได้จาก Hypothesis
แล้วค่อยเสนอ Actions
ข้อมูลยอดขาย:
[DATA]วิเคราะห์ Revenue ผ่าน:
- Customer Count
- Conversion
- Average Order Value
- Repeat Purchase
ระบุว่า Driver ใดเปลี่ยนมากที่สุด และอย่าสรุปสาเหตุที่ไม่มีข้อมูล
Funnel:
Visitors:
[ ]
Leads:[ ]
Sales:[ ]
Revenue:[ ]Baseline:
[ข้อมูลเดิม]คำนวณ Conversion แต่ละ Stage แล้วหาว่าจุดใดเปลี่ยนมากที่สุด จากนั้นสร้าง Hypotheses เฉพาะ Stage นั้น พร้อม Evidence Needed
Campaign Data:
[DATA]วิเคราะห์:
- Spend
- Reach
- Clicks
- CTR
- Leads
- Conversion
- Revenue
- CPA/ROAS ถ้าข้อมูลเพียงพอ
อย่าสรุปว่า Campaign ดีหรือแย่จาก Metric เดียว
Search Data:
[DATA]วิเคราะห์:
- Impressions
- CTR
- Position
- Queries
- Landing Pages
แยกปัญหาที่อาจมาจาก Visibility, CTR หรือ Ranking ก่อนเสนอวิธีแก้
Traffic ลดจาก
[A]เป็น[B]ก่อนสรุปสาเหตุ ให้ตรวจ:
- Channel
- Device
- Country
- Landing Page
- Date Range
- Tracking Changes
ระบุว่า Data ใดไม่มีและต้องตรวจเพิ่ม
Traffic ยังใกล้เคียงเดิม แต่ Conversion ลด
ช่วยสร้าง Diagnostic Tree แบ่ง:
- Traffic Quality
- Offer
- Price
- UX
- Technical
- Trust
ห้ามสรุปสาเหตุจนกว่าจะมี Evidence
จาก Query Data ต่อไปนี้
[DATA]ช่วยหา:
- Primary Intent
- Supporting Questions
- Recurring Problems
- Commercial Signals
จากนั้นจึงเสนอ Article Topics โดยห้ามสร้าง Query หรือ Search Volume ที่ไม่มีใน Data
ใช้เฉพาะ Customer Data
[DATA]สรุป:
- Goals
- Problems
- Behaviors
- Objections
- Repeated Patterns
ห้ามสร้าง Age, Income หรือ Demographics ที่ไม่มีข้อมูล
จากข้อมูลคู่แข่งที่ให้:
[DATA]เปรียบเทียบตาม Criteria เดียวกัน และหากข้อมูลส่วนใดไม่มีให้ใช้ N/A ห้ามเติมข้อมูลจากการเดา
วิเคราะห์ Report นี้โดยแยก:
- Key Facts
- Trends
- Variances
- Risks
- Unknowns
- Decisions Needed
อย่าเพิ่มข้อมูลนอก Report
ก่อนสรุป Spreadsheet นี้ ให้ตรวจ:
- Missing Values
- Duplicate Rows
- Outliers
- Invalid Values
- Units
จากนั้นค่อยวิเคราะห์ Trend และ Insights
วิเคราะห์ Survey โดยแยก:
Quantitative:
- Distribution
- Top Responses
Qualitative:
- Recurring Themes
- Examples
Limitations:
- Sample Size
- Missing Responses
ห้ามสรุปเกินข้อมูลที่มี
Environment:
[ENVIRONMENT]Error:
[ERROR]Code:
[CODE]ก่อนเสนอ Fix:
- สรุป Expected vs Actual
- หา First Failure Point
- สร้าง Hypotheses
- ระบุ Evidence ใน Stack Trace/Code
- เลือก Root Cause ที่มี Evidence มากที่สุด
แล้วค่อยเสนอ Minimal Fix
อ่าน Log ตามเวลาและหา:
- Last Normal Event
- First Anomaly
- First Error
- Cascading Errors
ห้ามถือว่า Error บรรทัดสุดท้ายเป็น Root Cause โดยอัตโนมัติ
Query:
[QUERY]Schema:
[SCHEMA]Existing Indexes:
[INDEXES]Execution Plan:
[PLAN]ก่อนเสนอ Index ให้ระบุ Bottleneck จาก Evidence เช่น Scan, Join, Sort หรือ Cardinality
Performance Data:
[PROFILE]Code:
[CODE]ใช้ Profile Data เป็นหลักก่อนเสนอ Optimization ห้าม Rewrite Code ที่ไม่มี Evidence ว่าเป็น Bottleneck
Incident Data:
[LOGS / TIMELINE]แยก:
- Impact
- Timeline
- First Anomaly
- Confirmed Cause
- Contributing Factors
- Unknowns
ห้ามสร้าง Root Cause เพื่อให้ Postmortem ดูครบ
Project Data:
[DATA]วิเคราะห์:
- Planned vs Actual
- Critical Path
- Blockers
- Dependencies
- Resource Constraints
อย่าสรุปว่าใครเป็นสาเหตุโดยไม่มีข้อมูล
ใช้เฉพาะ Performance Data ที่ให้ แยก System/Process Issues ออกจาก Individual Issues และห้ามสรุปคุณภาพบุคคลจาก Metric เดียว
ประโยคง่าย ๆ ที่มีประโยชน์คือ
รอบแรกวิเคราะห์เท่านั้น ยังไม่ต้องเสนอ Solution
จากนั้นหลังเห็น Analysis แล้วค่อยถาม
จาก Analysis นี้ มี Solution ใดที่ตรง Root Problem มากที่สุด?
ช่วยป้องกันการสร้าง Solution ก่อนเข้าใจ Problem
สามารถล็อก Workflow ว่า
Analysis
Diagnosis
Recommendation
Prompt:
ห้ามข้าม Phase และห้ามเสนอ Recommendation ใน Phase 1
เหมาะกับงานที่มีข้อมูลจำนวนมาก
สำหรับข้อมูลใหญ่
ใช้
Summary
Patterns
Drivers
Root Cause
Action
ทำให้ไม่กระโดดข้ามขั้น
Prompt:
Final Summary ต้องใช้เฉพาะ Findings ที่เกิดจาก Analysis ก่อนหน้า ห้ามเพิ่ม Conclusion ใหม่ใน Summary
ช่วยป้องกัน Summary มีข้อมูลที่ Analysis ไม่เคยพูด
แทนการขอ
Confidence 95%
ใช้
ระบุ Evidence Strength เป็น Strong / Moderate / Weak พร้อมเหตุผล
เพราะตัวเลข Confidence จาก AI ไม่ได้เป็นความน่าจะเป็นที่รับรอง
ตัวอย่าง
มีข้อมูลตรงหลายจุด
มีสัญญาณแต่ยังมีคำอธิบายอื่น
เป็นเพียง Hypothesis
Prompt:
ใช้ระดับ Evidence Strength นี้ในทุก Conclusion
Prompt:
ทุก Analysis ต้องมี Section “ข้อจำกัดของข้อมูล” ก่อน Recommendation
ช่วยให้ผู้ใช้รู้ว่าคำตอบควรเชื่อได้แค่ไหน
Prompt:
ตรวจว่าการวิเคราะห์กำลังให้ความสำคัญกับข้อมูลที่สนับสนุนสมมติฐานแรกมากเกินไปหรือไม่ และหา Evidence ที่ขัดแย้งด้วย
เหมาะกับข้อมูลที่มีความคลุมเครือ
Prompt:
หาก Sample Size น้อย ให้ระบุข้อจำกัดและหลีกเลี่ยงการ Generalize ไปยังประชากรทั้งหมด
สำคัญกับ Survey และ Customer Feedback
สองจุดอาจบอก
เพิ่ม
แต่ยังไม่ใช่ Trend ระยะยาว
Prompt:
แยกระหว่าง Short-term Change กับ Sustained Trend และอย่าเรียกข้อมูลไม่กี่จุดว่า Trend โดยไม่มีบริบท
Average อาจซ่อน Distribution
Prompt:
หากข้อมูลมี Distribution ให้ดู Median, Range หรือ Segments เพิ่ม ไม่ใช้ Average เพียงตัวเดียวในการสรุป
ตัวอย่างยอดรวมดูปกติ แต่ Mobile อาจลดมาก
Prompt:
วิเคราะห์ Overall ก่อน แล้ว Segment ตาม
[Channel/Device/Region/Product]เพื่อดูว่าความเปลี่ยนแปลงมาจากกลุ่มใด
Workflow:
Overall → Segment → Metric → Record
Prompt:
เริ่มจาก Overall Trend แล้ว Drill Down ไปยัง Segment ที่เปลี่ยนมากที่สุด ไม่ต้องวิเคราะห์ทุก Segment เท่ากัน
ช่วยประหยัดเวลา
Prompt:
หา 20% ของ Categories ที่สร้างประมาณ 80% ของ Impact จาก Data ที่ให้ หากข้อมูลไม่รองรับ 80/20 ตรง ๆ ให้ใช้เป็นแนวทางจัดอันดับแทน
อย่าบังคับให้ต้องได้ 80/20 เป๊ะ
Prompt:
เปรียบเทียบ Before และ After โดยแยก:
- Metric Difference
- Absolute Change
- Percentage Change
- Other Changes ที่เกิดพร้อมกัน
ห้ามสรุปว่าการเปลี่ยนแปลงเกิดจาก Intervention เพียงอย่างเดียวหากไม่มี Control
Prompt:
วิเคราะห์ผล A/B Test โดยดู Sample Size, Conversion และ Difference ก่อน ห้ามประกาศ Winner จาก Percentage ต่างกันอย่างเดียว หากข้อมูล Statistical Confidence ไม่พอให้ระบุข้อจำกัด
Prompt:
แยก:
Hypothesis
Change
Metric
Result
Confounders
Conclusion
Next Test
ช่วยลดการตีความเกิน Experiment
ใช้ Analysis ที่ได้เป็น Input ในการตัดสินใจ โดย Recommendation ต้องระบุ:
- Supporting Evidence
- Key Assumption
- Main Risk
- What Would Change the Recommendation
เป็น Decision Support ที่แข็งแรงขึ้น
Prompt:
ระบุ Evidence ใหม่แบบใดที่จะทำให้คุณเปลี่ยน Conclusion ปัจจุบัน
ช่วยป้องกัน Conclusion ที่ปิดตาย
Prompt:
ก่อน Recommendation ให้ระบุว่าการตัดสินใจนี้ Reversible หรือ Irreversible และปรับระดับ Evidence ที่ต้องการให้เหมาะสม
Decision ที่ย้อนกลับไม่ได้ควรต้องมีหลักฐานสูงกว่า
Prompt:
ถ้ายังมีความไม่แน่นอน ให้เสนอ Experiment ที่เล็กและย้อนกลับได้ก่อนการตัดสินใจเต็มรูปแบบ
เหมาะกับ
①
สรุป Facts ก่อน ยังไม่ต้องตีความ
②
แยก Observation ออกจาก Cause
③
หา Missing Data ก่อน Conclusion
④
สร้าง Hypotheses แทนการเดา Root Cause
⑤
ระบุ Evidence For และ Against
⑥
แยก Known / Unknown
⑦
อย่าสรุป Causation จาก Correlation
⑧
Recommendation ต้องเชื่อมกับ Finding
⑨
ระบุสิ่งที่ยังสรุปไม่ได้
⑩
ตรวจ Alternative Explanations ก่อน Final
ถ้าจะจำเพียง 5 ข้อ ให้ใช้
สรุป Facts ก่อน
แยก Fact กับ Hypothesis
ระบุ Missing Information
หา Evidence ก่อน Root Cause
ค่อย Recommendation หลัง Analysis
เพียงเท่านี้ช่วยปรับคุณภาพงานวิเคราะห์ได้มาก
บังคับ AI ให้เดา
ไม่รู้ว่า “ดีขึ้น” เทียบกับอะไร
แต่ยังต้องการ Conclusion ชัด
Garbage In, Garbage Out
เห็นพร้อมกันไม่ได้แปลว่าเหตุผลเดียวกัน
ซ่อน Segment
เกิด Confirmation Bias
ได้คำแนะนำทั่วไป
คำตอบดูมั่นใจกว่าหลักฐาน
Insight อาจมาจากข้อมูลที่ตีความผิด
ตรวจว่า
① Objective ชัดหรือไม่
② Data ครบพอหรือไม่
③ Period ชัดหรือไม่
④ Baseline มีหรือไม่
⑤ Units ตรงกันหรือไม่
⑥ Missing Values มีหรือไม่
⑦ Segments สำคัญมีอะไร
⑧ Metrics หลักคืออะไร
⑨ ต้องการหา Trend หรือ Cause
⑩ Data รองรับ Causation หรือไม่
⑪ มี Hypothesis เดิมที่อาจทำให้ Bias หรือไม่
⑫ Missing Data ต้องระบุหรือไม่
⑬ Output Format คืออะไร
⑭ Recommendation ต้องรอ Analysis หรือไม่
⑮ ต้องตรวจ Evidence Strength หรือไม่
หลัง Gemini ตอบ ตรวจว่า
① Facts แยกชัด
② ไม่มีข้อมูลที่สร้างขึ้นเอง
③ Pattern มี Evidence
④ Anomaly มีข้อมูลรองรับ
⑤ Hypothesis ถูก Label
⑥ Missing Data ถูกระบุ
⑦ Cause ไม่ถูกสรุปเร็วเกินไป
⑧ Correlation ไม่ถูกเขียนเป็น Causation
⑨ Recommendation เชื่อมกับ Finding
⑩ Limitations ชัด
⑪ มี Next Check
⑫ Conclusion ไม่แรงเกิน Evidence
<QUESTION>[สิ่งที่ต้องการรู้]</QUESTION>
<DATA>[ข้อมูล]</DATA>
<BASELINE>[ข้อมูลที่ใช้เปรียบเทียบ]</BASELINE>ทำงานตามลำดับ:
Phase 1 — Data Check
- ตรวจ Missing Values
- ตรวจ Units
- ตรวจ Date Range
- ตรวจ Outliers
- ตรวจข้อมูลขัดกัน
Phase 2 — Facts
สรุปเฉพาะสิ่งที่ข้อมูลยืนยัน
Phase 3 — Analysis
- Trends
- Patterns
- Segments
- Anomalies
Phase 4 — Diagnosis
- Possible Hypotheses
- Evidence For
- Evidence Against
- Missing Evidence
Phase 5 — Conclusion
สรุปเฉพาะสิ่งที่ Evidence รองรับ
Phase 6 — Next Action
เสนอ Data หรือ Test ที่ควรทำต่อ
Constraints:
- ห้ามสร้างข้อมูลใหม่
- ห้ามเดา Root Cause
- ห้ามสรุป Causation จาก Correlation
- หากข้อมูลไม่พอ ให้ระบุ Unknowns
วิเคราะห์ข้อมูลนี้ก่อนสรุป โดยทำตามลำดับ:
Facts → Patterns → Anomalies → Missing Data → Hypotheses → Evidence → Conclusion → Next Action
ห้ามสรุป Root Cause หากยังไม่มี Evidence และห้ามสร้างข้อมูลที่ไม่มีใน Input
เป็น Prompt สั้นที่ใช้ได้กับงานจำนวนมาก
ทุกครั้งที่ฉันส่งข้อมูลให้วิเคราะห์ ให้ใช้กฎต่อไปนี้:
- อย่ารีบตอบ Conclusion
- ตรวจ Data Quality ก่อน
- แยก Fact ออกจาก Interpretation
- ระบุ Missing Information
- สร้าง Hypotheses เมื่อจำเป็น
- ระบุ Evidence สนับสนุนและคัดค้าน
- ห้ามสรุป Correlation เป็น Causation
- Recommendation ต้องเชื่อมกับ Finding
- ระบุข้อจำกัดของข้อมูล
- หาก Evidence ยังไม่พอ ให้ตอบว่า “ยังสรุปไม่ได้”
Output:
Facts
Analysis
Hypotheses
Missing Information
Conclusion
Recommended Next Check
ถ้าไม่ต้องการจำ Prompt ยาว ให้จำสูตร
Facts → Patterns → Hypotheses → Evidence → Conclusion → Action
หรือแบบย่อมาก
วิเคราะห์ก่อน สรุปทีหลัง
จากข้อมูล
[DATA]ช่วยวิเคราะห์ก่อนสรุปคำตอบ โดยเริ่มจากข้อเท็จจริงที่ข้อมูลยืนยัน จากนั้นหา Pattern และ Anomaly ระบุ Missing Information และสร้าง Hypotheses ที่เป็นไปได้ พร้อม Evidence ที่สนับสนุนหรือขัดแย้งแต่ละข้อ ห้ามเรียก Hypothesis ว่า Root Cause จนกว่าจะมีหลักฐานเพียงพอ และค่อยสร้าง Recommendation หลังจากสรุป Findings แล้ว หากข้อมูลไม่พอ ให้ระบุสิ่งที่ยังไม่สามารถสรุปได้แทนการเดา
หากต้องการใช้ Google Gemini กับงานวิเคราะห์ สิ่งสำคัญคืออย่าเริ่มจากคำสั่งว่า
บอกสาเหตุให้หน่อย
หรือ
สรุปว่าควรทำอะไร
ทันที
เพราะ AI อาจข้ามขั้นตอน Diagnosis และสร้างคำตอบที่ดูสมเหตุสมผลแต่ยังไม่มี Evidence รองรับ
วิธีที่ดีกว่าคือใช้ลำดับ
Data → Facts → Patterns → Missing Information → Hypotheses → Evidence → Conclusion → Action
Prompt ที่ควรเซฟไว้คือ
วิเคราะห์ข้อมูลที่ฉันให้ก่อน อย่าเพิ่งสรุปคำตอบ เริ่มจากสรุป Facts ที่ข้อมูลยืนยัน จากนั้นหา Trends, Patterns และ Anomalies แยก Observation ออกจาก Interpretation ระบุ Missing Information สร้าง Hypotheses ที่เป็นไปได้ และบอก Evidence ที่ต้องใช้สนับสนุนหรือหักล้างแต่ละข้อ ห้ามสรุป Root Cause หรือ Causation หากข้อมูลยังไม่เพียงพอ จากนั้นค่อยสร้าง Conclusion เฉพาะสิ่งที่ Evidence รองรับ และเสนอ Next Action ที่เชื่อมกับ Findings
หัวใจสำคัญคือ ทำให้ Gemini มีสิทธิ์ตอบว่า “ยังสรุปไม่ได้” เมื่อข้อมูลไม่พอ
เพราะในงานวิเคราะห์ คำตอบที่บอกว่า “ต้องตรวจข้อมูลเพิ่ม” อาจมีคุณค่ามากกว่าคำตอบที่สรุปได้เร็วแต่ผิด
เมื่อใช้ Prompt แบบ Analysis-First อย่างเป็นระบบ Gemini จะช่วยเราได้ดีขึ้นทั้งการวิเคราะห์ข้อมูลธุรกิจ การตลาด SEO Report Troubleshooting และการตัดสินใจที่ต้องอาศัยข้อมูลหลายด้าน