Synthetische data is voor veel teams geen “nice to have” meer. Je wilt testsets, trainingsdata of evaluatiegegevens die je snel kunt herhalen, kunt uitleggen en kunt controleren. Alleen loopt het in de praktijk vaak vast op één ding: te veel losse bestanden, te veel terminalwerk en te weinig zicht op wat er nu precies gebeurt. SyGra Studio in versie 2.0.0 pakt dat heel nuchter aan met een visuele werkomgeving die hetzelfde blijft doen als de bestaande SyGra flows, maar dan op een manier die je als team beter kunt volgen.
Wat Studio in de kern verandert
Studio maakt van synthetische data generatie iets dat je kunt zien, beoordelen en bijsturen terwijl je werkt. In plaats van YAML bestanden en scripts heen en weer te schuiven bouw je een flow op een canvas, je bekijkt eerst een voorbeeld van de data en je ziet tijdens het draaien live wat elke stap doet. Belangrijk detail: onder de motorkap blijft het gewoon SyGra. Alles wat je visueel klikt en typt wordt vertaald naar SyGra compatibele graph configuratie en task executor scripts. Dat betekent dat je niet vastzit aan een “klik tool”, maar dat je werk ook als code blijft bestaan en herhaalbaar blijft.
Wat je er concreet mee kunt doen
In Studio kun je modellen configureren en controleren via begeleide formulieren. Denk aan OpenAI, Azure OpenAI, Ollama, Vertex, Bedrock, vLLM of een eigen endpoint. Daarna koppel je een databron zoals Hugging Face, een map op disk of ServiceNow, waarbij je direct een preview van rijen ziet voordat je echt gaat draaien.
Vervolgens bouw je nodes waarin je een model kiest, prompts schrijft en outputs vastlegt. Als je gestructureerde resultaten nodig hebt, kun je schema’s gebruiken en mappings maken die gebaseerd zijn op gedeelde state variabelen, met Pydantic als hulpmiddel om dat netjes te houden. Tijdens het uitvoeren zie je voortgang per node, kun je logs inline bekijken, breakpoints gebruiken en kleine stukjes code aanpassen in een editor die aanvoelt als een echte ontwikkelomgeving. Alles wordt automatisch als concept opgeslagen, en je krijgt per run inzicht in tokenkosten, latency en guardrail resultaten. De geschiedenis wordt weggeschreven in de map .executions/ zodat je later kunt terugkijken wat er precies is gebeurd.
Stap 1: begin bij de databron, niet bij de prompt
Als je Studio opent en je kiest Create Flow, staan Start en End al klaar. Mijn advies is om dan niet meteen met prompts te gaan spelen, maar eerst je input goed te zetten. Je kiest een connector zoals Hugging Face, disk of ServiceNow, vult de parameters in zoals repo_id, split of een bestandspad en klikt op Preview.
Dat preview moment is meer dan gemak. Kolomnamen uit je dataset worden meteen state variabelen, bijvoorbeeld {prompt} of {genre}. Daardoor weet je direct wat je later in prompts en processors kunt refereren. Zodra dit klopt, houdt Studio de configuratie synchroon en worden die variabelen vanzelf door de flow heen beschikbaar. Dat voorkomt het klassieke handwerk waarbij je zelf moet onthouden welke velden waar vandaan komen.
Stap 2: bouw de flow op het canvas en houd het simpel
Daarna sleep je de blokken die je nodig hebt het canvas op. Een eenvoudig voorbeeld is een story generatie pipeline. Je zet een LLM node neer, noemt die bijvoorbeeld Story Generator, kiest een eerder ingesteld model zoals gpt 4o mini, schrijft je prompt en slaat het resultaat op in een variabele zoals story_body. Vervolgens voeg je een tweede LLM node toe, bijvoorbeeld Story Summarizer, waarin je {story_body} gebruikt en de output wegschrijft naar story_summary.
Waar Studio helpt, is context. In het detailpaneel zie je modelinstellingen, je prompt editor, tool configuratie en eventuele pre of post processing code bij elkaar. Typ je in een prompt een accolade openen, dan krijg je direct suggesties van beschikbare state variabelen. Heb je vertakkingen of herbruikbare logica nodig, dan kun je ook Lambda of Subgraph nodes gebruiken. En als je parallel meerdere varianten wilt genereren, ondersteunt Studio ook multi LLM instellingen zonder dat je je flow onleesbaar maakt.
Stap 3: controleer de code, draai de workflow en kijk naar de feiten
Voordat je runt, is het verstandig om even in het Code Panel te kijken. Daar zie je de YAML of JSON die Studio opbouwt. Dit is dezelfde artefact die naar tasks/examples/ wordt geschreven. Wat je ziet is dus wat je later ook kunt committen, reviewen en herhalen.
Als je gaat uitvoeren, klik je op Run Workflow. In de run instellingen kies je onder andere aantallen records, batch sizes en retry gedrag. Daarna zie je in het Execution panel live de status per node, inclusief tokengebruik, latency en kosten. Logs geven je precies genoeg zicht om fouten te vinden zonder dat je alles hoeft te reproduceren in de terminal. Runs worden opgeslagen als .executions/runs/*.json, en na afloop kun je outputs downloaden, vergelijken met eerdere runs en de metadata erbij houden voor evaluatie.
Bestaande workflows draaien, inclusief een nuttig voorbeeld
Handig is dat Studio niet alleen bedoeld is voor nieuwe flows. Je kunt ook bestaande workflows uit je tasks openen en uitvoeren. Een voorbeeld is tasks/examples/glaivecodeassistant/. Die workflow haalt de dataset glaiveai/glaive-code-assistant-v2 op, maakt conceptantwoorden, laat die beoordelen en herhaalt de loop totdat de critique terugkomt met “NO MORE FEEDBACK”.
In Studio zie je dat heel letterlijk op het canvas: twee LLM nodes, generate_answer en critique_answer, met een conditionele route die terugloopt voor een nieuwe revisie of doorgaat naar End. In de run modal kun je de dataset split wisselen, batch sizes aanpassen, een recordlimiet zetten en temperaturen bijstellen zonder aan YAML te komen. Tijdens het draaien zie je de nodes na elkaar oplichten, kun je tussenresultaten zoals critiques inspecteren en houd je overzicht op voortgang en status. Uiteindelijk rolt er synthetische data uit die je kunt gebruiken voor training, evaluatie of annotatie.
Zo start je zonder omwegen
Wil je het zelf proberen, houd het dan klein. Clone de repo en start de Studio omgeving met: git clone SyGra en daarna make studio. Gebruik vervolgens een voorbeeldconfig als referentie, bijvoorbeeld tasks/examples/glaivecodeassistant/graph_config.yaml, zodat je niet vanaf nul hoeft te gokken hoe een goede flow eruitziet.
Mijn praktische conclusie: Studio is vooral waardevol omdat het de afstand verkleint tussen idee en uitvoering. Je ziet eerder of je input klopt, je ontdekt sneller waar je prompt of mapping misgaat en je krijgt per run harde cijfers in plaats van onderbuikgevoel. Dat scheelt tijd, maar belangrijker, het voorkomt dat je met onbetrouwbare data beslissingen gaat nemen.