Mi valójában itt a munkafolyamat
Az MI-területen a legtöbb „munkafolyamat"-eszköz kérésláncolat vékony réteggel a tetején. A ToRun építője irányított körmentes gráf (DAG) típusos lépésekből: modellhívásokat, eszközhívásokat, feltételes elágazásokat, ciklusokat és almunkafolyamatokat köt gráffá, a motor pedig függőségi sorrendben hajtja végre őket, párhuzamosan ott, ahol a gráf engedi.
Minden lépés teljes értékű entitás saját beállítással: lépéstípus (LLM-hívás, webes keresés, kódfuttatás, képgenerálás, visszakeresés, átalakítás és így tovább), bemeneti séma, hibaházirend (gyors bukás, ismétlés várakozással, átállás tartalékra), lépésenkénti végrehajtási költségvetési plafon és időkorlát.
A modellirányítás minden LLM-lépésen belül ugyanazon a képességcsővezetéken megy át, mint minden más a ToRunban. Kijelenti, mire van szüksége — szerkezetes kimenet, látás, eszközhasználat, következtetés, legalább N tokenes környezeti ablak —, a végrehajtó pedig feloldja a legjobban illő modellt az akkor elérhető szolgáltatók közül. Ha kedvelt szolgáltatója 5xx-et ad vissza, a tartalékos lánc automatikusan átveszi.
Minőségelsőségű végrehajtók és mit jelent ez a gyakorlatban
Amikor munkafolyamatot futtat, a végrehajtó szándékosan minőségi osztályú modelleket választ a legolcsóbb lehetőség helyett. Két ok: az automatizálások olyan műtermékeket állítanak elő (jelentések, generált tartalom, kód), amelyeket senki sem néz át azonnal, így a minőségi hibák csendben halmozódnak; és mérsékelt mennyiségnél a költségkülönbség kisebb, mint egy rossz kimenet ára, amely újrafuttatást vagy kézi javítást kényszerít ki.
A gyakorlatban ez azt jelenti, hogy egy „foglald össze a kutatást, és írj jelentést" munkafolyamat szilárd következtető modellt választ az összefoglaláshoz és jó minőségű szövegmodellt az íráshoz ahelyett, hogy az ártalpra rohanna. Ezt lépésenként felülbírálhatja, ha tudja, hogy ott elég egy könnyű modell.
A számlázás a ToRun többi részét követi: minden modellhívás a munkafolyamaton belül pontosan egy tételt ír befagyasztott díjpillanatképpel. Egy futás, amely három különböző modellt hív öt lépésben, öt tételt ad. Minden futás pontos költségét ellenőrizheti lépésenkénti bontásban utólag is — akár hónapokkal később, amikor a szolgáltatói árak már elmozdultak.
Egy futás átvizsgálása
Minden munkafolyamat-futás szerkezetes nyomot állít elő. A nyom megmutatja a DAG-ot minden csomópontnál megjegyzésekkel: kezdési idő, befejezési idő, feloldott modell, bemeneti és kimeneti tokenszám, elvégzett eszközhívások és a hiba, ha volt. LLM-lépéseknél kibonthatja a pontosan elküldött kérést és a kapott nyers választ.
Ha egy lépés elbukik, a nyom megmondja, a hiba a modellhívásból jött-e (szolgáltatói hiba, környezettúlcsordulás, tartalmi házirendi elutasítás), egy későbbi eszközből (hálózati időtúllépés, sémaellenőrzési hiba) vagy a saját feltételes logikájából. Nem kell naplózást hozzáadnia: minden futásnál infrastruktúra szintjén rögzül.
Bármely futás megismételhető ugyanazzal a bemenettel, ami közvetlenné teszi egy hiba megismétlését.
Egy kis példa: heti versenytárs-figyelő munkafolyamat
Képzeljen el egy munkafolyamatot, amelyet minden hétfő reggel elindít:
- Webes keresési lépés — friss híreket keres versenytársi kulcsszavak halmazára, és címek és szemelvények listáját adja vissza.
- Visszakeresési lépés — előhozza az utolsó négy jelentést egy tudásbázisból, hogy megalapozza a kiinduló környezetet.
- Összefoglaló lépés (LLM) — a keresési találatokat szerkezetes megállapításokká párolja: új szolgáltatások, árváltozások, fontos bejelentések.
- Írási lépés (LLM) — tömör belső feljegyzést ír egységes házi stílusban, az összefoglalt megállapításokra alapozva.
- Kézbesítési lépés — közzéteszi a feljegyzést egy beállított webhook-végponton.
A gráfnak természetes függősége van: a 3. lépés az 1-től és 2-től függ (amelyek párhuzamosan futhatnak), a 4. a 3-tól, az 5. a 4-től. A végrehajtó ezt mindenféle kifejezett párhuzamossági beállítás nélkül teszi: olvassa az éleket.