Gemini Decision vs Gemini Decision 1: Jedno to nazwa, drugie to identyfikator modelu

Wyszukaj Gemini Decision a znajdziesz relacje z premiery, wpis w rankingu, wiersz cennika i dokumentację API — wszystkie opisują to samo nieco innymi słowami. Wyszukaj Gemini Decision 1 a znajdziesz identyfikator modelu, który faktycznie działa. Te dwa ciągi różnią się jednym znakiem i zachowują się w kodzie zupełnie inaczej: jeden to określenie, którego ludzie używają dla produktu, a drugi to jedyna wartość, którą zaakceptuje POST /v1beta/decisions. Jeśli spędziłeś popołudnie na 404, zastanawiając się, dlaczego nie można znaleźć modelu, który przecież istnieje, to jest artykuł, który by ci to oszczędził.

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.

Na co wskazują te dwie nazwy

Zacznij od mapowania, ponieważ wszystko inne z niego wynika.

• 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 — model oraz identyfikator gemini-decision-1. To jest wartość, która działa. Jest to jedyny model udostępniany przez Decisions API i dokumentacja mówi o tym wprost: endpoint jest dostępny wyłącznie z G​emini Decision 1.

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.

Gdzie ciągle pojawia się drugie imię

To, że ta niejednoznaczność ma się dobrze, wynika z faktu, że trzy odrębne systemy opisują ten model, a żaden z nich nie stosuje tej samej konwencji nazewnictwa.

Strona z cennikiem wymienia go pod nazwą własną modelu, wraz ze stawką i uwagą, że wynik nie ma zastosowania. Dokumentacja API opisuje endpoint i podaje nazwę modelu w zdaniu o dostępności, a nie w tabeli modeli. Niezależny ranking, który go benchmarkuje, używa czytelnej nazwy w swoim wierszu i na swoim wykresie. Żadne z nich nie jest błędne i żadne nie jest identyfikatorem modelu, więc skopiowanie któregokolwiek z nich do treści żądania daje ten sam błąd.

Istnieje czwarte źródło zmienności, które z upływem czasu będzie miało coraz większe znaczenie: teksty innych osób. Materiały z premiery, samouczki i odpowiedzi na forach skracają nazwę, a niektóre skracają ją do czegoś, co wygląda jak identyfikator — pisane małymi literami, z łącznikami, wiarygodne. Rozwiązaniem nie jest ufanie któremukolwiek z nich. Zapytaj punkt końcowy.

Jak sprawdzić, co dany klucz może faktycznie wywoływać

Przed napisaniem żądania wylistuj modele, do których klucz ma uprawnienia. Standardowe wywołanie list-models w Generative Language API zwraca modele dostępne dla Twojego projektu wraz z ich identyfikatorami, a jednorazowe uruchomienie go na stałe rozstrzyga tę kwestię dla tego klucza.

Jeśli pojawi się gemini-decision-1, masz dostęp, a właśnie ten dokładny ciąg znaków trafia do żądania. Jeśli się nie pojawi, problem leży w uprawnieniach lub regionie, a nie w pisowni, i żadna zmiana nazwy nie pomoże. Na tej liście nie znajdziesz wpisu o nazwie gemini-decision, ponieważ nie ma takiego modelu.

Druga kontrola dotyczy odpowiedzi. Pomyślna odpowiedź decyzyjna wskazuje model, który ją obsłużył, więc potok, który zapisuje w logach pole modelu razem z własnym identyfikatorem żądania, może po miesiącach odpowiedzieć na pytanie „który model wytworzył tę odpowiedź”, nie odczytując ponownie konfiguracji. Brzmi to jak porządki, dopóki ktoś po raz pierwszy nie zapyta, dlaczego decyzja się zmieniła, a uczciwą odpowiedzią nie okaże się, że alias został przeniesiony.

Trzy błędy, które ta niejednoznaczność faktycznie powoduje

• 404 nieznanego modelu. Ten oczywisty. gemini-decision w treści żądania zwraca błąd, który wygląda jak problem z uprawnieniami, choć nim nie jest. Jeśli błąd odnosi się do modelu, a nie do projektu, sprawdź ten ciąg, zanim sprawdzisz konto rozliczeniowe.

• Ciche założenie o aliasie. Trudniejsze do wychwycenia. Zespół, który przyswoił sobie konwencje „-latest”, pisze konfigurację z nazwą rodziny i krokiem rozwiązywania, a krok rozwiązywania po cichu zwraca dosłowną nazwę rodziny, gdy alias nie istnieje. Awaria ujawnia się wtedy przy pierwszym rzeczywistym żądaniu, a nie podczas wdrażania, co jest najgorszym możliwym momentem.

• Błędne założenie dotyczące punktu końcowego. Jeszcze subtelniejsze, ponieważ model istnieje, a nazwa jest prawidłowa: gemini-decision-1 wysłany do zwykłego punktu końcowego generate-content nadal kończy się niepowodzeniem. Modelu w ogóle nie można wywołać w ten sposób. Jest to cel zwracający wyłącznie prawdopodobieństwa w punkcie końcowym decisions, a żądanie, które prosi go o prozę, prosi o coś, czego on nie generuje. Każda biblioteka klienta, która domyślnie korzysta z chat completions, będzie wymagała jawnej ścieżki.

Co to mówi o samym modelu, a nie tylko o jego nazwie

Nazewnictwo jest objawem rzeczywistej decyzji projektowej, która polega na tym, że nie jest to model czatu z innym formatem wyjścia. Model czatu zwraca tekst, więc jego identyfikator można swobodnie podmieniać między dostawcami, proxy i bramami, które mówią tym samym schematem. Model, który zwraca skalibrowane prawdopodobieństwa dla twoich własnych typowanych pytań, nie ma takiego wspólnego schematu, a identyfikator jest związany z jednym punktem końcowym o jednym kształcie żądania.

Dlatego rodzina nie ma jeszcze pływającego aliasu ani drugiego członka: nie ma z czym być kompatybilna. To wyjaśnia również, dlaczego modelu nie można po prostu dodać do routera ogólnego przeznaczenia. OrcaRouter nie obsługuje gemini-decision-1, ponieważ endpoint zwracający wyłącznie prawdopodobieństwa nie jest celem chat-completions, a umieszczenie go za kluczem posługującym się tym schematem byłoby obietnicą, której warstwa routingu nie może dotrzymać. W przestrzeni decyzyjnej mamy natomiast typesafe/jev-1.14 firmy TypeSafe — model decyzyjny, który można wywołać przez ten sam interfejs co wszystko inne w katalogu.

Częścią potoku decyzyjnego, którą router faktycznie obsługuje, jest połowa odpowiedzialna za szkicowanie — wywołanie generatywne, które tworzy kandydacką odpowiedź lub rubrykę, którą następnie ocenia scorer. To wywołanie działa w ramach ponad 200 modeli na jednym endpointcie, z ceną katalogową dostawcy przekazywaną bez narzutu (0% marży), i to jest wywołanie, w którym zmiana dostawcy to zmiana konfiguracji, a nie przepisanie. Natomiast wywołanie oceniające jest z założenia przypisane do jednego endpointu, a uczciwa architektura traktuje je jako stałą zależność, a nie coś, co można obejść routingiem.

Jeśli wybierasz między dwoma ciągami na formularzu

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.

Praktyczną konsekwencją jest to, że każda tabela porównawcza, recenzja lub benchmark, w których oba są wymienione jako osobne pozycje, opisuje ten sam model dwukrotnie. Dwa wiersze, jeden model, jedna cena. Jeśli dwa wiersze nie zgadzają się co do jakiejś liczby, jeden z nich jest nieaktualny, a nie mierzy czegoś innego.

Konkluzja

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.