Gemini Decision กับ Gemini Decision 1: อันหนึ่งเป็นชื่อ อีกอันเป็น ID ของโมเดล

ค้นหา Gemini Decision แล้วคุณจะพบกับการรายงานข่าวการเปิดตัว รายการบนลีดเดอร์บอร์ด แถวราคา และเอกสารอ้างอิง API ซึ่งทั้งหมดใช้ถ้อยคำต่างกันเล็กน้อยสำหรับสิ่งเดียวกัน ค้นหา Gemini Decision 1 แล้วคุณจะพบกับ id ของโมเดลที่ใช้งานได้จริง สองสตริงนี้ต่างกันเพียงอักขระเดียวแต่ทำงานแตกต่างกันโดยสิ้นเชิงในโค้ด: อันหนึ่งคือสิ่งที่ผู้คนเรียกผลิตภัณฑ์ และอีกอันคือค่าเดียวที่ POST /v1beta/decisions จะยอมรับ หากคุณเคยเสียเวลาทั้งบ่ายไปกับ 404 โดยสงสัยว่าเหตุใดโมเดลที่มีอยู่จริงกลับหาไม่พบ นี่คือบทความที่คงช่วยคุณไว้ได้

The confusion is not anyone's mistake in particular. G​oogle shipped a model, an endpoint and a family name in the same release on 11 November 2026, and the natural way to write about all three is to shorten them. The shortening works in prose and fails in a request body, and the gap between those two facts is where most of the support tickets in this category will come from over the next month.

สิ่งที่ชื่อทั้งสองนี้ชี้ไป

เริ่มต้นด้วยการแมป เพราะทุกสิ่งอื่นล้วนตามมาจากมัน

• Gemini Decision — a product name. It refers to the decision-model line, and in G​oogle's own documentation it appears as the family label in prose, in the model card heading, and in sentences like "available with G​emini Decision only". It is not a model id, there is no alias behind it, and passing it as model returns an unknown-model error rather than falling back to the newest member of the family.

• Gemini Decision 1 — the model, and the id gemini-decision-1. This is the value that works. It is the only model the Decisions API serves, and the documentation says so explicitly: the endpoint is available with G​emini Decision 1 only.

Two names, one model, and no alias between them. That last part is the unusual bit. Most G​oogle model families offer a moving alias and a pinned id — a -latest form for prototypes and a dated or numbered form for production. This one offers only the pinned form, so any code path built on the assumption that families have a floating head will fail here rather than silently tracking a new version.

ที่ซึ่งชื่อที่สองยังคงปรากฏขึ้นเรื่อย ๆ

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

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

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

วิธีตรวจสอบว่าคีย์ที่กำหนดสามารถเรียกใช้อะไรได้จริง

ก่อนจะเขียนคำขอ ให้แสดงรายการโมเดลที่คีย์นั้นมีสิทธิ์เข้าถึง การเรียก list-models มาตรฐานบน Generative Language API จะส่งคืนโมเดลที่พร้อมใช้งานสำหรับโปรเจกต์ของคุณพร้อมกับไอดีของโมเดลเหล่านั้น และการเรียกเพียงครั้งเดียวก็จะตอบคำถามนี้ได้อย่างถาวรสำหรับคีย์นั้น

หาก gemini-decision-1 ปรากฏอยู่ แสดงว่าคุณมีสิทธิ์เข้าถึง และสตริงนั้นแบบตรงตัวคือสิ่งที่ต้องใส่ในคำขอ หากไม่มี ปัญหาจะอยู่ที่สิทธิ์การเข้าถึงหรือภูมิภาค ไม่ใช่การสะกด และการเปลี่ยนชื่อไม่ว่าจะมากเพียงใดก็ไม่ช่วยอะไร สิ่งที่คุณจะไม่พบในรายการนั้นคือรายการที่ชื่อ gemini-decision เพราะไม่มีโมเดลดังกล่าว

การตรวจสอบครั้งที่สองอยู่ที่การตอบสนอง การตอบสนองการตัดสินใจที่สำเร็จจะระบุโมเดลที่ให้บริการคำตอบนั้น ดังนั้นไปป์ไลน์ที่บันทึกฟิลด์โมเดลควบคู่กับ request id ของตัวเองจึงสามารถตอบได้ว่า “โมเดลใดสร้างคำตอบนี้” ในอีกหลายเดือนถัดมาโดยไม่ต้องอ่านการกำหนดค่าใหม่ ฟังดูเหมือนงานธุรการจนกระทั่งครั้งแรกที่มีคนถามว่าทำไมการตัดสินใจจึงเปลี่ยน และคำตอบที่ตรงไปตรงมาคือ alias ถูกย้าย

ข้อผิดพลาดทั้งสามที่ความกำกวมนี้ก่อให้เกิดขึ้นจริง

• 404 ของโมเดลที่ไม่รู้จัก อันที่เห็นได้ชัดเจน คือ gemini-decision ใน request body ส่งคืนข้อผิดพลาดที่อ่านแล้วเหมือนปัญหาเรื่องสิทธิ์ แต่กลับไม่ใช่ หากข้อผิดพลาดกล่าวถึงโมเดลแทนโปรเจกต์ ให้ตรวจสอบสตริงก่อนตรวจสอบบัญชีการเรียกเก็บเงิน

• สมมติฐานเรื่อง alias แบบเงียบ ๆจับได้ยากกว่า ทีมที่ซึมซับธรรมเนียม -latest ไว้แล้วจะเขียนคอนฟิกด้วยชื่อตระกูลและขั้นตอนการ resolve และขั้นตอนการ resolve นั้นก็คืนค่าชื่อตระกูลตามตัวอักษรอย่างเงียบ ๆ เมื่อไม่มี alias อยู่ ความล้มเหลวจึงปรากฏขึ้นที่คำขอจริงครั้งแรกแทนที่จะปรากฏตอน deploy ซึ่งเป็นเวลาที่แย่ที่สุดเท่าที่จะเป็นไปได้

• สมมติฐานเรื่องปลายทางที่ไม่ถูกต้อง ละเอียดอ่อนยิ่งกว่านั้นอีก เพราะโมเดลมีอยู่จริงและชื่อก็ถูกต้อง: การส่ง gemini-decision-1 ไปยังปลายทาง generate-content ทั่วไปก็ยังล้มเหลว โมเดลนี้ไม่สามารถเรียกใช้ด้วยวิธีนั้นได้เลย มันเป็นเป้าหมายที่ให้เฉพาะค่าความน่าจะเป็นบนปลายทาง decisions และคำขอที่ขอให้มันสร้างข้อความร้อยแก้วก็กำลังขอสิ่งที่มันไม่ได้ผลิต ไลบรารีไคลเอนต์ใดก็ตามที่ใช้ค่าเริ่มต้นเป็น chat completions จะต้องระบุพาธอย่างชัดเจน

สิ่งที่สิ่งนี้บ่งบอกเกี่ยวกับโมเดล ไม่ใช่แค่ชื่อของมัน

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

นั่นคือเหตุผลที่ตระกูลนี้ยังไม่มี alias แบบลอยตัวและยังไม่มีสมาชิกตัวที่สอง: ยังไม่มีอะไรให้เข้ากันได้ นอกจากนี้ยังอธิบายว่าทำไมโมเดลนี้จึงไม่สามารถเพิ่มเข้าไปในเราเตอร์อเนกประสงค์ได้โดยตรง OrcaRouter ไม่มี gemini-decision-1 เพราะปลายทางที่ให้เฉพาะความน่าจะเป็นไม่ใช่เป้าหมายแบบ chat-completions และการวางมันไว้เบื้องหลังคีย์ที่พูดสคีมานั้นจะเป็นคำสัญญาที่ชั้นการกำหนดเส้นทางไม่สามารถรักษาได้ สิ่งที่เรามีอยู่ในพื้นที่การตัดสินใจคือ typesafe/jev-1.14 ของ TypeSafe ซึ่งเป็นโมเดลการตัดสินใจที่เรียกใช้ได้ผ่านอินเทอร์เฟซเดียวกับทุกสิ่งอื่นในแคตตาล็อก

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

หากคุณกำลังเลือกระหว่างสตริงทั้งสองบนแบบฟอร์ม

There is a version of this question that is not about identifiers at all, and it is worth answering directly because the phrasing invites it: someone comparing "G​emini Decision" with "G​emini Decision 1" may believe they are looking at two products, an older one and a newer one, and want to know which to adopt. There is only one. Nothing called G​emini Decision shipped before G​emini Decision 1, and the shorter name is the family label for a family that currently has a single member.

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

ประเด็นสำคัญ

Use gemini-decision-1 in every request body, endpoint path and config value, and use "G​emini Decision" only where a human reads it. There is no alias to fall back on, no second model hiding behind the shorter name, and no chat-completions path to the longer one. The cost of getting this wrong is small — one 404, one confused afternoon — but the cost of assuming an alias exists is larger, because that mistake survives review and fails in production. Pin the id, log the model the response names, and treat the family name as prose.