Czym naprawdę jest tu przepływ pracy
Większość narzędzi „przepływowych" w obszarze AI to łańcuchy zapytań z cienką warstwą na wierzchu. Konstruktor ToRun to skierowany graf acykliczny (DAG) typowanych kroków: łączysz wywołania modeli, wywołania narzędzi, rozgałęzienia warunkowe, pętle i podprzepływy w graf, a silnik wykonuje je w kolejności zależności, równolegle tam, gdzie graf na to pozwala.
Każdy krok to pełnoprawny byt z własną konfiguracją: typ kroku (wywołanie LLM, wyszukiwanie w sieci, wykonanie kodu, generowanie obrazu, pobieranie, przekształcenie itd.), schemat wejścia, polityka błędu (szybka porażka, ponowienie z odczekaniem, przejście do alternatywy), pułap budżetu wykonania na krok i limit czasu.
Kierowanie modelu wewnątrz każdego kroku LLM przechodzi przez ten sam potok zdolności co wszystko inne w ToRun. Deklarujesz, czego potrzebujesz — wyjścia strukturalnego, widzenia, użycia narzędzi, rozumowania, okna kontekstu co najmniej N tokenów — a wykonawca rozstrzyga najlepiej pasujący model wśród dostawców dostępnych w danej chwili. Jeśli preferowany dostawca zwróci 5xx, łańcuch zapasowy przejmuje automatycznie.
Wykonawcy z priorytetem jakości i co to zmienia w praktyce
Gdy uruchamiasz przepływ, wykonawca celowo wybiera modele klasy jakościowej zamiast najtańszej opcji. Dwa powody: automatyzacje wytwarzają artefakty (raporty, wygenerowaną treść, kod), których nikt zaraz nie przegląda, więc usterki jakości cicho się kumulują; a przy umiarkowanym wolumenie różnica kosztu jest mniejsza niż cena kiepskiego wyniku, który wymusza ponowne uruchomienie albo ręczną poprawkę.
W praktyce znaczy to, że przepływ „streść badanie i napisz raport" wybierze solidny model rozumowania do streszczenia i wysokiej jakości model tekstowy do pisania, zamiast biec ku dnu cenowemu. Możesz to nadpisać na konkretnym kroku, jeśli wiesz, że wystarczy tam lekki model.
Rozliczanie idzie za resztą ToRun: każde wywołanie modelu wewnątrz przepływu zapisuje dokładnie jeden wpis z zamrożoną migawką stawki. Przebieg wywołujący trzy różne modele w pięciu krokach daje pięć wpisów. Możesz zbadać dokładny koszt każdego przebiegu, rozbity na kroki, po fakcie — nawet miesiące później, gdy ceny dostawców już się przesuną.
Diagnozowanie przebiegu
Każdy przebieg przepływu daje uporządkowany ślad. Ślad pokazuje DAG z każdym węzłem opisanym: czas rozpoczęcia, czas zakończenia, rozstrzygnięty model, liczba tokenów wejścia i wyjścia, wykonane wywołania narzędzi i ewentualny błąd. Na krokach LLM możesz rozwinąć dokładne wysłane zapytanie i surową otrzymaną odpowiedź.
Jeśli krok zawiedzie, ślad mówi, czy błąd przyszedł z wywołania modelu (błąd dostawcy, przepełnienie kontekstu, odmowa z polityki treści), z narzędzia dalej w potoku (przekroczenie czasu sieci, niepowodzenie walidacji schematu) czy z twojej własnej logiki warunkowej. Nie musisz dodawać dziennika: jest przechwytywany na poziomie infrastruktury przy każdym przebiegu.
Każdy przebieg można powtórzyć z tym samym wejściem, co czyni prostym odtworzenie awarii.
Mały przykład: cotygodniowy przepływ wywiadu konkurencyjnego
Wyobraź sobie przepływ, który uruchamiasz w każdy poniedziałek rano:
- Krok wyszukiwania w sieci — szuka świeżych publikacji dla zestawu słów kluczowych konkurencji i zwraca listę adresów i wyimków.
- Krok pobierania — wyciąga cztery ostatnie raporty z bazy wiedzy, żeby ustawić kontekst wyjściowy.
- Krok streszczenia (LLM) — destyluje wyniki wyszukiwania w uporządkowane ustalenia: nowe funkcje, zmiany cen, ważne zapowiedzi.
- Krok pisania (LLM) — pisze zwięzłą notatkę wewnętrzną w spójnym stylu firmowym, osadzoną w streszczonych ustaleniach.
- Krok dostarczenia — publikuje notatkę do skonfigurowanego punktu webhook.
Graf ma naturalną zależność: krok 3 zależy od 1 i 2 (które mogą biec równolegle), krok 4 od 3, krok 5 od 4. Wykonawca robi to bez żadnego jawnego ustawienia równoległości: czyta krawędzie.