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

ปัญหานี้มักเรียกว่า AI Hallucination

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

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

เราไม่สามารถเขียน Prompt ที่รับประกันได้ 100% ว่า Gemini จะไม่ Hallucinate แต่สามารถออกแบบ Prompt เพื่อลดพื้นที่ที่ AI ต้องเดา และทำให้ตรวจสอบคำตอบได้ง่ายขึ้นมาก

ตัวอย่าง Prompt ที่เสี่ยงคือ

วิเคราะห์ว่าทำไมยอดขายร้านฉันลดลง

ถ้าไม่มีข้อมูล Gemini ต้องเดาสาเหตุ

Prompt ที่ดีกว่าคือ

วิเคราะห์ยอดขายจากข้อมูลที่ฉันให้เท่านั้น แยก Fact ออกจาก Hypothesis หากข้อมูลยังไม่เพียงพอสำหรับระบุ Root Cause ให้บอกว่าต้องตรวจข้อมูลอะไรเพิ่ม ห้ามสรุปสาเหตุที่ไม่มี Evidence

ความแตกต่างสำคัญคือ Prompt หลังไม่ได้บังคับให้ AI ต้อง “มีคำตอบ” ทั้งที่ข้อมูลยังไม่เพียงพอ

บทความนี้จะอธิบาย วิธีเขียน Prompt Gemini ให้คำตอบแม่นขึ้นและลด AI Hallucination พร้อม Prompt Template ที่นำไปใช้กับงานจริงได้ทันที

AI Hallucination คืออะไร?

AI Hallucination หมายถึงสถานการณ์ที่ Generative AI สร้างข้อมูลหรือข้อสรุปที่ดูเหมือนถูกต้อง แต่จริง ๆ แล้วอาจ

ผิด
ไม่มีหลักฐาน
ไม่มีอยู่จริง
ไม่ได้มาจาก Source ที่กำหนด
เป็นการคาดเดาที่ถูกนำเสนอเหมือน Fact

ปัญหาสำคัญคือคำตอบที่ผิดไม่ได้จำเป็นต้องดูผิดอย่างเห็นได้ชัด

บางครั้งมันอาจเขียนอย่างเป็นระบบ มีรายละเอียด และใช้ศัพท์ถูกต้องจนดูน่าเชื่อถือ

ดังนั้นหลักสำคัญคือ

ความมั่นใจของภาษา ไม่ได้เท่ากับความถูกต้องของข้อมูล

Hallucination เกิดขึ้นได้กับงานแบบไหน?

เกิดได้กับงานหลายประเภท เช่น

ข้อมูลทั่วไป

วันที่ ชื่อ บุคคล สถานที่ เหตุการณ์

Research

แหล่งอ้างอิง งานวิจัย หรือ Citation

Programming

ชื่อ Function, API หรือ Parameter ที่ไม่มีจริง

Business

Market Size, Forecast หรือสาเหตุของยอดขาย

Finance

ตัวเลข Calculation หรือ Assumption

Content Writing

Statistics, Quotes หรือ Claims

Technical Troubleshooting

สรุป Root Cause ทั้งที่ยังไม่มี Log หรือ Evidence

จึงควรออกแบบ Prompt ให้เหมาะกับระดับความเสี่ยงของงาน

① บอก Gemini ให้ใช้เฉพาะข้อมูลที่ให้

หนึ่งในวิธีลด Hallucination ที่สำคัญที่สุดคือ จำกัด Source

ตัวอย่าง

ใช้เฉพาะข้อมูลใน <SOURCE> เพื่อตอบคำถาม ห้ามเพิ่มข้อเท็จจริงจากภายนอก

แล้วใส่ข้อมูล

<SOURCE>
[ข้อมูล]
</SOURCE>

Prompt ตัวอย่าง

ใช้เฉพาะข้อมูลใน <SOURCE> ด้านล่าง

หากคำถามใดไม่สามารถตอบได้จาก Source ให้เขียนว่า “ข้อมูลที่ให้มายังไม่เพียงพอ”

ห้ามเติมข้อมูลจากการคาดเดา

<SOURCE>
[ข้อมูล]
</SOURCE>

เหมาะกับ

สรุปเอกสาร
วิเคราะห์รายงาน
สร้าง FAQ จากข้อมูลบริษัท
สรุป Meeting Notes
วิเคราะห์ข้อมูลภายใน

② บอกอย่างชัดเจนว่า “ห้ามเดา”

คำว่า

ตอบให้ครบ

อาจทำให้ AI พยายามเติมส่วนที่ข้อมูลไม่มี

ควรเปลี่ยนเป็น

หากข้อมูลไม่พอ อย่าเดา

แต่ให้ดีขึ้นอีกควรระบุ Behavior ที่ต้องทำแทน

ตัวอย่าง

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

Gemini จะมีทางเลือกอื่นนอกจากการแต่งคำตอบเติมช่องว่าง

③ ให้ Gemini ระบุ Missing Information

บางครั้งสิ่งที่ช่วยลด Hallucination ไม่ใช่ข้อมูลเพิ่มใน Prompt แต่คือการให้ AI บอกว่าอะไรยังขาด

Prompt:

ก่อนสรุปคำตอบ ให้ตรวจว่ามีข้อมูลสำคัญอะไรยังขาด หาก Missing Information สามารถเปลี่ยน Conclusion ได้ ให้ระบุไว้ก่อน

ตัวอย่าง

ฉันต้องการรู้ว่าทำไม Conversion ลดลง

Data:
[ข้อมูล]

ก่อนวิเคราะห์ ให้ระบุข้อมูลที่ยังขาด เช่น Traffic Source, Device, Landing Page, Period Comparison หรือ Technical Errors

ช่วยป้องกันการกระโดดไปสู่ข้อสรุปเร็วเกินไป

④ แยก Fact ออกจาก Assumption

Prompt ที่มีประโยชน์มากคือ

แยก Fact กับ Assumption

ตัวอย่าง

จากข้อมูลนี้ ช่วยตอบเป็น 4 ส่วน:

Facts

Assumptions

Analysis

Missing Information

ทำไมจึงช่วย?

เพราะบางคำตอบของ AIมีทั้งข้อมูลจริงและการตีความปนกัน

หากไม่แยก เราอาจอ่าน Assumption เหมือนเป็น Fact

⑤ แยก Fact ออกจาก Hypothesis

ในงาน Troubleshooting หรือ Business Analysis ควรแยก

Fact

สิ่งที่ข้อมูลยืนยัน

Hypothesis

สาเหตุที่เป็นไปได้แต่ยังต้องพิสูจน์

ตัวอย่าง Prompt

ยอดขายลดลง 20% จากเดือนก่อน

ช่วยสร้าง Hypotheses ที่เป็นไปได้ แต่ห้ามเรียก Hypothesis ใดว่า Root Cause จนกว่าจะมี Evidence สนับสนุน

นี่เป็นวิธีวิเคราะห์ที่ปลอดภัยกว่า

บอกสาเหตุที่ยอดขายลด

เพราะคำสั่งหลังบังคับให้ Gemini ต้องสรุปสาเหตุ

⑥ บังคับให้ระบุ Evidence Needed

หลังจากสร้าง Hypothesis ให้สั่งต่อว่า

สำหรับแต่ละ Hypothesis ระบุ Evidence ที่ต้องใช้เพื่อยืนยันหรือหักล้าง

ตัวอย่าง

Hypothesis	Evidence Needed
Traffic ลด	Analytics Traffic
Conversion ลด	Conversion Rate
ลูกค้าซื้อซ้ำน้อยลง	Repeat Purchase Data
Website Error	Error Logs

ทำให้คำตอบเปลี่ยนจาก “การคาดเดา” เป็น “รายการสิ่งที่ควรตรวจ”

⑦ ขอ Confidence แบบเชิงคุณภาพ

สามารถให้ Gemini แยกข้อมูลเป็น

High confidence
Medium confidence
Low confidence

แต่ไม่ควรมองค่าความมั่นใจของ AIเป็นความน่าจะเป็นที่ได้รับการรับรอง

Prompt:

ระบุว่าข้อสรุปใดมี Evidence จาก Input ชัด ข้อใดเป็น Interpretation และข้อใดยังมีความไม่แน่นอนสูง

วิธีนี้ดีกว่าขอ

ให้คะแนนความถูกต้อง 99%

เพราะคะแนนดังกล่าวอาจไม่มีหลักฐานรองรับ

⑧ บอก Gemini ให้พูดว่า “ไม่รู้” ได้

Prompt ที่พยายามบังคับ AI ให้ตอบทุกอย่างเพิ่มความเสี่ยง

เพิ่ม Rule เช่น

หากไม่สามารถยืนยันคำตอบได้จากข้อมูลที่มี ให้ตอบตรง ๆ ว่าไม่สามารถยืนยันได้

หรือ

คำตอบว่า “ข้อมูลไม่เพียงพอ” ถือเป็นคำตอบที่ยอมรับได้

นี่สำคัญมาก

เพราะเราไม่ควรออกแบบ Prompt ที่ให้รางวัลกับการ “ตอบครบ” มากกว่าการ “ตอบถูก”

⑨ ห้ามสร้างตัวเลข

ตัวเลขดูน่าเชื่อถือมาก แต่ AI สามารถสร้างขึ้นได้

Prompt:

ห้ามสร้าง Percentage, Revenue, Market Size, Growth Rate หรือจำนวนใด ๆ ที่ไม่ได้อยู่ใน Input

เหมาะกับ

Business Report
Marketing
Finance
SEO
Research

ตัวอย่าง

แทน

เพิ่มสถิติให้บทความน่าเชื่อถือ

ใช้

หากไม่มีสถิติใน Source ห้ามสร้างตัวเลข ให้เขียนอธิบายโดยไม่ใช้ตัวเลขแทน

⑩ ห้ามสร้าง Quote

อย่าให้ Gemini แต่งคำพูดของบุคคล ลูกค้า หรือผู้เชี่ยวชาญแล้วนำเสนอเหมือน Quote จริง

Prompt:

ห้ามสร้าง Direct Quote หากไม่มี Quote อยู่ใน Source หากต้องสรุปความเห็นให้ Paraphrase โดยไม่ใส่เครื่องหมายคำพูด

สำคัญกับ

Case Study
Customer Story
ข่าว
บทความ
Research

⑪ ห้ามสร้าง Citation หรือ Source

อีกจุดที่ต้องระวังคือ Citation

Prompt:

ห้ามสร้างชื่อบทความ งานวิจัย URL ผู้แต่ง DOI หรือ Citation หากไม่มีข้อมูลที่ตรวจสอบได้

ถ้าต้องการ Source จริง ควรตรวจ Source นั้นจริงก่อนนำไปใช้

Prompt ที่ปลอดภัยกว่า

ระบุว่า Claim ใดต้องมี Source และเสนอประเภท Source ที่ควรค้นหา เช่น Government, Official Documentation หรือ Peer-reviewed Research โดยไม่สร้าง Citation ขึ้นเอง

⑫ อย่าขอให้ Gemini “ทำข้อมูลให้ดูน่าเชื่อถือ”

Prompt เช่น

เพิ่มสถิติและแหล่งอ้างอิงให้ดูน่าเชื่อถือ

มีความเสี่ยงสูง

เพราะ AI อาจพยายามเติมข้อมูลที่ไม่มี

ควรใช้

เพิ่มเฉพาะ Evidence ที่มีอยู่ใน Source หากไม่มี Evidence ให้ระบุว่าต้องหา Source เพิ่ม

⑬ ให้ Geminiรักษาตัวเลขเดิม

ถ้า Rewrite เอกสารที่มีตัวเลข

ใช้

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

เหมาะกับ

รายงาน
Proposal
Business Document
Technical Documentation

⑭ ให้ Gemini แสดง Calculation

ถ้ามีการคำนวณ

Prompt:

แสดง Formula และค่าที่ใช้คำนวณก่อนให้ผลลัพธ์ เพื่อให้สามารถตรวจสอบได้

ตัวอย่าง

Revenue = 1,000,000
Cost = 700,000

Profit = Revenue – Cost

ทำให้ตรวจ Error ได้ง่ายกว่าเห็นเพียงคำตอบสุดท้าย

⑮ ระบุหน่วยให้ชัด

AI อาจสับสนหน่วยได้

Prompt:

รักษาหน่วยของข้อมูลทุกตัว และห้ามแปลงหน่วยโดยไม่ระบุขั้นตอน

ตัวอย่าง

บาท
ดอลลาร์
kg
g
MB
GB
ms
seconds

โดยเฉพาะงาน Calculation

⑯ กำหนดช่วงข้อมูล

ตัวอย่าง

ใช้เฉพาะข้อมูลเดือนมกราคม–มิถุนายน 2026

ถ้าไม่ระบุ Gemini อาจรวมข้อมูลช่วงอื่นหรือสมมติแนวโน้ม

Prompt:

อย่านำข้อมูลนอกช่วง [ช่วงเวลา] มาใช้เปรียบเทียบ

⑰ ระบุ Version

สำคัญมากกับ Software

แทน

วิธีทำใน WordPress

ใช้

ใช้ข้อมูลที่ตรงกับ [Version] หากขั้นตอนอาจต่างกันตาม Version ให้ระบุว่าต้องตรวจ Version ก่อน

สำหรับ Coding

Framework: [Version]

ลดความเสี่ยงที่ Gemini แนะนำ API คนละรุ่น

⑱ ให้ Gemini หลีกเลี่ยง API ที่ไม่ยืนยัน

Prompt สำหรับโปรแกรมเมอร์

ใช้เฉพาะ Function, Method หรือ API ที่อยู่ใน Code หรือ Documentation ที่ฉันให้ หากต้องใช้ API อื่นให้ระบุว่าต้องตรวจ Documentation ก่อน ห้ามสร้างชื่อ Method ขึ้นเอง

ช่วยลด “API Hallucination”

⑲ ให้ Gemini ตรวจ Input ก่อนวิเคราะห์

Prompt:

ก่อนวิเคราะห์ ให้สรุปข้อมูลที่ได้รับและตรวจว่ามี Field ใดผิดรูปแบบ ขาด หรือขัดกันหรือไม่

เหมาะกับ Data Analysis

ตัวอย่าง

ถ้า Data มี

Revenue 100,000
Profit 150,000

อาจมีปัญหาที่ต้องตรวจก่อน

⑳ ให้ Gemini ตรวจความขัดแย้งใน Source

ถ้ามีหลาย Source

ใช้

หาก Source A และ Source B ให้ข้อมูลต่างกัน ห้ามเลือกด้านใดด้านหนึ่งโดยไม่อธิบาย ให้ระบุ Conflict และข้อมูลที่ต้องตรวจเพิ่มเติม

สำคัญมากกับ Research

㉑ ให้ Gemini แยก “Source says” กับ “AI interpretation”

Prompt:

ทุก Conclusion ให้ระบุว่าเป็น:

Directly supported by Source

Reasonable interpretation

Speculative hypothesis

ทำให้ระดับหลักฐานชัดขึ้น

㉒ สั่งให้ยกข้อความสนับสนุนเฉพาะเมื่อมี

หาก Source อยู่ใน Prompt

สามารถสั่ง

สำหรับ Finding สำคัญ ระบุส่วนของ Source ที่สนับสนุน Finding นั้นโดยไม่แต่งข้อความใหม่เป็น Quote

ช่วยตรวจว่าคำสรุปเชื่อมกับ Source จริงหรือไม่

㉓ ให้ Gemini หา Unsupported Claims ในคำตอบตัวเอง

Prompt:

หลังสร้าง Draft ให้ตรวจทุก Claim และระบุ Claim ที่ไม่มี Evidence จาก Input ก่อนสร้าง Final Version

เหมาะมากกับ Content และ Report

㉔ สั่งให้ลบ Unsupported Claims

ต่อจากข้อก่อน

หาก Claim ใดไม่มี Evidence และไม่จำเป็นต่อ Goal ให้ลบออกจาก Final Version

ถ้าจำเป็น

ให้เปลี่ยนจาก Fact เป็น Hypothesis และ Label ให้ชัด

㉕ ใช้ Source-First Prompting

แทนที่จะเริ่ม

ตอบคำถามนี้

ให้เริ่ม

อ่าน Source ก่อนและสร้างรายการ Facts ที่ Source รองรับ จากนั้นใช้ Facts เหล่านั้นตอบคำถาม

Workflow:

Source → Facts → Analysis → Answer

มีความโปร่งใสมากกว่า

㉖ ใช้ Evidence-First Analysis

Prompt:

อย่าสร้าง Conclusion ก่อน ตรวจ Evidence ก่อน แล้วสร้าง Conclusion เฉพาะเท่าที่ Evidence สนับสนุน

เหมาะกับการวิเคราะห์ที่มีความเสี่ยงสูง

㉗ อย่าบังคับให้มีจำนวนคำตอบครบตามจำนวน

Prompt เช่น

หาสาเหตุ 20 ข้อ

อาจเพิ่มความเสี่ยงเมื่อสาเหตุจริงมีไม่ถึง 20 ข้อ

ดีกว่า

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

หรือ

สูงสุด 20 ข้อ

คำว่า “สูงสุด” ช่วยลดแรงกดดันให้ AI ต้องสร้างของเพิ่ม

㉘ ระวัง Prompt ที่บังคับว่า “ต้องตอบ”

ตัวอย่าง

ห้ามบอกว่าไม่รู้ ต้องตอบให้ได้

ควรหลีกเลี่ยง

เพราะตรงข้ามกับเป้าหมายลด Hallucination

ใช้แทน

หากข้อมูลไม่พอ ให้ระบุข้อจำกัดของคำตอบ

㉙ ขอหลาย Hypothesis แทนข้อสรุปเดียว

ถ้าข้อมูลยังไม่ครบ

แทน

บอกสาเหตุ

ใช้

เสนอ 3–5 Hypotheses ที่เป็นไปได้และบอกวิธีตรวจแต่ละข้อ

นี่เหมาะกับ Troubleshooting มาก

㉚ ใช้ Diagnostic Tree

Prompt:

สร้าง Diagnostic Tree จากอาการ [ปัญหา] เริ่มจากสิ่งที่ตรวจง่ายและมีโอกาสแยกสาเหตุได้มากที่สุด โดยห้ามสรุป Root Cause ก่อนตรวจ

ช่วยให้ Gemini ทำหน้าที่เป็นผู้ช่วย Diagnosis แทนการเดา

㉛ ใช้ “Known / Unknown”

Prompt:

ก่อนตอบ ให้แบ่งข้อมูลเป็น:

Known
สิ่งที่รู้จาก Input

Unknown
สิ่งที่ยังไม่รู้

Can Infer
สิ่งที่อนุมานได้อย่างมีเหตุผล

Cannot Infer
สิ่งที่ยังสรุปไม่ได้

นี่เป็น Framework ที่ดีมากกับงานวิเคราะห์

㉜ ใช้ “Answer / Evidence / Limitation”

Prompt:

ตอบทุกประเด็นในรูปแบบ:

Answer:
[คำตอบ]

Evidence:
[ข้อมูลที่สนับสนุน]

Limitation:
[สิ่งที่ยังไม่รู้]

ทำให้คำตอบอ่านง่ายและตรวจสอบได้

㉝ ให้ Gemini ระบุความไม่แน่นอน

แทนที่ AI จะเขียนว่า

สาเหตุคือ…

Prompt สามารถกำหนด

หากยังไม่มีหลักฐานเพียงพอ ให้ใช้ภาษาว่า “เป็นไปได้ว่า”, “อาจ”, หรือ “ยังต้องตรวจสอบ” แทนการนำเสนอเป็นข้อเท็จจริง

แต่ไม่ควรใช้คำไม่แน่นอนพร่ำเพรื่อกับ Fact ที่ยืนยันได้

㉞ ป้องกันการเปลี่ยน Hypothesis เป็น Fact

Prompt:

หากข้อมูลเริ่มต้นระบุว่าเป็น Hypothesis ให้รักษาสถานะเป็น Hypothesis จนกว่าจะมี Evidence ใหม่ ห้าม Rewrite ให้กลายเป็น Fact

มีประโยชน์เมื่อสรุปเอกสารหลายรอบ

㉟ ระบุว่า Example ต้องเป็น Example

AI อาจสร้างตัวอย่างแล้วคนอ่านตีความเป็นเหตุการณ์จริง

ใช้

หากสร้างตัวอย่างสมมติ ให้ Label ว่า “ตัวอย่างสมมติ” ทุกครั้ง

เหมาะกับ

Business
Finance
Marketing
Case Study

㊱ ระบุว่า Estimate คือ Estimate

Prompt:

หากจำเป็นต้องประมาณค่า ให้ Label ว่า “Estimate” พร้อม Assumptions ที่ใช้ และอย่านำ Estimate ไปเขียนเหมือนข้อมูลจริง

สำคัญกับ Forecast

㊲ อย่าให้ Gemini สร้างข้อมูลให้ “ครบตาราง”

ถ้าบาง Cell ไม่มีข้อมูล

Prompt:

หากข้อมูลใน Cell ใดไม่มี ให้ใส่ “N/A” หรือ “ไม่ได้ระบุ” ห้ามสร้างค่าขึ้นมาเพื่อให้ตารางครบ

นี่เป็น Constraint ที่ใช้ได้ดีมาก

㊳ ใช้ Null แทนการเดาใน Structured Output

หากเป็น JSON

ตัวอย่าง

หาก Field ไม่มีข้อมูล ให้ใช้ null ห้ามสร้างค่า

เช่น

{
  "deadline": null,
  "owner": null
}

ดีกว่าให้ AI สร้าง Owner หรือ Deadline เอง

㊴ กำหนด Schema เพื่อป้องกันข้อมูลแทรก

ตัวอย่าง

ตอบเฉพาะ Fields:

Task

Owner

Deadline

Status

ห้ามเพิ่ม Field อื่น

ช่วยลดการขยาย Output นอก Scope

㊵ ใช้ Closed-Book Prompt เมื่อมี Source ครบ

ถ้าต้องการให้ Gemini ใช้เอกสารเท่านั้น

Prompt:

ทำงานแบบ Closed-Book: ใช้เฉพาะข้อมูลใน Source นี้ ไม่ใช้ความรู้ภายนอก แม้ว่าจะรู้ข้อมูลเพิ่มเติมก็ตาม

เหมาะกับเอกสารภายใน

㊶ ใช้ Open-Book อย่างระมัดระวัง

ถ้าต้องการให้ใช้ความรู้ทั่วไปด้วย

ให้แยก

ใช้ Source เป็นข้อมูลหลัก หากเพิ่มข้อมูลทั่วไปให้แยก Section ชัดเจนว่า “ข้อมูลเพิ่มเติมที่ไม่ได้อยู่ใน Source”

ช่วยไม่ให้ข้อมูลสองส่วนปนกัน

㊷ ให้ Gemini ถามกลับเมื่อข้อมูลสำคัญขาด

Prompt:

หากข้อมูลที่ขาดสามารถเปลี่ยนคำตอบอย่างมีนัยสำคัญ ให้ถามฉันก่อนสูงสุด 3 คำถาม

เหมาะกับ

Business
Technical
Planning
Recommendations

แต่ไม่จำเป็นกับงานที่ตอบจาก Source ได้อยู่แล้ว

㊸ ให้ Gemini ทำ Best Effort โดยไม่เดา

ถ้าไม่ต้องการให้หยุดถาม

ใช้

หากข้อมูลไม่ครบ ให้ทำ Best Effort จากข้อมูลที่มี โดยแยกสิ่งที่ตอบได้ สิ่งที่ยังตอบไม่ได้ และข้อมูลที่ต้องเพิ่ม ห้ามเติมข้อมูลเอง

ช่วยให้ Workflow เดินต่อได้

㊹ ให้ Gemini ตรวจคำตอบกับ Prompt เดิม

Prompt:

ก่อน Final ให้เปรียบเทียบคำตอบกับ Requirement เดิมทีละข้อ และแก้ข้อที่ไม่ตรงก่อนส่ง

ช่วยลดความผิดพลาดจากการหลุดคำสั่ง

㊺ ให้ Gemini ตรวจ Logical Consistency

Prompt:

ตรวจว่าคำตอบไม่มีข้อสรุปที่ขัดกับ Fact หรือคำตอบส่วนอื่น หากพบ Conflict ให้แก้หรือระบุความไม่แน่นอน

เหมาะกับรายงานยาว

㊻ ให้ Gemini ตรวจตัวเลขระหว่าง Section

Prompt:

ตรวจว่าตัวเลขเดียวกันถูกใช้สอดคล้องกันทุก Section และไม่มีการเปลี่ยนหน่วยหรือค่าระหว่างการ Rewrite

ช่วยลด Numeric Drift

㊼ ให้ Gemini ตรวจชื่อและคำศัพท์

Prompt:

รักษาชื่อบุคคล บริษัท Product และ Technical Terms ตาม Source ทุกจุด ห้ามเปลี่ยน Spelling หรือขยายชื่อเอง

เหมาะกับ Technical Document

㊽ ให้ Gemini ทำ Final Hallucination Check

Prompt:

ก่อนส่ง Final Answer ให้ตรวจทุกประโยคว่าเป็น:

Supported Fact

Explicit Assumption

Recommendation

Unknown

หากพบข้อความที่ไม่อยู่ใน 4 กลุ่มนี้ ให้แก้ก่อนส่ง

เป็น Quality Gate ที่มีประโยชน์มาก

㊾ ให้ Gemini ลบ “ความมั่นใจปลอม”

Prompt:

หากข้อสรุปไม่มีหลักฐานเพียงพอ ห้ามเขียนด้วยภาษาที่ทำให้ดูยืนยันแน่นอน ให้ระบุระดับข้อจำกัดอย่างเหมาะสม

ช่วยให้ Tone สอดคล้องกับ Evidence

㊿ ใช้ Master Prompt ลด Hallucination

Prompt พร้อมใช้:

<TASK>
[งาน]
</TASK>

<SOURCE>
[ข้อมูล]
</SOURCE>

กฎสำคัญ:

ใช้เฉพาะข้อมูลที่สามารถยืนยันได้จาก SOURCE เว้นแต่ฉันอนุญาตให้ใช้ข้อมูลภายนอก

ห้ามสร้าง Fact, Number, Quote, Citation, Name หรือ Source ขึ้นเอง

หากข้อมูลไม่พอ ให้ระบุว่า “ข้อมูลไม่เพียงพอ”

แยก Fact, Assumption และ Recommendation

หากมี Hypothesis ให้ Label ว่าเป็น Hypothesis

ระบุ Missing Information ที่มีผลต่อ Conclusion

ห้ามเปลี่ยนตัวเลข วันที่ ชื่อ หรือหน่วยจาก Source

หากมี Conflict ใน Source ให้ระบุ Conflict

ก่อน Final ตรวจ Unsupported Claims

ลบหรือแก้ Claim ที่ไม่มี Evidence

<OUTPUT>
[รูปแบบคำตอบ]
</OUTPUT>

Template นี้สามารถนำไปดัดแปลงกับงานหลายประเภท

Prompt ลด Hallucination สำหรับการสรุปเอกสาร

สรุปเอกสารนี้โดยใช้เฉพาะข้อมูลใน <SOURCE>

ห้าม:

เพิ่ม Fact

เติมรายละเอียด

สร้าง Conclusion ที่ Source ไม่ได้สนับสนุน

หากข้อมูลใดไม่ได้ระบุ ให้เขียนว่า “ไม่ได้ระบุ”

<SOURCE>
[เอกสาร]
</SOURCE>

Prompt ลด Hallucination สำหรับบทความ

เขียนบทความจาก Source ที่ให้ โดย:

Fact ทุกข้อที่เฉพาะเจาะจงต้องมาจาก Source

ห้ามสร้าง Statistics

ห้ามสร้าง Quote

ห้ามสร้าง Feature

หากข้อมูลไม่พอให้ตัด Claim นั้นออก

สามารถอธิบายหรือจัดโครงสร้างใหม่ได้ แต่ห้ามเปลี่ยนความหมาย

Prompt ลด Hallucination สำหรับ Research

ตอบ Research Question [คำถาม] จาก Sources ที่ให้

แบ่งคำตอบเป็น:

Findings

Supporting Evidence

Conflicting Evidence

Limitations

Unknowns

ห้ามสร้าง Citation หรือ Reference ที่ไม่มีอยู่ใน Source

Prompt ลด Hallucination สำหรับ Business

วิเคราะห์ Business Problem [ปัญหา] จากข้อมูล [DATA]

แยก:

Facts

Hypotheses

Missing Data

Experiments

Recommendation

ห้ามเรียก Hypothesis ว่า Root Cause จนกว่าจะมี Evidence

Prompt ลด Hallucination สำหรับการตลาด

วิเคราะห์ Marketing Performance จากข้อมูล [DATA]

ห้ามสร้าง:

Market Size

Search Volume

Customer Behavior

Competitor Data

Conversion Rate

หากไม่ได้อยู่ใน Input

ทุก Recommendation ต้องระบุว่ามาจาก Fact หรือ Hypothesis

Prompt ลด Hallucination สำหรับ Coding

Environment:
[LANGUAGE / FRAMEWORK / VERSION]

Code:
[CODE]

Error:
[ERROR]

ใช้เฉพาะ API ที่ยืนยันได้จาก Code หรือ Documentation ที่ให้ หากไม่แน่ใจว่า API มีจริง ให้ระบุว่าต้องตรวจ Documentation ห้ามสร้าง Method หรือ Parameter ขึ้นเอง

Prompt ลด Hallucination สำหรับ Troubleshooting

อาการคือ [SYMPTOM]

ข้อมูลที่มี [DATA]

อย่าระบุ Root Cause ทันที

ให้:

สร้าง Possible Causes

ระบุ Evidence Needed

เรียง Diagnostic Steps

ตัดสาเหตุออกตามผลตรวจ

หากข้อมูลยังไม่พอ ให้หยุดที่ Hypothesis

Prompt ลด Hallucination สำหรับ Meeting Notes

จาก Meeting Notes นี้ ดึงเฉพาะ:

Decisions

Actions

Owners

Deadlines

หาก Owner หรือ Deadline ไม่ได้ระบุ ให้เขียน “ไม่ได้ระบุ” ห้ามเดาจากบริบท

นี่ช่วยป้องกัน AI สร้างผู้รับผิดชอบหรือนัดหมายขึ้นเอง

Prompt ลด Hallucination สำหรับ Rewrite

Rewrite ข้อความนี้โดยเปลี่ยนเฉพาะ Style และ Sentence Structure

ต้องรักษา:

Meaning

Fact

Number

Date

Name

Unit

Conclusion

ห้ามเพิ่มข้อมูลใหม่

Prompt ลด Hallucination สำหรับ Translation

แปลข้อความนี้โดยรักษาชื่อเฉพาะ ตัวเลข วันที่ Technical Terms และโครงสร้างความหมายเดิม หากคำใดกำกวมให้รักษาความกำกวมไว้หรือระบุ Alternative Translation แทนการเดาความหมาย

Prompt ลด Hallucination สำหรับ Data Extraction

ดึงข้อมูลจาก Source ลงในตาราง [Schema]

ถ้า Field ใดไม่มีข้อมูล ให้ใส่ N/A

ห้ามอนุมานค่าเพื่อให้ Field ครบ

ใช้ได้กับการแปลงเอกสารเป็น Structured Data

Prompt ลด Hallucination สำหรับการเปรียบเทียบ

เปรียบเทียบ A และ B โดยใช้เฉพาะข้อมูลที่ให้ หาก Criterion ใดไม่มีข้อมูลของตัวเลือกหนึ่ง ให้ระบุ “ไม่มีข้อมูล” แทนการเดาค่า

Prompt ลด Hallucination สำหรับ Decision Making

ก่อน Recommendation ให้แสดง:

Facts → Assumptions → Missing Information → Options → Trade-offs

หาก Missing Information มีผลต่อ Recommendation อย่างมาก ให้ระบุว่าคำแนะนำเป็น Provisional Recommendation

Prompt ลด Hallucination สำหรับ Forecast

Forecast มี Assumption อยู่แล้ว

Prompt:

สร้าง Scenario Forecast จากตัวเลขที่ให้เท่านั้น หากต้องสมมติค่า ให้แสดง Assumption ชัดและอย่านำ Forecast ไปเขียนเป็น Fact

Prompt ลด Hallucination สำหรับ Case Study

ใช้เฉพาะข้อมูล Case จริงที่ให้ ห้ามสร้าง Revenue, Percentage, Customer Quote หรือ Result ใหม่ หากข้อมูลไม่ครบให้ตัด Section หรือระบุว่าไม่ได้ให้ข้อมูล

เทคนิค Grounded Prompting

แนวคิดคือให้คำตอบ “ยึด” กับข้อมูลที่กำหนด

โครงสร้างง่าย ๆ:

Context
Source
Question
Rules
Output

ตัวอย่าง

<SOURCE>
[ข้อมูล]
</SOURCE>

<QUESTION>
[คำถาม]
</QUESTION>

ใช้เฉพาะ Source ในการตอบ หาก Source ไม่เพียงพอให้ระบุข้อจำกัด

นี่เป็นหนึ่งในวิธีพื้นฐานที่มีประโยชน์มากที่สุดในการลด Hallucination

เทคนิค Quote → Interpret → Conclude

สำหรับ Source สำคัญ

ใช้ Workflow

Step 1

ระบุข้อความหรือข้อมูลที่เกี่ยวข้อง

Step 2

ตีความ

Step 3

สร้าง Conclusion

Prompt:

ก่อนสร้าง Conclusion ให้ระบุ Evidence จาก Source ที่สนับสนุน Conclusion นั้นก่อน

ทำให้เห็นเส้นทางจาก Evidence ไปสู่คำตอบ

เทคนิค Claim → Evidence Mapping

Prompt:

สร้างตาราง:

| Claim | Evidence | Source Section | Confidence |

หาก Claim ไม่มี Evidence ให้ทำเครื่องหมาย Unsupported

เหมาะกับการตรวจบทความและรายงาน

เทคนิค Fact Table ก่อนเขียน

Prompt:

ก่อนเขียนบทความ ให้สร้าง Fact Table จาก Source โดยยังไม่เขียนบทความ จากนั้นใช้เฉพาะ Facts ใน Table เป็นฐานของเนื้อหา

ช่วยแยก Research กับ Writing ออกจากกัน

เทคนิค Unknown List

Prompt:

ก่อนตอบ ให้สร้างรายการ Unknowns ที่ไม่สามารถยืนยันจากข้อมูลปัจจุบัน และอย่าพยายามตอบ Unknown เหล่านั้น

นี่ช่วยให้เห็นขอบเขตความรู้ของคำตอบ

เทคนิค Contradiction Check

Prompt:

ตรวจ Source และ Draft ว่ามีข้อมูลใดขัดกัน ถ้ามีให้แสดงทั้งสองด้านและอย่าสรุปโดยเลือกด้านเดียวโดยไม่มีเหตุผล

มีประโยชน์กับข้อมูลหลาย Source

เทคนิค Counterexample Check

Prompt:

หลังสร้าง Conclusion ให้ลองหากรณีที่ Conclusion อาจไม่จริงจากข้อมูลที่มี หากมีให้เพิ่ม Limitation

เหมาะกับการวิเคราะห์

เทคนิค “What would change the answer?”

Prompt:

ระบุข้อมูล 3 อย่างที่ถ้าเปลี่ยนหรือได้รับเพิ่มเติม อาจทำให้ Recommendation เปลี่ยน

ช่วยระบุ Sensitivity ของคำตอบ

เทคนิค “What do we actually know?”

Prompt:

ตัด Recommendation และความคิดเห็นออกชั่วคราว แล้วแสดงเฉพาะข้อเท็จจริงที่ Input ยืนยันได้

ใช้เมื่อ Conversation เริ่มมี Assumption เยอะ

Self-Check ไม่ได้ทำให้คำตอบถูก 100%

การสั่งว่า

ตรวจตัวเองอีกครั้ง

ช่วยได้ในบางสถานการณ์ แต่ไม่ควรถูกมองว่าเป็นการ Verification จากแหล่งอิสระ

AI อาจตรวจคำตอบผิดด้วยเหตุผลเดิมซ้ำ

ดังนั้นข้อมูลสำคัญยังควร

ตรวจ Source
ตรวจ Documentation
ตรวจ Calculation
ทดลอง Code
ใช้ข้อมูลจริง

ทำไม Prompt ยาวไม่ได้ป้องกัน Hallucination?

เพราะ Hallucination ไม่ได้เกิดจาก Prompt สั้นอย่างเดียว

Prompt ยาวอาจยังมีปัญหา เช่น

ไม่มี Source
บังคับให้ตอบ
มี Context ผิด
มีข้อมูลขัดกัน
มี Example ที่ผิด
กำหนด Output มากกว่าความถูกต้อง

Prompt 2,000 คำจึงยัง Hallucinate ได้

สิ่งสำคัญคือ

Grounding + Constraints + Verification

ไม่ใช่ความยาว

ไม่ควรใส่ข้อมูลผิดเข้า Prompt

Gemini สามารถได้รับผลกระทบจาก Premise ที่เราป้อน

ตัวอย่าง

จากข้อเท็จจริงที่ว่า X เกิดในปี 2025 ช่วยอธิบาย…

ถ้า X ไม่ได้เกิดปีนั้น คำตอบทั้งหมดอาจสร้างต่อบนข้อมูลผิด

ดังนั้น Prompt ที่ดีควรแยกสิ่งที่เป็น

User-provided assumption

ออกจาก

Verified fact

Prompt ตรวจ Premise

ใช้

ก่อนตอบ ตรวจว่าคำถามของฉันมี Premise หรือ Assumption ใดที่ต้องยืนยันก่อนหรือไม่ หากพบ ให้ระบุก่อนทำงานต่อ

มีประโยชน์กับคำถามเชิงข้อมูล

อย่าสร้าง Fact จาก Example

ถ้า Few-Shot Prompt มี Example

เพิ่ม

Examples ใช้เพื่อเรียนรู้ Format เท่านั้น ห้ามนำ Fact, Names, Dates หรือ Numbers จาก Examples ไปใช้กับ New Input

ลดข้อมูลรั่วจาก Example

ระวัง Summary หลายทอด

ถ้าสรุป

เอกสาร → Summary → Summary ของ Summary → บทความ

รายละเอียดอาจค่อย ๆ เปลี่ยนหรือหาย

ควรกลับไปใช้ Original Source ในขั้นสำคัญ

Prompt:

ใช้ Original Source เป็น Ground Truth เมื่อข้อมูลใน Summary ขัดกับ Source

วิธีตรวจบทความที่ Gemini เขียนแล้ว

ใช้

อ่าน Draft นี้และสร้าง Fact-Check List โดยดึงทุก Claim ที่ตรวจสอบได้ เช่น Date, Number, Feature, Person, Organization และ Technical Statement ออกมาเป็นรายการสำหรับตรวจ Source

ไม่จำเป็นต้องเชื่อว่า AI ตรวจ Fact เองถูกทั้งหมด

แต่ช่วยสร้างรายการที่เราต้องตรวจ

ข้อมูลแบบไหนควรตรวจเองเสมอ?

ควรระมัดระวังมากเป็นพิเศษกับ

กฎหมาย
ภาษี
การเงิน
การแพทย์
ความปลอดภัย
ข่าวล่าสุด
ราคา
Version Software
Policy
Specification
Citation
ตัวเลขธุรกิจ

เพราะผลกระทบจากข้อมูลผิดสูงหรือข้อมูลเปลี่ยนเร็ว

10 คำสั่งสั้น ๆ ที่ช่วยลด Hallucination

สามารถนำไปต่อท้าย Prompt ได้

① ใช้เฉพาะข้อมูลที่ให้
② หากไม่มีข้อมูล ให้บอกว่าไม่มีข้อมูล
③ ห้ามสร้างตัวเลข
④ ห้ามสร้าง Citation
⑤ แยก Fact กับ Assumption
⑥ Label Hypothesis ให้ชัด
⑦ ระบุ Missing Information
⑧ อย่าสรุป Root Cause หากยังไม่มี Evidence
⑨ ตรวจ Unsupported Claims ก่อน Final
⑩ ถ้าไม่แน่ใจ ให้ระบุความไม่แน่นอนแทนการเดา

ไม่จำเป็นต้องใช้ทุกข้อกับทุก Prompt

เลือกตามงาน

5 คำสั่งสำคัญที่สุด

ถ้าจำเพียง 5 ข้อ ให้ใช้

1.

ใช้เฉพาะข้อมูลที่ให้

2.

หากข้อมูลไม่พอ อย่าเดา

3.

แยก Fact กับ Assumption

4.

ระบุ Missing Information

5.

ตรวจ Unsupported Claims ก่อน Final

เพียงเท่านี้ก็ช่วยเพิ่มความชัดเจนของ Prompt ได้มาก

Prompt ก่อนและหลังปรับเพื่อลด Hallucination

ตัวอย่างที่ 1 — วิเคราะห์ธุรกิจ

ก่อน

ทำไมยอดขายลดลง?

หลัง

จากข้อมูลยอดขายต่อไปนี้ [DATA] ช่วยสร้าง Hypotheses ว่ายอดขายลดเพราะอะไร แยก Fact กับ Hypothesis และระบุ Evidence ที่ต้องตรวจ ห้ามสรุป Root Cause จนกว่าจะมีข้อมูลรองรับ

ตัวอย่างที่ 2 — เขียนบทความ

ก่อน

เขียนบทความพร้อมสถิติให้ดูน่าเชื่อถือ

หลัง

เขียนบทความจาก Source ที่ให้ หากไม่มี Statistics ใน Source ห้ามสร้างตัวเลขเพิ่ม และระบุ Claim ที่ต้องหา Source เพิ่มก่อน Publish

ตัวอย่างที่ 3 — Meeting Notes

ก่อน

สรุปว่าใครต้องทำอะไรและเมื่อไร

หลัง

ดึง Task, Owner และ Deadline จาก Notes เท่านั้น หากไม่ได้ระบุ Owner หรือ Deadline ให้เขียน “ไม่ได้ระบุ” ห้ามอนุมานเอง

ตัวอย่างที่ 4 — Coding

ก่อน

แก้ Error นี้ให้หน่อย

หลัง

วิเคราะห์ Error [ERROR] จาก Code [CODE] และ Environment [VERSION] ก่อนเสนอ Fix หากไม่แน่ใจว่า API หรือ Method มีอยู่ใน Version นี้ ให้ระบุว่าต้องตรวจ Documentation ห้ามสร้าง API ขึ้นเอง

Master Prompt ลด AI Hallucination แบบพร้อมใช้

<OBJECTIVE>
[งานที่ต้องการ]
</OBJECTIVE>

<SOURCE>
[ข้อมูลที่อนุญาตให้ใช้]
</SOURCE>

<RULES>

ใช้ SOURCE เป็น Ground Truth

ห้ามสร้าง Fact, Number, Date, Name, Quote, Citation หรือ Source ที่ไม่มีข้อมูลรองรับ

หากข้อมูลไม่เพียงพอ ให้ระบุว่า “ข้อมูลไม่เพียงพอ”

แยก Fact, Assumption, Hypothesis และ Recommendation

อย่าเปลี่ยน Hypothesis ให้เป็น Fact

ระบุ Missing Information ที่สามารถเปลี่ยน Conclusion

หาก Sources ขัดกัน ให้ระบุ Conflict

รักษาตัวเลข ชื่อ วันที่ และหน่วยตาม Source

หากจำเป็นต้องประมาณ ให้ Label ว่า Estimate และแสดง Assumption

ก่อน Final ให้ตรวจ Unsupported Claims ทุกข้อ
</RULES>

<OUTPUT_FORMAT>
[รูปแบบคำตอบ]
</OUTPUT_FORMAT>

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

Checklist ก่อนใช้คำตอบ Gemini

แม้เขียน Prompt ดีแล้ว ควรตรวจต่อ

① มี Source หรือไม่
② Fact สำคัญตรงกับ Source หรือไม่
③ มีตัวเลขที่ไม่รู้มาจากไหนหรือไม่
④ มี Citation จริงหรือไม่
⑤ ชื่อและวันที่ถูกหรือไม่
⑥ Assumption ถูก Label หรือไม่
⑦ Hypothesis ถูกเขียนเหมือน Fact หรือไม่
⑧ Calculation ตรวจแล้วหรือไม่
⑨ Version หรือ Specification ยังเป็นปัจจุบันหรือไม่
⑩ Recommendation ใช้ข้อมูลครบพอหรือยัง

Checklist สำหรับ Prompt ลด Hallucination

ก่อนส่ง Prompt ตรวจว่า

① ระบุ Source หรือยัง
② บอก Gemini ว่าใช้ข้อมูลไหนได้หรือไม่
③ กำหนด Behavior เมื่อข้อมูลขาดหรือยัง
④ ห้ามสร้าง Fact หรือยัง
⑤ ห้ามสร้างตัวเลขหากจำเป็นหรือยัง
⑥ ห้ามสร้าง Citation หรือยัง
⑦ แยก Fact/Assumption หรือยัง
⑧ ต้อง Label Hypothesis หรือไม่
⑨ ระบุ Missing Information หรือไม่
⑩ มี Evidence Needed หรือไม่
⑪ ต้องรักษาตัวเลขหรือชื่อเดิมหรือไม่
⑫ ต้องระบุ Version หรือไม่
⑬ Output Schema ชัดหรือไม่
⑭ มี Self-Check หรือไม่
⑮ ต้องตรวจ Source จริงภายหลังหรือไม่

สรุป วิธีเขียน Prompt Gemini ให้คำตอบแม่นขึ้น ลด AI Hallucination

ไม่มี Prompt ใดรับประกันได้ว่า Google Gemini จะตอบถูก 100%

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

หลักที่สำคัญที่สุดคือ

Source + Constraints + Fact/Assumption + Missing Information + Verification

แทนที่จะสั่ง

ตอบให้ครบและมั่นใจ

ควรสั่ง

ถ้าไม่รู้ ให้บอกว่าไม่รู้

แทนที่จะถาม

สาเหตุคืออะไร?

ควรถาม

Hypotheses มีอะไร และต้องตรวจ Evidence อะไร?

แทนที่จะให้ Gemini สร้างข้อมูลเพื่อเติมช่องว่าง

ควรใช้

N/A, ไม่ได้ระบุ, ข้อมูลไม่เพียงพอ

Prompt พร้อมใช้ที่ควรเซฟไว้คือ

ใช้เฉพาะข้อมูลใน Source ที่ฉันให้ หากข้อมูลไม่เพียงพอสำหรับยืนยันข้อสรุป ห้ามเดาหรือสร้างข้อมูลขึ้นเอง ให้ระบุว่าอะไรยังไม่ทราบ แยก Fact, Assumption และ Hypothesis อย่างชัดเจน ห้ามสร้างตัวเลข Quote Citation หรือ Source ที่ไม่มีข้อมูลรองรับ และก่อนส่ง Final Answer ให้ตรวจทุก Claim ว่ามี Evidence หรือได้รับการ Label ว่าเป็น Assumption/Recommendation อย่างเหมาะสม

หัวใจสำคัญคือ อย่าออกแบบ Prompt ให้ Gemini ต้องมีคำตอบทุกครั้ง แต่ให้อิสระ Gemini ในการระบุว่า “ข้อมูลยังไม่พอ” เมื่อจำเป็น

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