Печалби:
- Може да сравнява семейство модели (бързи/балансирани/мощни) по възможности, скорост и цена
- Проектира избор на модел и стратегии за маршрутизиране според сложността на задачата
- Базира избора на модел на доказателства с малък набор от оценки
Единственото решение, което определя най-добрата цена за вашите пари и качество в интегрирането на LLM, е кой модел използвате. Общият рефлекс е „избери най-силния модел“; Това обаче често означава ненужни разходи и забавяния. Правилният подход е да изберете най-лекия модел, който изпълнява всяка задача и да базирате този избор на измерване, а не на догадки. В този модул ще сравните фамилията модели по оста възможности/скорост/цена, ще установите стратегия за маршрутизиране на модел според сложността на задачата и ще докажете избора с малък набор от оценки.
Разбиране на моделното семейство
Доставчиците обикновено предлагат три класа: бърз/евтин, стабилен и мощен. Връзката между тях е обобщена в три оси: способност (мощност за решаване на трудни задачи), скорост (латентност), цена (цена на токена).
клас
пример
талант
скорост
цена
Налични задачи
бързо
Хайку 4.5
среден
много високо
ниско
Класификация, етикетиране, кратко резюме, ориентация
балансиран
сонет 5
високо
високо
среден
Общо предназначение, кодиране, многоетапен поток, работа на повечето агенти
силен
Опус 4.8
най-високо
среден
високо
Сложни разсъждения, дългосрочни автономни задачи, труден анализ
Критичен поглед: по-мощният модел не се представя по-добре при всяка работа. При просто етикетиране „спешно или не“, силният модел и бързият модел дават един и същ правилен отговор; единствената разлика е, че мощният е 5 пъти по-скъп и по-бавен. Допълнителният талант произвежда стойност само когато мисията го изисква.
Стъпка по стъпка: Как да изберем модел?
- Класифицирайте задачата. Дали е рутинно/шаблонно (етикетиране, извод) или отворено/многоетапно (анализ, планиране, код)?
- Започнете с най-лекия кандидат. Опитайте с бързия модел. Ако това е достатъчно, спри.
- Ако не е достатъчно, преминете в по-горен клас. Ако точността е ниска, отидете на балансирания, ако това не е достатъчно, отидете на силния.
- Измерете, не гадайте. Сравнете точността и цената на всеки кандидат с малък набор от оценки (по-долу).
- Настройте пренасочване. Вместо да се свързвате към един модел, разпределете задачата към правилния модел с "рутер".
Маршрут на модела
Реалните натоварвания са смесени: повечето входящи заявки са прости, някои са трудни. Загуба е да ги изпращате всички към мощния модел; Изпращането им всички към бързия модел намалява качеството. Маршрутизирането решава това: евтин модел (или просто правило) първо класифицира задачата, след което работата отива към подходящия модел.
# Подкана на рутера (работи с евтин модел) Класифицирайте входящата заявка според нейната трудност. Връща само следния JSON:{"трудност": "прост|сложен"}Прост: едноетапен, формулиран, кратък отговор. Сложен: изисква многоетапно разсъждение, анализ или дълго генериране. Заявка: """{{request}}"""
- отидете на прост → бърз модел (евтин, бърз).
- отидете на сложен → мощен модел (скъп, но необходим).
Този модел значително намалява средната цена, тъй като по-голямата част от трафика обикновено е прост.
Съвет: Решението за препоръка не винаги изисква LLM. Прости правила като „Преминете към бърз модел, ако текстът е по-малък от 20 думи“ също са ръководство и не водят до нулеви допълнителни символични разходи. Първо опитайте правилото.
Свързване на избора с доказателствата: Малкият оценъчен клъстер
Не избирайте модел на базата на „по-добре ми изглежда“. Eval (набор за оценка) е малък набор от проби, за които е известен правилният отговор; изпълнявате всеки модел на този комплект и измервате точността, цената и забавянето.
# Шаблон за настройка на Eval1) Съберете 20-50 реални примера, напишете на ръка „правилния отговор“ на всеки.2) Пуснете всеки модел (бърз/балансиран/силен) в този комплект.3) За всеки модел: брой корекции, средни токени за пропускателна способност, цена на заявка, средно време.4) Изберете модела, който „дава достатъчна точност най-евтино“.
# Eval таблица за сравнение (попълване) Модел | Точност | Цена на заявка | Средна продължителност Хайку | ...% | ... $ | ... snSonnet | ...% | ... $ | ... snOpus | ...% | ... $ | ... сек
Слаба подкана/Силна подкана (решение за избор на модел)
# СЛАБ (няма основа за решение) Нека използваме най-добрия модел, бюджетът не е важен.
# СИЛЕН (решение въз основа на измерване) При оценка на 50 проби, Haiku даде 96% точност, Sonnet даде 97% точност; Разликата е статистически незначима. Haiku е избран, защото е 5 пъти по-евтин и 2 пъти по-бърз. Ако точността падне под 95%, решението за надграждане до Sonnet ще бъде взето автоматично.
Мощна версия; обвързва избора с число, праг и правило за ескалация. Това едновременно защитава днешното решение и управлява бъдещата промяна.
Три мини калъфа
Случай 1 — Бягство от свръхмощния модел. Кол център изготвяше всички резюмета на разговори с Opus; месечната сметка беше висока. При оценка от 40 проби Sonnet беше с 1% зад Opus по точност, но струваше една трета. Те преместиха обобщението в Сонета; месечната цена спадна от $9000 на $3100, без оплаквания за качество.
Случай 2 — Смесен трафик с пренасочване. 80% от заявките на екипа по правни технологии са били просто маркиране на документи, 20% са били сложен анализ на договори. Изпращаха ги всички към мощния модел. Те добавиха евтин рутер и разпределиха прости задачи към Haiku и сложни задачи към Opus; средната цена на заявката спадна с 64%, докато качеството на анализа се запази.
Случай 3 — Разходите за намаляване без измерване. За да намали разходите, един екип намали извличането на сложни медицински кодове директно към бързия модел; Те не оцениха. На живо точността спадна от 92% на 78%, което доведе до връщане на неправилни заключения. Първо трябваше да оценят: тази задача изискваше мощния модел. Урок: както намаляването, така и повдигането се извършват чрез измерване.
Често срещани грешки
- Рефлексът на „най-силния модел“: Разхищение и ненужно забавяне на прости задачи.
- Промяна на модела без измерване: Както намаляването, така и уголемяването са рискови без оценка.
- Заключване в един модел: Маршрутизирането при смесен трафик често е по-ефективно.
- Винаги бъркате рутера с LLM: Простите правила могат да работят без разходи.
- Незадаване на праг на усилване: Какво се случва, ако точността спадне, трябва да се определи предварително.
- Не коригиране на версията на модела: Запишете върху кой модел/версия работите в производството; Промяната на версията може да промени поведението.
Deeper: Perpetuating Eval и Incremental Trial
Изборът на модел не е еднократно решение. Доставчиците представят нови модели, цените се променят, длъжностната ви характеристика се развива. Така че настройте клъстера eval веднъж и не забравяйте; дръж го като живо същество. Когато излезе нов модел, пускате през него същите 20-50 проби, актуализирате таблицата и отново вземате решението си. Това ви предпазва от капана на „интуицията за превключване на модели“.
Втората усъвършенствана техника е резервният / каскаден модел. Първо давате задачата на евтиния модел; Ако изходът е с ниска степен на доверие или слоят за проверка (единица 11) го отхвърли, вие ескалирате същата заявка. Така че по-голямата част от трафика се разрешава на евтиния модел, като само останалото малцинство отива на скъпия модел. Това е както по-евтино, така и по-трайно от подхода с фиксиран единичен модел.
Третата точка е, че eval включва не само точност, но и цена и латентност. Ако един модел е 1% по-точен, но 3 пъти по-скъп и 2 пъти по-бавен, компромисът не си струва за повечето работни места. Вземете решение по три оси (точност, цена, латентност) и определете „праг на достатъчност“: „ако точността е над 95%, изберете най-евтиния“.
Накрая запишете кой модел/версия сте използвали в производството. Ако един ден качеството на изхода се промени, първото нещо, което ще погледнете е дали версията на модела се е променила. Проследимостта на версиите улеснява намирането на първопричината за проблеми с качеството.
Още едно предупреждение: клъстерът eval трябва да представлява вашето действително натоварване. Една оценка, състояща се само от лесни примери, крие къде моделът се спъва в трудни случаи и ви вдъхва фалшива увереност. Добра оценка; Той включва общи лесни примери, както и ъглови случаи, които срещате в реалността (двусмислени, непълни, противоречиви входове). Това трудно малцинство определя избора ви на модел, защото така или иначе всеки модел успява в лесното мнозинство. Поддържайте своя Eval свеж и представителен, като периодично го захранвате с нови реални примери.
В обобщение
Правилният модел е най-лекият модел, който върши работата; По-мощният не е по-добър за всяка работа, просто е по-скъп и по-бавен. Класифицирането на задачата и започването от най-лекия кандидат, разпределянето на смесения трафик с маршрутизиране и обосноваването на селекцията с малък набор от оценки намалява многократно разходите, като същевременно запазва качеството.
Задача за приложение
Изберете работно натоварване. (1) Класифицирайте задачата като проста/сложна. (2) Проектирайте малък набор от 20 реални примера (с техните верни отговори). (3) Направете план за попълване на таблицата за сравнение на точност/цена/време за трите класа модел. (4) Ако имате смесен трафик, напишете правило за маршрутизиране и задайте праг на ескалация.
контролен списък
- [ ] Мога да сравня семейството на моделите по оста възможности/скорост/цена.
- [ ] Мога да прилагам принципа на „най-лекия успешен модел“.
- [ ] Мога да настроя моделно маршрутизиране според сложността на задачата.
- [ ] С малък набор от eval мога да обвържа селекцията с доказателствата.
- [ ] Мога да дефинирам праг за надграждане/понижаване.