บทเรียน Gemini 3.8 Flash API: ระดับการคิด การดึงข้อมูลจาก PDF และการเรียกใช้ฟังก์ชันใน Python

Gemini 3.8 Flash คืออะไร?

Gemini 3.8 Flash คือโมเดลหลักสำหรับงานทั่วไปของ Google เปิดให้ใช้ทั่วไปตั้งแต่วันที่ 2 กันยายน 2026 ภายใต้รหัสโมเดล gemini-3.8-flash เปิดตัวหลัง 3.7 Flash เพียง 3 สัปดาห์ และ Google วางตำแหน่งเพื่อรองรับงานโค้ดที่กินระยะยาว เวิร์กโฟลว์เชิงเอเจนต์ และการให้เหตุผลหลายขั้นในโดเมนเฉพาะเช่นการเงินและกฎหมาย

สเปกที่สำคัญต่อการเรียก API ไม่เปลี่ยนจาก 3.7: 

• หน้าต่างบริบท 1 ล้านโทเค็น
• โทเค็นขาออกสูงสุด 64k
• รับอินพุตมัลติโหมด (ข้อความ รูปภาพ วิดีโอ เสียง PDF) และส่งออกเป็นข้อความ
• ราคาเปิดตัวเท่าเดิม $0.75 ต่อโทเค็นขาเข้า 1M และ $3.75 ต่อโทเค็นขาออก 1M จนถึง 31 ธันวาคม 2026 (ปรับเป็น $1.50 และ $7.50 ตั้งแต่ 1 มกราคม 2027)

สิ่งที่เปลี่ยนคือพฤติกรรม ไม่ใช่หน้าตา: Google ระบุว่า 3.8 ทำงานหนักขึ้นกับงานที่ซับซ้อน โดยใช้ขั้นตอนให้เหตุผลเพิ่มเติมและเรียกใช้เครื่องมือแบบวนรอบ ซึ่งอาจเพิ่มการใช้โทเค็นเมื่อใช้ระดับความพยายามที่สูงขึ้น 3.7 Flash ยังรองรับเต็มที่สำหรับงานที่ให้ความสำคัญกับประสิทธิภาพมากกว่าความลึก

สำหรับเกณฑ์วัดผลและรายละเอียดราคา อ่านได้ที่ คู่มือ Gemini 3.8 Flash หรืออ่าน What is Google Gemini? เพื่อทำความรู้จักแพลตฟอร์ม

Gemini 3.8 Flash เทียบกับ 3.8 Flash Cyber

การเปิดตัวมี 2 รุ่นย่อย และมีเพียง 1 รุ่นที่มีรหัสโมเดลให้พิมพ์เรียกใช้ได้ 

• Gemini 3.8 Flash เป็นโมเดลทั่วไป ใช้ได้ใน Google AI Studio และ Gemini API วันนี้ 
• Gemini 3.8 Flash Cyber เป็นรุ่นสายไซเบอร์ซีเคียวริตี้ ปรับจูนเพื่อค้นหาช่องโหว่และแพตช์อัตโนมัติ

รุ่น Cyber ไม่เปิดให้ใช้บน API สาธารณะ: การเข้าถึงผ่านโครงการ Fairwind ของ Google ซึ่งจำกัดไว้สำหรับหน่วยงานรัฐที่ได้รับอนุมัติ ผู้ให้บริการโครงสร้างพื้นฐานสำคัญ และผู้ดูแลซอฟต์แวร์

หากกำลังทำตามบทเรียนนี้ รหัสโมเดลของคุณคือ gemini-3.8-flash ไม่มีส่วนไหนด้านล่างนี้ที่ต้องใช้หรืออ้างอิงรุ่น Cyber

Interactions API เทียบกับ generateContent

การเรียก Gemini 3.8 Flash ให้ใช้ client.interactions.create() ใน SDK google-genai Google ประกาศ Interactions API เป็น GA ในเดือนมิถุนายน 2026 และแนะนำให้ใช้สำหรับงานใหม่ทั้งหมด แม้ generateContent ยังทำงานได้ แต่ถือเป็นรุ่นเก่า ฟีเจอร์ใหม่อย่างประวัติฝั่งเซิร์ฟเวอร์ การประมวลผลเบื้องหลัง และขั้นตอนการทำงานที่สังเกตได้ จะมาลงที่ Interactions ก่อน

ความเปลี่ยนแปลงที่ใหญ่ที่สุดในการใช้งานจริงคือการจัดการสถานะ การเรียกหลายเทิร์นตอนนี้ใช้ previous_interaction_id ฝั่งเซิร์ฟเวอร์: ส่งไอดีของอินเทอร์แอ็กชันล่าสุด แล้วเซิร์ฟเวอร์จะกู้คืนสถานะให้ ไม่ต้องต่อประวัติแชตเองหรือส่งซ้ำทั้งหมดอีก หลีกเลี่ยงการพรีฟิลฝั่งโมเดลด้วย นั่นเป็นรูปแบบของ generateContent แบบเก่า และจะทำให้ Gemini 3.x พัง

ประเด็นหนึ่งที่หลายคนพลาด และจะกลับมาอีกในส่วน PDF: previous_interaction_id กู้คืนเฉพาะประวัติการสนทนาและไม่มีอย่างอื่น tools, system_instruction, generation_config และ response_format ผูกกับอินเทอร์แอ็กชัน ดังนั้นทุกเทิร์นที่ต้องใช้ต้องส่งมาด้วยอีกครั้ง

thinking_level แทนที่ปุ่มปรับ sampling

บนโมเดล Gemini รุ่นเก่า นักพัฒนาจะใช้ temperature, top_p และ top_k เพื่อควบคุมความสุ่มของเอาต์พุต Gemini 3.x ตัดปุ่มปรับเหล่านี้ออกและแทนด้วย thinking_level ซึ่งกลายเป็นตัวปรับเพียงตัวเดียว

รองรับ 3 ค่า:

• low: ใช้โทเค็นเหตุผลน้อยสุด เร็วและถูก เหมาะกับงานดึงข้อมูล จัดประเภท และงานที่ตั้งใจจะตรวจเอง

• medium: ค่าเริ่มต้น และเป็นคำแนะนำของ Google สำหรับงานโค้ดและเอเจนต์

• high: งบประมาณการให้เหตุผลสูงสุด สำหรับตรรกะหลายขั้นที่ยากและงานที่ใช้เครื่องมือหนัก

อย่าส่ง minimal ค่านี้ใช้ไม่ได้ตั้งแต่ Gemini Flash 3.7 และจะได้ 400 validation error 

กฎอีกข้อที่สืบมาจาก 3.7: frequency_penalty, presence_penalty และ candidate_count ตอนนี้จะทิ้ง error จาก API โดยตรง ดังนั้นให้ลบออกจากคอนฟิกเก่าด้วย

ตั้งค่า Gemini 3.8 Flash API อย่างไร?

การตั้งค่าสภาพแวดล้อมใช้เวลาประมาณ 2 นาที ต้องมีคีย์ API จาก Google AI Studio และไลบรารี Python google-genai เวอร์ชันอัปเดต

ขอคีย์ API จาก Google AI Studio

เข้า Google AI Studio บนบราวเซอร์และลงชื่อเข้าใช้ด้วยบัญชี Google คลิก Create API Key เลือกหรือสร้างโปรเจ็กต์ Google Cloud แล้วคัดลอกคีย์ลับของคุณ 

เปิดเทอร์มินัลแล้วบันทึกคีย์เป็นตัวแปรสภาพแวดล้อมด้วย export GEMINI_API_KEY=<your-key>

อย่าส่งคีย์เป็นพารามิเตอร์ ?key= ใน URL เด็ดขาด เพราะคิวรีสตริงจะไปอยู่ในล็อกเซิร์ฟเวอร์ ประวัติบราวเซอร์ และแคชพร็อกซี หากอยากลองเล่นโมเดลใน playground ก่อนเขียนโค้ด ให้ดู Google AI Studio Tutorial ซึ่งครอบคลุมโหมด Chat, Build และ Stream; บทความนี้โฟกัสที่ API

สำหรับระบบโปรดักชัน เรื่องยืนยันตัวตนจะต่างออกไป: Vertex AI (ตอนนี้เป็นส่วนหนึ่งของ Gemini Enterprise Agent Platform) ให้ OAuth บทบาท IAM และเอ็นด์พอยต์รายภูมิภาค แทนการใช้คีย์ API ตรง ทุกอย่างในบทเรียนนี้ใช้คีย์ AI Studio เพราะเร็วที่สุดสำหรับการเรียนรู้ แต่ควรวางแผนย้ายไป Vertex ก่อนจะมีข้อมูลผู้ใช้จริงเข้ามาเกี่ยวข้อง

ติดตั้ง google-genai และสร้างไคลเอนต์

บทเรียนจำนวนมากยังแนะนำให้ติดตั้ง google-generativeai ซึ่งเป็น SDK รุ่นเก่าและไม่มี Interactions API ให้ติดตั้ง google-genai (เวอร์ชัน 2.3.0 ขึ้นไป):

pip install -U google-genai

เมื่อติดตั้งแล้ว ให้ตรวจสอบว่า Python โหลดไลบรารีและเริ่มต้นไคลเอนต์ได้โดยไม่มีข้อผิดพลาด:

from google import genai # reads GEMINI_API_KEY from the environment
client = genai.Client() 
print("Client initialized successfully.")

เรียก Interactions API ครั้งแรก

ทุกคำขอไปยัง Interactions API จะสร้างทรัพยากร Interaction ซึ่งบันทึกเทิร์นเต็มรูปแบบ: อินพุตของคุณ กระบวนคิดของโมเดล การเรียกใช้เครื่องมือ และผลลัพธ์สุดท้าย SDK เปิดเผยข้อความสุดท้ายผ่านพร็อพเพอร์ตีสะดวกใช้อย่าง output_text จึงแทบไม่ต้องไล่ดูทีละสเต็ปเอง

from google import genai
client = genai.Client()
interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input=(
        "Write a pandas one-liner that adds a 7-day rolling average "
        "revenue column per store_id to a DataFrame with columns "
        "date, store_id, revenue. Reply with only the code, no explanation."
    ),
    generation_config={"thinking_level": "medium"},
)
print(interaction.output_text)
usage = interaction.usage
print(
    f"input={usage.total_input_tokens} | output={usage.total_output_tokens} | "
    f"thinking={usage.total_thought_tokens} | total={usage.total_tokens}"
)

บนเครื่องของฉัน โมเดลตอบด้วยโค้ด pandas แบบ one-liner ที่เชื่อมคำสั่ง และได้ตัวเลขการใช้งานดังนี้:

ตัวเลขเหล่านี้ซ่อนความต่างจริงจังจาก 3.7 ฉันรันงานเดียวกันอีกครั้งด้วยพรอมป์ตที่ยาวขึ้นและไม่จำกัดเอาต์พุต และ 3.8 ใช้โทเค็นคิด 1,436 เทียบกับโทเค็นเอาต์พุต 870 เมื่อมีข้อจำกัด มันใช้ 1,515 ต่อ 42 งบคิดแทบไม่เปลี่ยน ซึ่งตรงข้ามกับ 3.7 ที่พรอมป์ต 2 แบบเดียวกันทำให้โทเค็นคิดแกว่งจาก 838 เป็น 1,530

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

สตรีมการตอบกลับ

สำหรับอินเทอร์เฟซแชตหรือสิ่งที่คนดูอยู่ การรอผลลัพธ์ทั้งหมดหลายวินาทีรู้สึกช้า ให้ส่ง stream=True ไปที่ client.interactions.create() และพิมพ์ชิ้นส่วนตามที่มาถึง:

	from google import genai

	client = genai.Client()

	stream = client.interactions.create(
	   model="gemini-3.8-flash",
	   input="Explain the difference between a JOIN and a correlated subquery in SQL.",
	   generation_config={"thinking_level": "low"},
	   stream=True,
	)

	for event in stream:
	   if event.event_type == "step.delta" and event.delta.type == "text":
	       print(event.delta.text, end="", flush=True)
	print() 

ตอนรัน โมเดลส่งคำตอบยาวและเป็นระบบดีที่ thinking_level: "low": มีการเปรียบเทียบเชิงแนวคิด ตารางสรุป และตัวอย่าง SQL 2 แบบสำหรับหาคำสั่งซื้อล่าสุดของลูกค้าแต่ละราย แบบหนึ่งใช้ join กับ derived table และอีกแบบใช้ correlated subquery ใน SELECT คำแรก ๆ โผล่มาแทบจะทันที ซึ่งก็คือสาระสำคัญของการสตรีม

คำสั่ง print() ท้ายสุดมีเหตุผล หากไม่ใส่ ชิ้นสุดท้ายจะจบกลางบรรทัด และ zsh จะแสดงเครื่องหมาย % เกินมาก่อนพรอมป์ต เพราะสตรีมหยุดตรงที่ข้อความโมเดลหยุดพอดี นอกจากนี้ เดลตาจะมีข้อความก็ต่อเมื่อคุณล็อกจำนวนโทเค็นต่อคำขอ ให้อ่านจากอีเวนต์ completion สุดท้ายแทนที่จะบวกชิ้นส่วน

thinking_level ส่งผลต่อค่าใช้จ่ายและคุณภาพอย่างไร?

thinking_level กำหนดว่า Gemini 3.8 Flash จะให้เหตุผลมากแค่ไหนก่อนเขียนคำตอบ โทเค็นให้เหตุผลคิดเงินในเรตเอาต์พุต $3.75 ต่อ 1M ดังนั้นระดับที่เลือกจะควบคุมต้นทุนและความหน่วงโดยตรง และ Google ระบุว่า 3.8 ตั้งใจใช้สิ่งนี้: จะเพิ่มขั้นตอนให้เหตุผลกับงานซับซ้อนและอาจใช้โทเค็นมากขึ้นที่ระดับความพยายามสูงกว่าเมื่อเทียบกับ 3.7

รันพรอมป์ตเดียวกันที่ low, medium และ high

การทดสอบคือ race condition ในฟังก์ชันชำระเงินซ้ำ ที่ส่งด้วยพรอมป์ตเดียวกันในทั้ง 3 ระดับ บั๊กด้าน concurrency จะลงโทษการอ่านผ่าน ๆ ดังนั้นถ้าระดับต่างกัน ตรงนี้น่าจะเห็นความต่าง หากจะรันโค้ดเพียงบล็อกเดียวจากบทความนี้ ให้รันบล็อกนี้ เพราะตัวเลขพูดได้ดีกว่าข้อความใด ๆ

import time

from google import genai

client = genai.Client()

BUGGY_CODE = '''
import threading

payment_attempts = {}

def retry_payment(order_id, charge_fn, max_retries=3):
    """Retry a failed payment up to max_retries times."""
    if order_id not in payment_attempts:
        payment_attempts[order_id] = 0

    while payment_attempts[order_id] < max_retries:
        success = charge_fn(order_id)
        if success:
            del payment_attempts[order_id]
            return True
        payment_attempts[order_id] += 1
    return False
'''

PROMPT = (
    "Two worker threads can call retry_payment() with the same order_id "
    "at the same time. Identify the concurrency bug that can double-charge "
    "a customer, and rewrite the function to fix it.\n\n" + BUGGY_CODE
)

for level in ["low", "medium", "high"]:
    start = time.perf_counter()
    interaction = client.interactions.create(
        model="gemini-3.8-flash",
        input=PROMPT,
        generation_config={"thinking_level": level},
    )
    elapsed = time.perf_counter() - start
    usage = interaction.usage
    print(f"\n=== thinking_level: {level} | {elapsed:.1f}s ===")
    print(interaction.output_text)
    print(
        f"input={usage.total_input_tokens} | output={usage.total_output_tokens} | "
        f"thinking={usage.total_thought_tokens}"
    )

เพื่อบริบท ช่องโหว่คือการเช็กแล้วลงมือบน payment_attempts[order_id] แบบไม่อะตอมมิก ภายใต้ concurrency เธร็ด 2 ตัวอาจผ่านเงื่อนไข while พร้อมกัน และทั้งคู่เรียก charge_fn() ก่อนที่ตัวใดตัวหนึ่งจะเพิ่มเคาน์เตอร์ การแก้คือต้องห่อกระบวนอ่าน-เช็ก-ชาร์จ-เพิ่มเคาน์เตอร์ด้วยล็อกต่อออร์เดอร์ หรือใช้ idempotency key ที่เกตเวย์

เปรียบเทียบผลลัพธ์

ผลจากการรันของฉัน:

ทั้ง 3 ระดับพบปัญหาชาร์จซ้ำ และทั้ง 3 เลือกล็อกต่อออร์เดอร์ ทำให้ออร์เดอร์ที่ไม่เกี่ยวกันรันขนานกันได้ ส่วนที่เป็นไฮไลต์เมื่อเทียบกับ 3.7 คือ ที่นั่น low ล็อกทั้งระบบ 1 ตัวคลุมช่วงเรียกเครือข่าย และล็อกต่อออร์เดอร์เพิ่งโผล่ที่ medium บน 3.8 low เขียนดีไซน์ที่ดีกว่านั้นด้วยโทเค็นคิด 0 ใช้เวลา 7.8 วินาที และมีต้นทุนไม่ถึง 1 ใน 3 เซ็นต์

แล้วระดับต่าง ๆ ซื้ออะไรให้ตอนนี้? ความลึกของการตรวจสอบ โค้ดนี้มีโหมดล้มเหลว 4 แบบ (ชาร์จซ้ำ, KeyError ตอนลบพร้อมกัน, การชาร์จซ้ำหลังเส้นทางสำเร็จลบสถานะ, และการเพิ่มเคาน์เตอร์แบบไม่อะตอมมิก) และมีเพียง high ที่ระบุครบทั้ง 4; low พลาดเคสชาร์จซ้ำหลังสำเร็จ และ medium พลาดเคสเคาน์เตอร์

high ยังเป็นระดับเดียวที่อธิบาย semantics ของเส้นทางล้มเหลว: เมื่อหมดรอบ retry ผู้เรียกภายหลังจะได้ False แทนการชาร์จอีกครั้ง

คอลัมน์ thinking แสดงให้เห็นคำกล่าว "3.8 ทำงานหนักขึ้น" ของ Google แบบชัด ๆ บนพรอมป์ตเดียวกันบน 3.7 medium ขยับจาก 2,343 โทเค็นคิดเป็น 3,158 และ high จาก 2,217 เป็น 4,512 ราวเท่าตัว และโทเค็นที่เพิ่มซื้อการวิเคราะห์ที่ครบขึ้น ไม่ใช่คำตัดสินที่ต่างออกไป ความหน่วงเพิ่มตามในรันนี้ (7.8 s, 16.6 s, 25.5 s) แต่เวลาในรันเดี่ยวของโมเดลเหล่านี้แกว่งได้ จึงควรเทียบจำนวนโทเค็นมากกว่าวินาที

เลือกค่าปริยายและเมื่อใดควรขยับระดับ

กฎจำง่ายสำหรับระดับการให้เหตุผลมีดังนี้:

• บน 3.8 low ทำได้ดีกว่าที่ค่าเริ่มต้นของ Google บอกไว้: ให้คำแก้ที่ถูกต้องและออกแบบดีด้วยโทเค็นคิด 0 ดังนั้นเริ่มจากระดับนี้สำหรับทุกอย่างที่มนุษย์อ่านก่อนสำคัญ (ไตรเอจ ร่าง สรุป โค้ดที่ตั้งใจรีวิว) 

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

• สำรอง high สำหรับเอาต์พุตที่เส้นทางล้มเหลวเองคือผลิตภัณฑ์ เช่น โฟลว์การชำระเงิน การย้ายระบบ หรือสิ่งที่ผู้ตรวจจะอ่านบรรทัดต่อบรรทัด ในรันของฉัน มันเป็นระดับเดียวที่จับบั๊กครบทั้ง 4 และระบุสิ่งที่เกิดขึ้นหลัง retry หมด

ที่ต้นทุนสูงกว่า 6.6 เท่าของ low สำหรับ high การแลกเปลี่ยนจะรู้สึกต่างกันมากที่ราคา $3.75 ต่อโทเค็นเอาต์พุต 1M ตอนนี้ เทียบกับ $7.50 หลัง 31 ธันวาคม 2026 ดังนั้นให้ขยับระดับเป็นรายคำขอ แทนการเปลี่ยนทั้งระบบ

ช่องทางหนีที่ควรรู้คือ Google ระบุว่า 3.7 Flash ยังรองรับเต็มที่สำหรับงานที่เอาประสิทธิภาพมาก่อน หากความพิถีพิถันเพิ่มของ 3.8 ทำให้แพงเกินความต้องการของงาน อยู่บน gemini-3.7-flash สำหรับงานนั้นถือว่าเป็นแนวทางที่รองรับ ไม่ใช่แฮ็ก

ดึงข้อมูลเชิงโครงสร้างจาก PDF อย่างไร?

Gemini 3.8 Flash อ่าน PDF ได้โดยตรงเป็นอินพุต จึงสามารถส่งใบแจ้งหนี้หรือรายงานแล้วถามคำถามเกี่ยวกับเอกสารได้ ฉันใช้ใบแจ้งหนี้ผู้ขาย 1 หน้า ที่มีเลขที่ใบแจ้งหนี้ วันที่ รายการ 4 บรรทัด และยอดรวม

แนบ PDF กับพรอมป์ต

อัปโหลดไฟล์ PDF ใบแจ้งหนี้จากเครื่องผ่าน Files API ซึ่งจัดการที่เก็บไฟล์และแคชบนโครงสร้างพื้นฐานของ Google:

	from google import genai
	client = genai.Client()
	print("Uploading invoice...")
	doc = client.files.upload(file="invoice_aug_2026.pdf")
	print(f"File uploaded: {doc.uri}\n")

	interaction = client.interactions.create(
	   model="gemini-3.8-flash",
	   input=[
	       {
	           "type": "text",
	           "text": "Extract the invoice number, total amount due, and due date.",
	       },
	       {"type": "document", "uri": doc.uri, "mime_type": doc.mime_type},
	   ],
	)
	print(interaction.output_text)

ผลลัพธ์จากใบแจ้งหนี้ของฉัน:

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

บังคับให้ส่ง JSON ด้วยสคีมาของการตอบกลับ

หากต้องการ JSON แทนร้อยแก้ว ให้ส่งสคีมาใน response_format บน Interactions API นี่เป็นพารามิเตอร์ระดับบนสุด ค่า responseMimeType ภายใน generationConfig ที่เห็นในบทเรียนรุ่นเก่าเป็นของเอ็นด์พอยต์ generateContent แบบเดิม

import json

from google import genai
from pydantic import BaseModel

client = genai.Client()


class Invoice(BaseModel):
    invoice_number: str
    total_due_usd: float
    due_date: str  # ISO 8601


doc = client.files.upload(file="invoice_aug_2026.pdf")

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input=[
        {
            "type": "text",
            "text": "Extract the invoice number, total amount due in USD, and due date.",
        },
        {"type": "document", "uri": doc.uri, "mime_type": doc.mime_type},
    ],
    response_format={
        "type": "text",
        "mime_type": "application/json",
        "schema": Invoice.model_json_schema(),
    },
)

invoice = json.loads(interaction.output_text)
print(invoice)

นี่คือเอาต์พุตที่ฉันได้รับ: 

คลาส Pydantic ของคุณกำหนดฟิลด์ที่ต้องมีและชนิดข้อมูล ขณะที่ model_json_schema() สร้าง JSON schema ที่ Gemini API ต้องการ เมื่อได้รับผลลัพธ์แล้ว json.loads() จะเปลี่ยนเอาต์พุตของโมเดลให้เป็นดิกชันนารี Python มาตรฐาน ตั้งแต่นี้ ข้อมูลเชิงโครงสร้างพร้อมจะถูกแปลงเป็นแถวของ DataFrame คอมมิตลงฐานข้อมูล หรือเพิ่มใน Google Sheet

ถามต่อด้วย previous_interaction_id

สำหรับคำถามที่ 2 เกี่ยวกับเอกสารเดียวกัน ให้ส่ง id ของอินเทอร์แอ็กชันแรกเป็น previous_interaction_id เซิร์ฟเวอร์มีทั้ง PDF และบทสนทนาแรกอยู่แล้ว จึงไม่ต้องส่งซ้ำ:

follow_up = client.interactions.create(
    model="gemini-3.8-flash",
    previous_interaction_id=interaction.id,
    input="List each line item on the invoice with its amount.",
)

print(follow_up.output_text)

ได้รายการทั้ง 4 ตามลำดับ รวมถึงบรรทัด compute ที่ซ้ำ โดยไม่คอมเมนต์เรื่องความซ้ำ ซึ่งถูกต้องตามคำถามที่ถาม หากต้องการให้ธงความผิดปกติ ให้สั่งเพิ่ม

ในส่วนนี้ 3.7 ก็ทำงานเหมือนกัน ดังนั้นความพิถีพิถันเพิ่มของ 3.8 ใช้กับการให้เหตุผลของตัวมันเอง ไม่ใช่การอาสาตรวจสอบสิ่งที่คุณไม่ได้ร้องขอ

มี 2 เรื่องที่ควรรู้เกี่ยวกับคำขอนี้: 

• response_format ไม่ได้พกต่อมา เพราะมันผูกกับอินเทอร์แอ็กชัน เทิร์นนี้จึงส่งกลับมาเป็นร้อยแก้ว 

• และอินเทอร์แอ็กชันจะถูกเก็บค่าเริ่มต้น (store=True) เป็นเวลา 55 วันบนแพ็กเกจแบบเสียเงิน และ 1 วันบนแพ็กเกจฟรี; การตั้ง store=False ทำให้คำขอไร้สถานะ แต่จะไม่สามารถ chain previous_interaction_id จากมันได้

เพิ่ม Function Calling ให้ Gemini 3.8 Flash อย่างไร?

Function calling บน Gemini 3.8 Flash เป็นลูปเดียว: โมเดลขอใช้เครื่องมือ โค้ดของคุณรันมัน ส่งผลลัพธ์กลับ และโมเดลเขียนคำตอบสุดท้าย ส่วนนี้จะสร้างลูปนั้นด้วยตนเอง

หากต้องการให้ Google รันลูปให้ด้วยเอเจนต์หลายเครื่องมือแบบโฮสต์ อ่านบทเรียนเรื่อง  "Managed Agents" ใน Gemini API ต่อ และหากเอเจนต์คือทิศทางระยะยาว หลักสูตร Building AI Agents with Google ADK จะสร้างผู้ช่วยซัพพอร์ตลูกค้าเต็มรูปแบบบนพริมิติฟเดียวกัน

ประกาศเครื่องมือและรันลูปอินเทอร์แอ็กชัน

เครื่องมือคือ lookup_exchange_rate(currency, date) รองรับด้วยดิกชันนารีในหน่วยความจำเล็ก ๆ เพื่อให้ตัวอย่างรันได้โดยไม่ต้องพึ่ง API ภายนอก การประกาศเป็น JSON schema โมเดลจะไม่รันฟังก์ชันเอง แต่จะคืนสเต็ป function_call ขอให้โค้ดของคุณ:

import json

from google import genai

client = genai.Client()

# Local "data source" standing in for a real FX API
RATES = {
    ("USD", "2026-08-03"): 87.42,
    ("USD", "2026-08-10"): 87.15,
    ("EUR", "2026-08-03"): 95.08,
}


def lookup_exchange_rate(currency: str, date: str) -> dict:
    rate = RATES.get((currency.upper(), date))
    if rate is None:
        return {"error": f"No rate for {currency} on {date}"}
    return {"currency": currency.upper(), "date": date, "inr_rate": rate}


rate_tool = {
    "type": "function",
    "name": "lookup_exchange_rate",
    "description": "Look up the INR exchange rate for a currency on a date (YYYY-MM-DD).",
    "parameters": {
        "type": "object",
        "properties": {
            "currency": {"type": "string", "description": "ISO code, e.g. USD"},
            "date": {"type": "string", "description": "YYYY-MM-DD"},
        },
        "required": ["currency", "date"],
    },
}

# Turn 1: the model decides to call the tool
interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="What was the USD to INR exchange rate on 2026-08-03?",
    tools=[rate_tool],
)

fc_step = next(s for s in interaction.steps if s.type == "function_call")
print(f"Model requested: {fc_step.name}({fc_step.arguments})")

# Your code executes the function locally
result = lookup_exchange_rate(**fc_step.arguments)

# Turn 2: send the result back; tools must be re-specified (interaction-scoped)
final = client.interactions.create(
    model="gemini-3.8-flash",
    previous_interaction_id=interaction.id,
    input=[
        {
            "type": "function_result",
            "name": fc_step.name,
            "call_id": fc_step.id,
            "result": [{"type": "text", "text": json.dumps(result)}],
        }
    ],
    tools=[rate_tool],
)

print(final.output_text)

เอาต์พุต: 

มี 3 อย่างเกิดขึ้นที่นี่:  

1. เทิร์นแรกส่งกลับสเต็ป function_call พร้อมชื่อ อาร์กิวเมนต์แบบมีโครงสร้าง และ id

2. Python ของคุณรันการค้นหา

3. เทิร์นที่สองส่งบล็อก function_result อ้างอิงการเรียกนั้น 

พารามิเตอร์ tools ถูกส่งอีกครั้งในเทิร์นที่สองด้วยเหตุผลเดียวกับที่ต้องส่ง response_format ซ้ำในส่วน PDF: previous_interaction_id พกเฉพาะประวัติ ไม่พกคอนฟิก

ข้อผิดพลาดในการเรียกฟังก์ชันบน Gemini 3.x

หากลูปเครื่องมือพัง มักเป็น 1 ใน 2 เรื่องนี้ 

อย่างแรก ผลลัพธ์ทุกชิ้นต้องแม็ปกลับไปยังการเรียก บน Interactions API คือ call_id และ name บนบล็อก function_result; บน API generateContent แบบเดิม FunctionResponse ต้องตรงกับ id และ name ของ FunctionCall ที่มาก่อน ไม่มีอันไหนเป็นออปชันบน Gemini 3.x

อย่างที่สอง ข้อผิดพลาด Malformed_Function_Call มักเกิดเมื่อโมเดลพิมพ์คอมเมนต์ก่อนเรียกเครื่องมือ เอกสารนักพัฒนารุ่น 3.8 ของ Google แนะนำให้ลบข้อความก่อนเครื่องมือ จัดรูปแบบคำสั่งในบรรทัดด้วย \n\n และห่อโน้ตการทำงานในคำเรียกฟังก์ชันเฉพาะ แทนการพิมพ์ดิบ ๆ ให้เข้มงวด system instruction และอย่ารีทรายแบบสุ่ม

อะไรจะพังเมื่อสลับมาใช้ Gemini 3.8 Flash?

ขึ้นกับว่าคุณเริ่มจากไหน 

• จาก Gemini 3.7 Flash: ไม่มีอะไร เปลี่ยนสตริงโมเดลเป็น gemini-3.8-flash แล้วโค้ดทุกชิ้นในบทความนี้รันได้โดยไม่ต้องแก้ เพราะพื้นผิว API เหมือนกัน 

• จาก Gemini 3.6 Flash หรือต่ำกว่า คอนฟิกของโมเดลต้องตรวจสอบ 15 นาทีเหมือนเดิม

เช็กลิสต์การย้ายระบบ (จาก 3.6 Flash หรือต่ำกว่า)

ทำตามลำดับนี้ ข้อ 1 ถึง 3 จะทำให้เกิด 400 ทันที; ข้อ 4 และ 5 จะทำให้คุณภาพแย่ลงแบบเงียบ ๆ

1. เปลี่ยนรหัสโมเดลเป็น gemini-3.8-flash

2. ลบพารามิเตอร์ sampling ที่เลิกใช้: temperature, top_p, และ top_k จะถูกเพิกเฉยหรือถูกปฏิเสธบน Gemini 3.x และ frequency_penalty, presence_penalty, candidate_count จะทิ้ง error จาก API โดยตรง ลบทั้ง 6 ออกจากคอนฟิกเก่า

3. แทนที่ thinking_budget ด้วย thinking_level: ใช้เฉพาะ low, medium หรือ high ค่า minimal แบบเก่าจะโดน validation error การส่งทั้ง thinking_budget และ thinking_level ในคำขอเดียวจะได้ 400

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

5. มาตรฐานฟลโลว์หลายเทิร์น: พึ่ง previous_interaction_id แทนการรีเพลย์ประวัติฝั่งไคลเอนต์ ต้องส่ง tools, system_instruction และ generation_config ซ้ำในทุกเทิร์นที่จำเป็น

Google เผยแพร่ฉบับอ้างอิงใน เอกสารโมเดล Gemini API รวมถึงเส้นทางอัตโนมัติหากเอเจนต์เขียนโค้ดของคุณรองรับสกิล ถึงอย่างนั้นก็ควรอ่านเองสักครั้ง; การย้ายแบบอัตโนมัติจะไม่บอกว่าทำไม temperature=0.2 จึงถูกตั้งไว้ตั้งแต่แรก

ข้อผิดพลาดที่มักเจอในโปรดักชัน

นี่คือ 4 สถานะที่ควรทำตัวจัดการไว้ และความหมายที่แท้จริงบน API นี้:

ยังมีอีก 2 เรื่อง:

• ตั้ง timeout ให้ไคลเอนต์อย่างชัดเจนเมื่อใช้ thinking_level: "high" ร่วมกับลูปเครื่องมือยาว ๆ เพราะคำขอที่ค้างแย่กว่าคำขอที่ล้มเหลว และความพิถีพิถันเพิ่มของ 3.8 ทำให้การให้เหตุผลยาว ๆ เกิดขึ้นได้มากขึ้น ไม่ใช่น้อยลง 

• และล็อก interaction.id กับทุกคำขอ; มันคือแฮนด์สำหรับดึง ดีบัก หรือ ลบอินเทอร์แอ็กชันที่เก็บไว้ภายหลัง

ส่งท้าย

ทุกอย่างในบทความนี้โยงกลับไปที่การเปลี่ยน 3 อย่าง Interactions API เปลี่ยนรูปแบบการเรียก thinking_level แทนที่ปุ่มปรับ sampling ทั้งหมดที่เคยใช้ และสถานะฝั่งเซิร์ฟเวอร์ผ่าน previous_interaction_id คือสิ่งที่ทำให้ทั้งคำถามต่อจาก PDF และลูปเครื่องมือกลายเป็นเทิร์นแบบ 1 บรรทัด แทนการรีเพลย์ประวัติ Gemini 3.8 Flash ไม่ได้เปลี่ยนสิ่งเหล่านี้บนผิว; สิ่งที่เปลี่ยนคือความพยายามของโมเดลภายใน ซึ่งเป็นเหตุผลที่การวัดผลในบทความนี้ถูกรันใหม่บน 3.8 แทนที่จะยกมาจาก 3.7

ก่อนจะเชื่อคำแนะนำเรื่องระดับ ลองสคริปต์เปรียบเทียบกับงานในแบ็กล็อกของคุณเอง; ระดับที่ชนะบนงาน payment-retry race อาจแพ้บนเวิร์กโหลดสร้าง SQL ของคุณก็ได้ 

เมื่อคำขอ API เดี่ยวไม่พอ และต้องการระบบ AI ระดับโปรดักชัน ดูหลักสูตร Associate AI Engineer for Developers ของเรา และหลักสูตร Associate AI Engineer for Data Scientists สำหรับสายดาต้า