คำตอบสั้น
LLMWebSearch API ส่งอะไรกลับมาสำหรับการค้นหา
LLMWebSearch ส่ง JSON กลับมาพร้อม query, created_at, credits_used และอาร์เรย์ results ที่จัดอันดับแล้ว แต่ละผลลัพธ์มีตำแหน่ง ชื่อเรื่อง URL โฮสต์ และ snippet และมี content_status; เมื่อเป็น ok เนื้อหาหลักของหน้าจะอยู่ใน content พร้อม word_count การค้นหาหนึ่งครั้งที่อ่านได้สูงสุด 3 หน้า คิด 1 เครดิต เริ่มที่ US$1.20/1K การค้นหา ณ เดือนตุลาคม 2026 ไม่ต้อง KYC; จ่ายด้วยคริปโต
ฟิลด์ใดอธิบายการเรียก
ระดับบนสุดของ response /search
| Field | Type | ความหมาย |
|---|---|---|
query | string | คำค้นหาตามที่เราใช้ค้น หลังตัดช่องว่าง |
created_at | string | เวลาที่การค้นหาเกิดขึ้น ISO 8601 ใน UTC |
credits_used | integer | ค่าใช้จ่ายของการเรียก: 1 หรือ 2 เมื่อ read เป็น 4 ถึง 10 |
results | array | ผลลัพธ์ที่จัดอันดับแล้ว ดีที่สุดก่อน สูงสุด max_results รายการ |
แต่ละผลลัพธ์มีฟิลด์ใดบ้าง
ฟิลด์ที่หน้าเว็บหรือผลการค้นหาไม่ได้ให้มาจะถูกตัดออกไปแทนที่จะส่งเป็นค่าว่าง
| Field | Type | เมื่อมี | ความหมาย |
|---|---|---|---|
position | integer | เสมอ | อันดับในการค้นหา เริ่มที่ 1 |
title | string | เสมอ | ชื่อเรื่องของผลลัพธ์ |
url | string | เสมอ | ที่อยู่ของหน้า |
host | string | เสมอ | ชื่อโฮสต์ของหน้า สะดวกสำหรับการจัดกลุ่มหรืออ้างอิง |
snippet | string | เสมอ | ข้อความสั้นที่แสดงโดยการค้นหา |
published_at | string | เมื่อทราบวันที่ | วันที่เผยแพร่จากหน้าเว็บหรือผลการค้นหา |
content_status | string | เสมอ | ระบุว่าอ่านหน้าเว็บแล้วหรือไม่ และถ้าไม่อ่านเพราะอะไร |
content | string | เมื่อ content_status คือ ok | เนื้อหาหลักเป็น Markdown หรือ plain text ตัดที่ max_chars |
word_count | integer | เมื่อ content_status คือ ok | จำนวนคำในข้อความที่ดึงมาทั้งหมด นับก่อนการตัด |
target_status | integer | ด้วย target_refused | HTTP status ที่ไซต์ตอบกลับ เช่น 403 หรือ 429 |
content_status แต่ละค่าหมายถึงอะไร?
ไม่มีสิ่งใดในนี้เปลี่ยนราคาของการค้นหา สิ่งเหล่านี้บรรยายหน้าเว็บหนึ่งหน้า ไม่ใช่ทั้งการเรียก
content_status | ความหมาย | สิ่งที่ agent ควรทำ |
|---|---|---|
ok | อ่านหน้าเว็บแล้ว content เก็บข้อความหลักไว้ | ใช้มันและอ้างอิง url |
not_requested | ผลลัพธ์เกินจำนวน read | เพิ่ม read หรืออ่านผ่าน /extract หากจำเป็น |
blocked_by_robots | robots.txt ของไซต์ไม่อนุญาตให้ reader ของเราอ่านหน้านี้ | ใช้ snippet หรือแหล่งอื่น |
blocked_by_site_policy | ไซต์ประกาศ Content-Signal: ai-input=no | ใช้ snippet หรือแหล่งอื่น |
target_refused | ไซต์ปฏิเสธคำขอ ดู target_status | อย่าลองหน้าเว็บซ้ำ ใช้แหล่งอื่น |
fetch_failed | ข้อผิดพลาด DNS, TLS หรือการเชื่อมต่อ หรือหน้าเว็บหายไปแล้ว | ลองผลลัพธ์อื่น การลองใหม่ภายหลังอาจได้ผล |
fetch_timeout | หน้าเว็บไม่ตอบกลับภายใน 15 วินาที | ลองผลลัพธ์อื่น การลองใหม่ภายหลังอาจได้ผล |
unsupported_content | ลิงก์เป็นไฟล์ที่เราแปลงเป็นข้อความไม่ได้ | ใช้ snippet หรือผลลัพธ์อื่น |
response แบบเต็มหน้าตาเป็นอย่างไร?
ตัวอย่างด้านล่างขอผลลัพธ์ 5 รายการ โดยอ่าน 4 รายการแรก จึงเสีย 2 เครดิต ผลลัพธ์ที่ 1 และ 3 ถูกอ่านแล้ว ผลลัพธ์ที่ 2 อยู่ในไซต์ที่ robots.txt กัน reader ของเราไว้นอก ผลลัพธ์ที่ 4 ปฏิเสธคำขอ และผลลัพธ์ที่ 5 อยู่เกิน read ชื่อเรื่อง URL และค่าต่างๆ เป็นเพียงตัวอย่าง
{
"query": "how to rotate api keys without downtime",
"created_at": "2026-10-22T10:15:04Z",
"credits_used": 2,
"results": [
{
"position": 1,
"title": "Rotating API keys",
"url": "https://docs.example.com/security/key-rotation",
"host": "docs.example.com",
"snippet": "Create a second key, deploy it everywhere, then revoke the first one.",
"published_at": "2026-09-30",
"content_status": "ok",
"content": "# Rotating API keys\n\n## Zero-downtime rotation\n\n1. Create a second key.\n2. Deploy it to every service.\n3. Revoke the old key.",
"word_count": 948
},
{
"position": 2,
"title": "Key rotation checklist",
"url": "https://blog.example.org/key-rotation-checklist",
"host": "blog.example.org",
"snippet": "Keep two keys active during the switch and alert on the old one.",
"content_status": "blocked_by_robots"
},
{
"position": 3,
"title": "Secrets management basics",
"url": "https://security.example.net/secrets-basics",
"host": "security.example.net",
"snippet": "Never commit keys to a repository.",
"content_status": "ok",
"content": "# Secrets management basics\n\n**Never** commit keys to a repository.",
"word_count": 1310
},
{
"position": 4,
"title": "Key management service guide",
"url": "https://cloud.example.com/kms-guide",
"host": "cloud.example.com",
"snippet": "Store keys in a managed vault and rotate them on a schedule.",
"content_status": "target_refused",
"target_status": 403
},
{
"position": 5,
"title": "API key best practices",
"url": "https://dev.example.com/api-key-best-practices",
"host": "dev.example.com",
"snippet": "Scope each key to one service and one environment.",
"content_status": "not_requested"
}
]
}ผลลัพธ์ใดได้รับสถานะหน้าเว็บที่ไม่ใช่ not_requested?
เฉพาะ read ผลลัพธ์แรก และทุกรายการของการเรียก /extract เท่านั้น สิ่งเหล่านี้คือหน้าที่เครื่องอ่านของเราพยายามดึงจริง ทุกอย่างหลังจากจำนวน read จะคงเป็น not_requested ไม่ว่าเว็บไซต์จะตอบอะไรก็ตาม
ลำดับไม่เคยเปลี่ยน: เครื่องอ่านทำงานที่ตำแหน่ง 1, 2, 3 ไปเรื่อย ๆ ไม่เคยทำงานกับผลลัพธ์ที่อยู่ถัดไปแทนผลลัพธ์ก่อนหน้าที่ล้มเหลว ถ้าเอเจนต์ต้องการผลลัพธ์แทนหน้าทีถูกปฏิเสธ ก็อ่านผลลัพธ์ถัดไปได้ผ่าน /extract
การตอบกลับของ extract หน้าตาเป็นอย่างไร?
/extract ส่งคืน credits_used และอาร์เรย์ results ตามลำดับ URL ที่คุณส่งไป แต่ละรายการมี url และ content_status เมื่อใช้ ok จะเพิ่ม title, content และ word_count และเมื่อใช้ target_refused จะเพิ่ม target_status จะไม่มี position, host หรือ snippet เพราะไม่มีการค้นหาเกิดขึ้น
เอกสารอ้างอิง extract แสดงตัวอย่างที่สมบูรณ์และอธิบายวิธีนับเครดิต
ฉันจะแปลงผลลัพธ์เป็นบริบทสำหรับโมเดลได้อย่างไร?
ใส่หมายเลขกำกับแต่ละแหล่งข้อมูล เก็บ URL ไว้ข้าง ๆ และส่งเฉพาะสิ่งที่โมเดลต้องการ รูปแบบที่กระชับทำงานได้ดี: [1] title — url ตามด้วยเนื้อหาของหน้านั้น แล้วจึงแหล่งข้อมูลถัดไป ขอให้โมเดลอ้างอิงด้วยหมายเลขเดียวกัน
เมื่อผลลัพธ์ใดไม่มีเนื้อหา ให้ส่ง snippet ของผลลัพธ์นั้นให้โมเดลแทน และระบุว่าเป็นเพียง snippet เท่านั้น วิธีนี้ช่วยหลีกเลี่ยงคำตอบที่สร้างจากหน้าที่โมเดลไม่เคยเห็น หน้า Python มีลูปสั้น ๆ ที่ทำทั้งหมดนี้ภายใต้งบโทเคน
รูปแบบการตอบกลับ: คำถามที่พบบ่อย
เนื้อหาเป็น Markdown เสมอหรือไม่?
ค่าเริ่มต้นคือ Markdown ส่ง format: "text" เพื่อรับข้อความธรรมดาที่ไม่มี markup เช่น เมื่อคุณต้องการนับคำหรือจำแนกหน้าเว็บเท่านั้น ชื่อฟิลด์ยังคงเป็น content
ทำไมบางผลลัพธ์จึงไม่มี published_at?
หลายหน้าไม่ระบุวันที่ และผลการค้นหาบางรายการก็ไม่แสดงวันที่เช่นกัน ในกรณีนั้นฟิลด์จะถูกomit ไป จึงควรตรวจสอบว่ามีฟิลด์นี้ก่อนใช้งาน
ฟิลด์ใหม่สามารถเกิดขึ้นได้ในภายหลังหรือไม่?
ได้ ในเวอร์ชัน 1 ฟิลด์อาจถูกเพิ่มได้ แต่จะไม่ถูกเปลี่ยนชื่อหรือลบออก เขียน parser ของคุณให้ไม่สนใจฟิลด์ที่ไม่รู้จัก
เนื้อหาถูกจัดเก็บไว้ฝั่งคุณหรือไม่?
ไม่ เราไม่ฝึกโมเดลใดๆ ด้วยคำค้นหาของคุณหรือข้อมูลที่ API ส่งกลับ และเราไม่เพิ่มกฎของเราเองต่อต้านการจัดเก็บผลลัพธ์; สิทธิ์ของเว็บไซต์ที่คุณอ่านหน้ายังคงมีผล บันทึกคำขอของเราเก็บเพียงร่องรอยสั้น ๆ ของแต่ละการเรียก ซึ่งอธิบายไว้ในหน้าความเป็นส่วนตัว