Twoje prompty od dawna są grafem, tylko nikt tego nie nazwał

Kiedy budujesz coś więcej niż pojedyncze zapytanie do modelu, dość szybko przestajesz pisać jeden dobry prompt. Jedno wywołanie zasila kolejne, wyszukiwanie w danych przeplata się z generowaniem, router rozgałęzia ruch na kilka ścieżek, a na końcu coś zbiera te równoległe odpowiedzi w jedną. Cała branża zeszła się na jednej strukturze, która wiąże to wszystko w całość: na grafie. LangGraph, DSPy i Prompt Flow pokazują go wprost, a w pracach badawczych powstają już systemy, które ten graf automatycznie optymalizują. Brakowało jednego: nikt nie zdefiniował precyzyjnie, w którym momencie zlepek połączonych promptów faktycznie staje się grafem, a kiedy to wciąż zwykłe łańcuchowanie wywołań.

Nadrabia to praca opublikowana 30 lipca na arXiv. Jej autor proponuje pojęcie prompt graph engineering, po polsku inżynierię grafu promptów: podejście, w którym prompt nie jest pojedynczym napisem, tylko węzłem jawnego, wykonywalnego grafu, który da się wersjonować i ulepszać jak kod. Od razu zaznaczę, czym ta praca nie jest. Nie ma tu żadnego nowego narzędzia, benchmarku ani biblioteki do pobrania. To tekst pojęciowy, który porządkuje słownictwo, bo słownictwo zostało w tyle za praktyką. Słowo graf oznacza dziś raz sposób rozumowania jednego modelu, raz rozmowę wielu agentów, a raz artefakt do orkiestracji, i z tej mieszanki trudno cokolwiek wyczytać.

Autor wyprowadza swoją definicję z pomysłów, które działały już wcześniej: z grafów przepływu danych i z tego, jak same modele rozumują, kiedy prowadzą myśl łańcuchem, drzewem albo grafem. Zamienia ją w prosty test: bierzesz swój system i sprawdzasz, czy spełnia cztery warunki. Jeśli tak, to jest inżynieria grafu promptów. Jeśli nie, to coś innego, choćby wyglądało podobnie.