Contact
Line : comsiam
Contact
Line : comsiam

Gemini API สามารถเชื่อมกับ Google Search เพื่อให้โมเดลค้นหาข้อมูลจากเว็บแบบปัจจุบันก่อนสร้างคำตอบ ช่วยลดข้อจำกัดของการตอบจากความรู้ภายในโมเดลเพียงอย่างเดียว และเหมาะกับคำถามที่ข้อมูลมีการเปลี่ยนแปลงตลอดเวลา เช่น ข่าว ราคาสินค้า ผลการแข่งขัน ข้อมูลบริษัท เหตุการณ์ล่าสุด หรือข้อมูลที่ต้องตรวจสอบแหล่งอ้างอิง
ความสามารถนี้เรียกว่า Grounding with Google Search
สำหรับ Interactions API รุ่นปัจจุบัน การเปิด Google Search ทำได้ง่ายมาก เพียงเพิ่ม Tool
google_search
เข้าไปใน Request
ตัวอย่าง Python พื้นฐาน
from google import genai
client = genai.Client()
interaction = client.interactions.create(
model="gemini-3.7-flash",
input="สรุปข่าว AI ล่าสุดวันนี้",
tools=[
{
"type": "google_search",
}
],
)
print(interaction.output_text)
เมื่อเปิด Tool นี้ Gemini จะจัดการ Workflow ตั้งแต่
วิเคราะห์คำถาม
↓
ตัดสินใจว่าต้องค้นหรือไม่
↓
สร้าง Search Query
↓
ค้น Google
↓
อ่านผลการค้นหา
↓
สังเคราะห์ข้อมูล
↓
สร้างคำตอบ
↓
แนบ Citation
Developer ไม่จำเป็นต้องสร้าง Search Query เองทุกครั้ง
Grounding หมายถึงการให้โมเดลนำข้อมูลจากแหล่งภายนอกมาใช้เป็นฐานในการตอบ
ถ้าไม่เปิด Search
User
↓
Gemini Model
↓
Model Knowledge
↓
Answer
เมื่อเปิด Google Search
User
↓
Gemini
↓
Google Search
↓
Web Information
↓
Gemini
↓
Grounded Answer
+
Citations
จึงเหมาะกับข้อมูลที่ต้องการความสดใหม่และตรวจสอบย้อนกลับได้
ควรพิจารณาเปิด Search เมื่อคำตอบขึ้นกับข้อมูลปัจจุบัน
ตัวอย่าง
วันนี้มีข่าว AI สำคัญอะไรบ้าง
ราคาหุ้นบริษัท X ล่าสุดเป็นอย่างไร
เมื่อคืนทีม X แข่งกับทีม Y ผลเป็นอย่างไร
มือถือรุ่นนี้เปิดตัวแล้วหรือยัง
บริษัทนี้ประกาศผลิตภัณฑ์ใหม่ล่าสุดอะไร
ตอนนี้มีเหตุการณ์อะไรเกิดขึ้นในประเทศนี้
งานเหล่านี้ไม่ควรพึ่ง Model Knowledge เพียงอย่างเดียว
Google Search ไม่ได้จำเป็นกับทุก Prompt
ตัวอย่าง
2 + 2 เท่ากับเท่าไร
อธิบาย Python list
ช่วยปรับข้อความนี้ให้อ่านง่ายขึ้น
แปลประโยคนี้เป็นภาษาไทย
หากข้อมูลทั้งหมดอยู่ใน Prompt แล้ว Search อาจเพิ่ม
โดยไม่มีประโยชน์ชัดเจน
เมื่อเพิ่ม
{
"type": "google_search"
}
ไม่ได้หมายความว่าทุก Prompt จะต้องสร้าง Search Query เสมอไป
Gemini สามารถวิเคราะห์คำถามก่อนว่า Search ช่วยให้คำตอบดีขึ้นหรือไม่
Flow คือ
Prompt
↓
Gemini วิเคราะห์
↓
ต้องข้อมูลเว็บหรือไม่?
├── ไม่ต้อง → ตอบ
└── ต้อง → Google Search
ดังนั้น Developer เปิดความสามารถ Search ให้โมเดล แล้วโมเดลจัดการขั้นตอนค้นหาตามความเหมาะสม
ติดตั้ง SDK ปัจจุบัน
pip install -U google-genai
ตั้ง API Key ผ่าน
GEMINI_API_KEY
จากนั้นสร้างไฟล์
search.py
Code
from google import genai
client = genai.Client()
interaction = client.interactions.create(
model="gemini-3.7-flash",
input=(
"ค้นหาข่าว AI ล่าสุด "
"และสรุปเหตุการณ์สำคัญ 5 ข้อ"
),
tools=[
{
"type": "google_search",
}
],
)
print(interaction.output_text)
Run
python search.py
หาก Search ถูกใช้งาน Gemini จะค้นข้อมูลแล้วสร้างคำตอบจาก Search Results
client = genai.Client()
ใช้ Gemini API Credential จาก Environment
model="gemini-3.7-flash"
เป็น Stable Model ปัจจุบันที่รองรับ Google Search Grounding
input="ค้นหาข่าว AI ล่าสุด..."
คือคำถามของ User
tools=[
{
"type": "google_search",
}
]
นี่คือส่วนสำคัญที่สุด
หากไม่มี Tool นี้ Request จะไม่ใช้ Grounding with Google Search
ติดตั้ง
npm install @google/genai
ตัวอย่าง
import { GoogleGenAI } from "@google/genai";
const ai = new GoogleGenAI({});
const interaction =
await ai.interactions.create({
model: "gemini-3.7-flash",
input:
"ค้นหาข่าวเทคโนโลยีล่าสุดและสรุป 5 ข้อ",
tools: [
{
type: "google_search",
},
],
});
console.log(interaction.output_text);
หลักการเหมือน Python
Create Client
↓
Input
↓
Enable google_search
↓
Gemini searches
↓
Return Answer
ได้
PHP, Go, C#, Ruby หรือภาษาอื่นที่เรียก HTTP ได้สามารถใช้ Google Search Tool ผ่าน REST ได้
Request Body พื้นฐาน
{
"model": "gemini-3.7-flash",
"input": "ค้นหาข่าว AI ล่าสุดและสรุป 5 ข้อ",
"tools": [
{
"type": "google_search"
}
]
}
ดังนั้น Feature นี้ไม่ได้จำกัดเฉพาะ Python หรือ JavaScript
Google อธิบาย Workflow หลักไว้ประมาณนี้
Application ส่งคำถามพร้อมเปิด Google Search Tool
Gemini วิเคราะห์ว่าคำถามควร Search หรือไม่
หากต้องการข้อมูลเว็บ Gemini สร้าง Search Query เอง
Query ถูกส่งไปค้นหา
Gemini อ่านและสังเคราะห์ Search Results
โมเดลสร้าง Final Answer พร้อมข้อมูลอ้างอิง
Developer ไม่จำเป็นต้องสร้าง Search Engine Workflow ทุกส่วนด้วยตนเอง
คำถามหนึ่ง Prompt ไม่จำเป็นต้องค้นเพียงครั้งเดียว
ตัวอย่าง User ถาม
เปรียบเทียบข่าวล่าสุดของบริษัท A กับบริษัท B
Gemini อาจสร้าง Query
บริษัท A latest news
และ
บริษัท B latest news
หรือ Query เพิ่มเติมเพื่อยืนยันข้อมูล
ดังนั้น
1 User Prompt
อาจเท่ากับ
หลาย Google Search Queries
จุดนี้สำคัญมากเมื่อคำนวณค่าใช้จ่าย
Interactions API สามารถคืน Steps เช่น
thought
google_search_call
google_search_result
model_output
ตัวอย่าง Structure แบบย่อ
{
"steps": [
{
"type": "google_search_call",
"arguments": {
"queries": [
"latest AI news"
]
}
},
{
"type": "google_search_result",
"result": [
{
"search_suggestions": "..."
}
]
},
{
"type": "model_output",
"content": [
{
"type": "text",
"text": "...",
"annotations": []
}
]
}
]
}
ข้อมูลเหล่านี้ช่วยให้ Application ตรวจสอบว่า Gemini ใช้ Search อย่างไร
ได้
ให้ตรวจ Step
google_search_call
ภายในจะมี
queries
ตัวอย่าง
{
"type": "google_search_call",
"arguments": {
"queries": [
"AI news today",
"latest generative AI announcements"
]
}
}
จึงสามารถนำไปใช้กับ
ได้ตาม Privacy Policy ของระบบ
จุดเด่นสำคัญของ Grounding with Google Search คือ Response สามารถมี Citation
Citation อยู่ใน
annotations
ของ Text Content Block
ตัวอย่าง Structure
{
"type": "text",
"text": "ข้อมูล...",
"annotations": [
{
"type": "url_citation",
"url": "...",
"title": "...",
"start_index": 0,
"end_index": 50
}
]
}
ทำให้ Developer รู้ว่า Source ใดสนับสนุนข้อความช่วงใด
start_index และ end_index ใช้ทำอะไรCitation ไม่ได้เพียงบอก URL
แต่สามารถบอกช่วงของ Text ที่ Source สนับสนุน
เช่น
Answer:
บริษัท X เปิดตัวผลิตภัณฑ์ใหม่วันนี้
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
start_index
→
end_index
Application สามารถนำข้อมูลนี้ไปสร้าง
ใน User Interface ได้
ตัวอย่าง
for step in interaction.steps:
if step.type == "model_output":
for content_block in step.content:
if content_block.type != "text":
continue
print(content_block.text)
if not content_block.annotations:
continue
print("\nแหล่งอ้างอิง:")
for annotation in (
content_block.annotations
):
if (
annotation.type
== "url_citation"
):
print(
annotation.title,
annotation.url,
)
วิธีนี้ช่วยให้ Application แสดงคำตอบและแหล่งข้อมูลแยกกันได้
สามารถใช้ Index
cited_text = content_block.text[
annotation.start_index:
annotation.end_index
]
จากนั้นแสดง
Source:
example.com
Supports:
"ข้อความช่วงนี้..."
เหมาะกับ Application ที่ต้องการ Traceability สูง
ตัวอย่าง
for (const step of interaction.steps) {
if (step.type !== "model_output") {
continue;
}
for (const block of step.content) {
if (block.type !== "text") {
continue;
}
console.log(block.text);
for (
const annotation
of block.annotations || []
) {
if (
annotation.type
=== "url_citation"
) {
console.log(
annotation.title,
annotation.url
);
}
}
}
}
สามารถนำข้อมูลไปสร้าง Source Card หรือ Citation UI ได้ต่อ
หาก Application ตอบว่า
บริษัท X เพิ่งเปิดตัว Product ใหม่
โดยไม่มี Source
User ต้องเชื่อ AI อย่างเดียว
แต่ถ้ามี Citation
คำตอบ
+
Source
ผู้ใช้สามารถตรวจสอบต่อได้
เหมาะมากกับ
Citation ไม่ได้ทำให้คำตอบถูก 100% แต่ช่วยให้ตรวจสอบได้ง่ายขึ้น
แม้ Gemini มี Source
Application ยังควรระวัง
ดังนั้น High-stakes Application ควรเพิ่ม
Search
↓
Sources
↓
Cross-check
↓
Validation
↓
Answer
ไม่ควรถือ Citation เป็น Guarantee ของ Truth
Step
google_search_result
สามารถมี
search_suggestions
ซึ่งเป็นข้อมูล HTML สำหรับแสดง Search Suggestions ใน UI ตามข้อกำหนดการใช้งานของ Google
Developer ที่นำ Search Grounding ไปสร้าง Public UI ควรตรวจ Requirement ของการแสดงผลและ Attribution ที่เกี่ยวข้องก่อน Deploy
ไม่ควรละเลยข้อมูลนี้เพียงเพราะ Application ใช้เฉพาะ output_text
ต้องแยก
สำหรับ Gemini 3.x Pricing ปัจจุบัน Google Search Grounding ใน Paid Tier ให้ Allowance
5,000 Search Requests / เดือน
แบบแชร์ระหว่าง Gemini 3.x Models ที่เกี่ยวข้อง
หลังจากนั้นราคา
$14 / 1,000 Search Requests
ตาม Pricing ปัจจุบัน
ราคาและ Allowance สามารถเปลี่ยนได้ จึงควรตรวจ Pricing ก่อนคำนวณ Production Cost
นี่เป็นจุดสำคัญมาก
Google ระบุว่าสำหรับ Gemini 3
1 Search Query
=
1 Billable Tool Use
ถ้า Prompt หนึ่งทำให้ Gemini Search
Query A
Query B
Query C
ก็สามารถนับเป็น
3 Search Requests
แม้ User ส่ง Prompt เพียงครั้งเดียว
ดังนั้นอย่าวาง Budget จาก
จำนวน User Prompts
อย่างเดียว
ต้องดู
Search Queries Executed
ด้วย
สมมติเดือนหนึ่งมี
100,000 User Prompts
และ Gemini ใช้ Search เฉลี่ย
1.5 Queries / Prompt
จะมี
150,000 Search Requests
หลังหัก Allowance ตาม Pricing ที่ใช้
ส่วนที่เกินจึงค่อยนำไปคำนวณ
จำนวน Search ที่คิดเงิน
÷
1,000
×
$14
และยังมีค่า Model Tokens แยกต่างหาก
Total Cost สามารถเป็น
Input Tokens
+
Output Tokens
+
Thinking Tokens
+
Google Search
+
Other Tools
ดังนั้น Feature Search ที่ User ใช้บ่อยควรมี Cost Monitoring แยก
ระบบ Production ควรเก็บอย่างน้อย
request_count
search_query_count
input_tokens
output_tokens
latency
status
model
และถ้าแยก Feature ได้
search_enabled
search_used
จะช่วยตอบคำถามว่า
เปิด Search แล้ว Cost เพิ่มเท่าไร
ได้จริง
สมมติ Application มี
70% คำถามทั่วไป
30% คำถามข้อมูลสด
ไม่จำเป็นต้องบังคับ Search 100%
สามารถออกแบบ Routing เช่น
คำถามต้องข้อมูลล่าสุด?
├── ใช่ → Search
└── ไม่ใช่ → Gemini ปกติ
ช่วยลด Cost และ Latency
วิธีง่ายคือดู Intent
คำที่มักต้อง Search เช่น
ล่าสุด
วันนี้
ตอนนี้
ราคา
ข่าว
ผลการแข่งขัน
เปิดตัวเมื่อไร
CEO ปัจจุบัน
แต่ Rule อย่างเดียวอาจไม่สมบูรณ์
อีกทางคือเปิด Search Tool แล้วให้ Gemini ตัดสินใจเองว่าจำเป็นหรือไม่
โดยทั่วไป Search Workflow เพิ่มขั้นตอน
จาก
Prompt
↓
Generation
เป็น
Prompt
↓
Search
↓
Process Results
↓
Generation
จึงสามารถเพิ่ม Latency
สำหรับ Application แบบ Real-time ควรวัด
ก่อน Deploy
ตัวอย่าง Python
import time
from google import genai
client = genai.Client()
start = time.perf_counter()
interaction = client.interactions.create(
model="gemini-3.7-flash",
input="ค้นหาข่าว AI ล่าสุด",
tools=[
{
"type": "google_search",
}
],
)
elapsed = time.perf_counter() - start
print(interaction.output_text)
print(f"{elapsed:.2f}s")
จากนั้นเปรียบเทียบกับ Request ที่ไม่เปิด Search
เหมาะเมื่อ
ต้องหา Source จากเว็บ
Gemini เลือก Search Query และ Source
เหมาะเมื่อ Developer หรือ User มี URL ที่ต้องการให้ Geminiอ่านโดยเฉพาะ
URL ที่กำหนด
↓
Gemini
↓
Analyze
ตัวอย่าง
Google Search
→ ค้นหาเว็บที่เกี่ยวข้อง
URL Context
→ อ่านเว็บที่เราระบุ
ทั้งสองสามารถใช้ร่วมกันได้ใน Workflow ที่รองรับ
ตัวอย่าง Use Case
User ถาม
เปรียบเทียบข้อมูลบนหน้า Product นี้
กับข้อมูลล่าสุดบนเว็บ
Workflow
Specific URL
+
Google Search
↓
Gemini
↓
Comparison
มีประโยชน์กับ Research Application
Search ใช้หา Data
จากนั้น Code Execution สามารถช่วย
ตัวอย่าง
ค้นหาข้อมูล
↓
Google Search
↓
ได้ตัวเลข
↓
Code Execution
↓
คำนวณ
↓
Answer
เหมาะกับ Data-driven Question ที่ต้องใช้ข้อมูลสดและการคำนวณ
สำหรับ Model ที่รองรับสามารถใช้ Search ร่วมกับ Maps
เหมาะกับ
ตัวอย่าง
Search ข่าว/ข้อมูลเว็บ
+
Maps ข้อมูลสถานที่
↓
Gemini
แต่ควรตรวจ Pricing ของ Tool ทั้งสองแยกกัน
Gemini 3 Models ปัจจุบันรองรับการรวม Built-in Tool อย่าง Google Search กับ Custom Function Calling ใน Workflow ที่รองรับ
ตัวอย่าง User ถาม
หาราคาตลาดล่าสุดของสินค้า X
แล้วเช็ก Stock ในร้านของเรา
Gemini สามารถ
Google Search
↓
ราคาตลาด
↓
get_product_stock()
↓
Internal Database
↓
Final Answer
นี่เป็นพื้นฐานของ AI Agent ที่ใช้ทั้ง Public Data และ Private Data
Tool Combination บางรูปแบบอาจมีสถานะ Preview
Production Application ควรตรวจ
ก่อนพึ่ง Workflow นี้เป็น Critical Path
ไม่ต้องบังคับ Gemini ให้ Search 10 ครั้ง
ควรอธิบาย Goal
ตัวอย่าง
ค้นหาข้อมูลล่าสุดเกี่ยวกับหัวข้อนี้
สรุปเฉพาะประเด็นที่ยืนยันได้
ถ้าหลายแหล่งให้ข้อมูลขัดแย้งกัน
ให้บอกความแตกต่าง
ช่วยให้ Model เข้าใจคุณภาพคำตอบที่ต้องการ
ตัวอย่าง
ใช้ข้อมูลล่าสุด ณ วันนี้
และแยกเหตุการณ์ตามวันที่เกิดขึ้นจริง
เพราะบทความหรือ Search Result อาจถูกเผยแพร่วันนี้แต่พูดถึงเหตุการณ์เก่า
Application ข่าวควรแยก
Publication Date
vs
Event Date
เสมอ
Prompt เช่น
ค้นหาข้อมูลจากหลายแหล่ง
หากข้อมูลตรงกันให้สรุป
หากขัดแย้งกันให้แสดงความแตกต่าง
ช่วยลดการพึ่ง Source เดียว
แต่ไม่ได้รับประกันว่า Gemini จะค้นจำนวน Source ที่ตายตัว
หาก Requirement ต้องชัดมาก Application อาจต้องตรวจ Citation เพิ่มเอง
Architecture
User Topic
↓
Gemini + Google Search
↓
Current Sources
↓
Summarization
↓
Citations
↓
News Brief
แต่ควรเก็บ
เพื่อให้ User ตรวจสอบข้อมูลได้
ตัวอย่าง
ค้นหาข้อมูลรุ่นล่าสุด
สเปก
ราคา
รีวิว
↓
Gemini
↓
Comparison
แต่ราคาและ Stock เปลี่ยนเร็ว
ควรระบุ Timestamp ของข้อมูลหาก Product ต้องการความแม่นยำสูง
ตัวอย่าง
Company
↓
Google Search
↓
Latest News
Funding
Product Launches
Leadership Changes
↓
Gemini Summary
เหมาะกับ
แต่ Financial Decision ควรตรวจ Source โดยตรงเพิ่มเติม
สามารถใช้ Search แล้วให้ Final Output เป็น Structured Data ใน Workflow ที่รองรับ
ตัวอย่าง
{
"headline": "...",
"summary": "...",
"event_date": "...",
"sources": []
}
เหมาะกับ Data Pipeline
แต่ Source/Citation Metadata ที่ API คืนควรถูกจัดการตาม Metadata จริง ไม่ควรให้โมเดลแต่ง URL ขึ้นเอง
ถ้า API มี
annotations
ควรใช้ Citation Metadata ที่ API คืน
แทนให้ Prompt สั่ง
กรุณาเขียน URL ของแหล่งข้อมูลเอง
เพราะ URL ที่โมเดลสร้างใน Free-form Text อาจผิดได้
Metadata จาก Search Grounding เป็นวิธีที่เหมาะกว่า
Google Search Tool ถูกออกแบบสำหรับ Web Search
ถ้าข้อมูลอยู่ใน
ควรใช้
ตาม Architecture
ไม่ควรคาดหวัง Google Search ให้เข้าถึงข้อมูล Private ที่ไม่ได้อยู่บนเว็บ
Grounding with Google Search เชื่อมโมเดลกับข้อมูลเว็บที่ Search เข้าถึงได้
หากข้อมูลอยู่หลัง
Login
Paywall
Private Session
Application ไม่ควรสมมติว่าจะดึงรายละเอียดทั้งหมดได้
หาก Developer มี URL หรือข้อมูลที่ได้รับสิทธิ์เอง ต้องเลือก Integration ที่เหมาะสมตาม Source นั้น
ก่อนส่ง User Prompt ที่มี
เข้า AI Workflow ต้องตรวจ Data Policy ของ Application
ไม่ควรส่ง Secret ไปกับ Prompt เพียงเพื่อให้ Search ทำงาน
หลักคือ
ส่งเฉพาะข้อมูลที่จำเป็น
เมื่อ AI อ่านข้อมูลจากเว็บ เนื้อหาเว็บเป็น External Input
Application ไม่ควรถือว่า
ข้อมูลจากเว็บไซต์
=
Instruction ที่เชื่อถือได้
เว็บไซต์อาจมีข้อความพยายามชักนำโมเดล
ระบบ Agent ที่ใช้ Search ร่วมกับ Write Function จึงต้องมี Security Boundary ที่ Backend
โดยเฉพาะ Tool เช่น
ไม่ควร
Search Web
↓
อ่านข้อความเว็บ
↓
Gemini ตัดสินใจ
↓
โอนเงินทันที
ควรเป็น
Search
↓
Gemini Recommendation
↓
Validation
↓
User Confirmation
↓
Backend Permission
↓
Action
Public Web Content ไม่ควรสามารถควบคุม Critical Action ได้โดยตรง
ควรเก็บข้อมูลที่จำเป็น เช่น
timestamp
model
search_used
search_query_count
latency
status
และอาจเก็บ Query หาก Privacy Policy อนุญาต
ไม่ควร Log
สำหรับระบบ Search-heavy สามารถดู
Search Requests / day
Queries / User Prompt
Search Cost
Search Latency
Citation Count
Error Rate
ถ้า Queries ต่อ Prompt เพิ่มจาก
1.2
→
4.8
Cost อาจเพิ่มหลายเท่าแม้จำนวน User ไม่เปลี่ยน
Public AI Search App ควรมี Product Quota เช่น
Free User
→ X searches/day
Paid User
→ Y searches/day
ตาม Business Model
ไม่ควรให้ User ส่ง Search Prompt แบบ Unlimited หากเจ้าของ Application เป็นผู้รับ Cost
ขึ้นอยู่กับ Use Case และ Terms ของข้อมูลที่เกี่ยวข้อง
Application สามารถพิจารณา Cache Final Result ของตัวเองสำหรับคำถามที่ไม่ต้อง Real-time ทุกครั้ง
เช่น
คำถามเดียวกัน
มี User ถาม 1,000 คน
อาจไม่จำเป็นต้องสร้าง Gemini Search ใหม่ 1,000 ครั้งหาก Business Requirement อนุญาต
แต่ข้อมูลสดมากควรกำหนด TTL ให้สั้นตามความเหมาะสม
ตัวอย่าง
TTL = นาที
TTL = ชั่วโมง/วัน
อาจ Cache ได้นานกว่า
ไม่มี TTL เดียวเหมาะกับทุกข้อมูล
ถ้า Google Search Tool เกิด Error
Application ควรกำหนดว่าจะ
ตาม Requirement
ไม่ควรเงียบแล้วทำเหมือนข้อมูลยังเป็น Real-time
ถ้า Application บอก
ข้อมูลล่าสุดวันนี้
แต่ Search Tool Fail แล้วระบบใช้ Model Knowledge แทนโดยไม่แจ้ง
อาจทำให้ User เข้าใจผิด
ควรให้ Application รู้ว่า
Search Used?
Search Failed?
จาก Interaction Steps
ดูว่า interaction.steps มี
google_search_call
หรือไม่
Python
used_search = any(
step.type == "google_search_call"
for step in interaction.steps
)
print("Used Google Search:", used_search)
มีประโยชน์กับ Application ที่ต้องการรับประกันว่า Answer บางประเภทผ่าน Search
แทนการเชื่อเพียงว่ามี Tool Available
Application สามารถ
google_search_callเหมาะกับระบบที่ Requirement ระบุชัดว่า
ข้อมูลต้องมาจากเว็บปัจจุบัน
ถ้าต้องการข้อมูล
Order 12345
ของระบบตัวเอง
ใช้ Function Calling
ไม่ใช่ Google Search
ถ้าต้องการ
ราคาตลาดของสินค้า
อาจใช้ Google Search
Agent ที่ดีเลือก Data Source ให้ตรงกับข้อมูล
| ต้องการข้อมูล | Tool ที่เหมาะ |
|---|---|
| ข่าวล่าสุด | Google Search |
| ข้อมูลเว็บทั่วไป | Google Search |
| หน้าเว็บที่กำหนด | URL Context |
| สถานที่/ร้าน | Google Maps |
| ข้อมูลใน Database | Function Calling |
| ไฟล์ภายใน | File Search / File Input |
| คำนวณ | Code Execution |
| Action ในระบบ | Function Calling |
การเลือก Tool ถูกช่วยทั้ง Accuracy และ Cost
โมเดลปัจจุบันที่รองรับมีหลายรุ่น เช่น
Gemini 3.7 Flash
Gemini 3.6 Flash
Gemini 3.5 Flash
Gemini 3.5 Flash-Lite
Gemini 3.1 Pro Preview
Gemini 2.5 Pro
Gemini 2.5 Flash
Gemini 2.5 Flash-Lite
และรุ่นอื่นตาม Model Capability
สำหรับ Project ใหม่ควรตรวจ Model List ปัจจุบันก่อนเลือก
google_search_retrieval กับ Model ใหม่Tutorial เก่าอาจใช้ Tool
google_search_retrieval
Google ระบุว่ารุ่นเก่าเคยใช้ชื่อดังกล่าว
แต่สำหรับ Model ปัจจุบันควรใช้
google_search
ดังนั้น Code ใหม่
{
"type": "google_search"
}
เป็นรูปแบบที่ควรใช้
หาก Tutorial ใช้
google_search_retrievalCode อาจไม่ตรงกับ Interactions API ปัจจุบัน
ควรตรวจ
SDK
Model ID
Tool Type
Response Structure
ทุกครั้ง
ถ้า Search Request คืน
400
ตรวจ
โดยเฉพาะเมื่อ Copy Code เก่า
ตรวจ
ตาม Error Message
Search-enabled Request ยังอยู่ภายใต้ Rate Limit ของ Gemini API
และยังมี Usage ของ Search Tool
ถ้า Traffic สูงอาจชน
RPM
TPM
Spend Rate
ตาม Project
ควรใช้
เหมือน Gemini API Request อื่น
หาก Error ชั่วคราว ใช้
Exponential Backoff
+
Maximum Attempts
ไม่ควร Retry แบบไม่มี Limit
เพราะ Request ที่ Retry อาจสร้าง Search Query และ Usage เพิ่มในสถานการณ์ที่ Request ทำงานบางส่วนแล้ว
Application ต้องออกแบบ Retry ตาม Error Type
อย่าวัดเพียงว่า
มี Citation หรือไม่
ควรวัด
ข้อมูลถูกหรือไม่
ข้อมูลล่าสุดจริงหรือไม่
Source สนับสนุน Claim หรือไม่
แหล่งข้อมูลน่าเชื่อถือหรือไม่
ช้าแค่ไหน
กี่ Query ต่อ Task
นี่เป็น Evaluation ที่เหมาะกับ Search Application
ข้อมูลวันนี้
ไม่ควร Search เกินจำเป็น
ต้องตีความ
มีข้อมูลไม่ตรงกัน
ภาษาไทย
ภาษาอังกฤษ
ทดสอบว่า Model ไม่ Search เกินจำเป็น
Google Search Grounding รองรับภาษาที่ Gemini รองรับ จึงเหมาะกับ Application หลายภาษา
ได้
เช่น
interaction = client.interactions.create(
model="gemini-3.7-flash",
input=(
"ค้นหาข่าวเทคโนโลยีล่าสุด "
"และสรุปเป็นภาษาไทย 5 ข้อ"
),
tools=[
{
"type": "google_search",
}
],
)
ไม่จำเป็นต้องแปล Prompt เป็นอังกฤษก่อน
Gemini สามารถสร้าง Search Workflow ตามคำถามภาษาไทยได้
ระบุ Requirement ใน Prompt เช่น
ค้นหาข้อมูลจากแหล่งต่างประเทศด้วย
และสรุปเป็นภาษาไทย
หรือ
ให้ความสำคัญกับข้อมูลจากแหล่งทางการ
เมื่อมีแหล่งดังกล่าว
แต่ Application ยังควรตรวจ Citation จริง ไม่ใช่เชื่อ Prompt อย่างเดียว
สำหรับข้อมูล เช่น
Prompt สามารถระบุ
ให้ตรวจแหล่งข้อมูลทางการก่อน
และใช้แหล่งข่าวอื่นเพื่อยืนยันเมื่อจำเป็น
ช่วยให้ Workflow มุ่งหา Source ที่มี Authority มากขึ้น
ไม่ควรสร้าง Feature ที่พยายามค้นหา
บนเว็บ
Search Tool ควรใช้กับข้อมูลสาธารณะที่เหมาะสมกับ Use Case และนโยบายของ Application
ตัวอย่าง
Answer
แหล่งอ้างอิง:
• Source A
• Source B
• Source C
หรือ Inline Citation
บริษัทประกาศผลิตภัณฑ์ใหม่ [1]
เมื่อ User กด Citation ควรเข้าถึง Source ที่ API คืนตามข้อกำหนดที่เกี่ยวข้อง
หาก Backend รับ
Answer
+
Citations
แล้ว Frontend แสดงเพียง Answer
Application จะเสียจุดเด่นสำคัญของ Search Grounding
สำหรับ Research หรือ News Product ควรเก็บ Citation Data ไปถึง UI
Backend ของเราอาจแปลง Response เป็น
{
"answer": "...",
"used_search": true,
"sources": [
{
"title": "...",
"url": "..."
}
]
}
จากนั้น Frontend ไม่จำเป็นต้องรู้ Structure ภายในทั้งหมดของ Gemini API
ช่วยแยก External API Contract ออกจาก Internal App Contract
Project ใหญ่ควรมี
Application
↓
SearchService
↓
Gemini API
SearchService จัดการ
ไม่ควรเขียน Search Parsing ซ้ำในทุก Endpoint
from google import genai
client = genai.Client()
def search_with_gemini(
question: str,
) -> str:
interaction = (
client.interactions.create(
model="gemini-3.7-flash",
input=question,
tools=[
{
"type":
"google_search",
}
],
)
)
return interaction.output_text
ต่อไปสามารถขยาย Function ให้คืน Citation ด้วย
Public Search Endpoint ควรตรวจ
ตัวอย่าง
if not question.strip():
raise ValueError(
"Question is required"
)
ไม่ควรส่ง Request ที่ไม่มีประโยชน์ไปสร้าง Search Usage
ถ้าต้องการ News Brief
Prompt ควรบอก
สรุป 5 ข้อ
แต่ละข้อไม่เกิน 2 ประโยค
แทน
อธิบายทุกอย่างอย่างละเอียดที่สุด
หาก Business Requirement ไม่ต้องการคำตอบยาว
ช่วยลด Output Token
ระบบที่ Cost-sensitive สามารถตั้ง Internal Policy เช่น
Search-heavy task
→ Allowed
Simple task
→ Search disabled
หรือแยก Product Tier
Free
→ Search จำกัด
Pro
→ Search มากขึ้น
ตาม Business Model
ตัวอย่าง Metrics
Most searched topics
Queries per interaction
Average citations
Search failure rate
Cost per successful answer
ช่วยรู้ว่า User ใช้ Search Feature กับอะไรจริง
และควรลงทุน Optimize ตรงไหน
เพิ่ม Cost/Latency โดยไม่จำเป็น
google_search_retrieval กับ Model ใหม่ควรใช้ google_search
เสียประโยชน์ของ Grounding
ควรใช้ annotations
หนึ่ง Prompt อาจสร้างหลาย Query
ต้องดู Query Count
Citation ไม่ได้แปลว่าถูกเสมอ
ข่าวใหม่อาจพูดถึงเหตุการณ์เก่า
ควรใช้ Function Calling
เสี่ยง Prompt Injection
Search Tool มีค่าใช้จ่ายของตัวเอง
คำตอบอาจไม่ได้ Grounded
Tool/API Structure อาจเปลี่ยน
เสี่ยง Abuse
User ไม่รู้ว่า Search ล้มเหลว
เก็บ Server-side
Python google-genai หรือ JavaScript @google/genai
เชื่อม Gemini API
เช่น gemini-3.7-flash
{
"type": "google_search"
}
เน้นข้อมูลที่ต้องการ
output_textรับ Final Answer
google_search_callดูว่า Search ถูกใช้หรือไม่
annotationsดึง Citation
ให้ User ตรวจ Source
ควบคุม Cost
ป้องกัน Abuse
ตรวจ Accuracy และ Freshness
เช่น URL Context หรือ Function Calling
สำหรับระบบค้นข้อมูลของ comsiam การเก็บทั้ง Answer และ Citation Metadata ตั้งแต่ Backend จะทำให้สามารถสร้าง Search Experience ที่ตรวจสอบแหล่งข้อมูลได้ดีกว่าการเก็บเฉพาะข้อความจาก output_text
google_searchหากครบชุดนี้ Application จะพร้อมกว่าเพียงเปิด Tool แล้วนำคำตอบไปแสดงทันที
ค้นหาข่าว AI ล่าสุด
สรุป 5 เหตุการณ์สำคัญ
ระบุวันที่เกิดเหตุการณ์เมื่อหาได้
และใช้ข้อมูลที่ตรวจสอบได้
ค้นหาข้อมูลล่าสุดของสินค้านี้
สรุปสเปก ราคาโดยประมาณ
และการเปลี่ยนแปลงจากรุ่นก่อน
ค้นหาข่าวล่าสุดของบริษัทนี้
สรุป Product, Business
และเหตุการณ์สำคัญในช่วงล่าสุด
ตรวจสอบข้อความนี้จากข้อมูลเว็บปัจจุบัน
ถ้าแหล่งข้อมูลขัดแย้งกัน
ให้บอกทั้งสองฝ่าย
ค้นข้อมูลหัวข้อนี้จากหลายแหล่ง
สรุปข้อเท็จจริงหลัก
และแยกสิ่งที่ยังไม่สามารถยืนยันได้
ได้ โดยเปิด Tool google_search ใน Gemini API Request โมเดลจะสามารถสร้าง Search Query ค้นเว็บ ประมวลผลข้อมูล และสร้าง Grounded Response พร้อม Citation
เพิ่ม tools=[{"type": "google_search"}] ใน client.interactions.create() แล้วอ่านคำตอบจาก interaction.output_text
ได้ เมื่อเปิด Google Search Tool โมเดลจะวิเคราะห์ Prompt และสามารถสร้างหนึ่งหรือหลาย Search Queries โดยอัตโนมัติตามความจำเป็น
ได้ Citation ปัจจุบันอยู่ใน annotations ของ Text Content Block โดย url_citation มีข้อมูล เช่น URL, Title, start_index และ end_index
สำหรับ Gemini 3.x Paid Tier Pricing ปัจจุบันมี Search Allowance 5,000 Requests ต่อเดือนแบบแชร์ระหว่าง Gemini 3.x Models ที่เกี่ยวข้อง จากนั้นคิด $14 ต่อ 1,000 Search Requests และหนึ่ง User Prompt สามารถสร้าง Search Query มากกว่าหนึ่งรายการได้
google_search หรือ google_search_retrievalสำหรับ Model ปัจจุบัน Google ระบุให้ใช้ google_search ส่วน google_search_retrieval เป็นรูปแบบของโมเดลรุ่นเก่า
วิธีเชื่อม Gemini API กับ Google Search ในปัจจุบันทำได้ง่ายโดยเพิ่ม Tool {"type": "google_search"} เข้า Gemini API Request ผ่าน Interactions API จากนั้น Gemini จะจัดการตั้งแต่การวิเคราะห์ Prompt, สร้าง Search Query, ค้น Google, ประมวลผลข้อมูล และสร้างคำตอบที่ Grounded จากข้อมูลเว็บ
gemini-3.7-flash เป็นหนึ่งใน Stable Model ปัจจุบันที่รองรับ Google Search และใช้งานได้ผ่าน Python SDK google-genai, JavaScript SDK @google/genai รวมถึง REST API
นอกจาก output_text แล้ว Developer ควรอ่าน interaction.steps เพราะจะมี google_search_call, google_search_result และ model_output ซึ่งช่วยให้ตรวจได้ว่า Gemini Search อะไรและได้ Citation ใดกลับมา
Citation สำคัญมากสำหรับ Search Application โดย url_citation สามารถระบุ Source URL และช่วงของข้อความที่ Source สนับสนุน ทำให้สร้าง Inline Citation หรือ Source List ใน Frontend ได้
สำหรับ Gemini 3.x ค่า Search ปัจจุบันคิดตาม Search Query ที่ Gemini Execute ไม่ใช่จำนวน User Prompt ดังนั้นหนึ่ง Prompt ที่สร้างหลาย Queries สามารถเกิด Tool Usage หลายครั้งได้ จึงควรเก็บ Search Query Count และ Cost ต่อ Successful Answer
ไม่ควรเปิด Search ทุก Request โดยอัตโนมัติถ้างานไม่ต้องการข้อมูลสด เพราะจะเพิ่มทั้ง Latency และ Cost และไม่ควรใช้ Google Search แทน Private Database หรือ Internal API ซึ่ง Function Calling หรือ Retrieval เหมาะกว่า
แนวทางของ comsiam คือใช้ Google Search Grounding เฉพาะ Search Intent ที่ต้องการข้อมูลปัจจุบัน พร้อมเก็บ Citation, Query Count, Latency และ Cost แยกจาก Gemini Text Generation เพื่อให้สามารถควบคุมทั้งความน่าเชื่อถือและต้นทุนของระบบได้ในระยะยาว