Eval-Driven Agent Development: How I Stopped Tuning Prompts on Vibes

నేను ఒక ప్రాంప్ట్‌ను మార్చాను. తదుపరి రన్ మెరుగ్గా కనిపించింది. ఆ మార్పు వల్ల ఉపయోగపడిందా, లేక నేను అదృష్టవంతుడిని అయ్యానా?

చాలా కాలం పాటు, నా సమాధానం "అవును అనుకుంటున్నాను" అని ఉండేది. నేను ఒక కమాండ్‌ను మార్చి, పైప్‌లైన్‌ను రన్ చేసి, అది విజయవంతం కావడాన్ని చూసి, పంపిణీ చేసేవాడిని. దీనినే 'vibes-based engineering' అంటారు. ఏజెంట్లను నిర్మించే దాదాపు ప్రతి ఒక్కరూ ఇలాగే చేస్తారు, ఎందుకంటే దీనికి ప్రత్యామ్నాయ మార్గాలు కష్టంగా అనిపిస్తాయి.

కానీ కోడింగ్ ఏజెంట్లు 'non-deterministic'. మీరు ఒకే పనిని రెండుసార్లు చేసినా రెండు వేర్వేరు ఫలితాలు రావచ్చు. ఒకే ఒక్క మంచి రన్ మీకు ఏమీ చెప్పలేదు. మీ మార్పు పని చేసిందా లేదా కేవలం అదృష్టం వల్ల అలా జరిగిందా అనేది మీరు చెప్పలేరు.

మెషిన్ లెర్నింగ్ క్రమశిక్షణను ఉపయోగించి నేను దీనిని పరిష్కరించాను. నా మొత్తం వ్యవస్థను కవర్ చేయడానికి ఒక ఎవాల్యుయేషన్ ఫ్రేమ్‌వర్క్‌ను (evaluation framework) రూపొందించాను.

ఈ ఫ్రేమ్‌వర్క్ ఎలా పనిచేస్తుందంటే:

• Target: ఒక స్థిరమైన కోడ్‌బేస్ (frozen codebase). స్కోర్‌లు పోల్చడానికి వీలుగా ఇది మారకుండా ఉంటుంది. • Task: ప్రాంప్ట్ మరియు ఒక 'oracle'తో కూడిన ఒక నిర్దిష్ట బెంచ్‌మార్క్ అంశం. • Oracle: ఒక డిటర్మినిస్టిక్ చెక్ (deterministic check). ఇవి తప్పనిసరిగా పాస్ కావాల్సిన షెల్ కమాండ్‌లు. • Variant: మీరు పరీక్షిస్తున్న నిర్దిష్ట మార్పు, ఉదాహరణకు కొత్త ప్లానర్. • Trial: ఒకే ఒక్క రన్. రాండమ్‌నెస్ (randomness) పరిగణనలోకి తీసుకోవడానికి నేను ప్రతి టాస్క్‌ను బహుళ సార్లు రన్ చేస్తాను.

వివిధ రకాల వైఫల్యాలను గుర్తించడానికి నేను రెండు రకాల స్కోరింగ్‌లను ఉపయోగిస్తాను:

  • Code Graders (Deterministic): ఇవి టెస్ట్ పాస్ రేట్లు, ఖర్చు, సమయం మరియు ఫైల్ మార్పులను తనిఖీ చేస్తాయి.
  • LLM Judge (Probabilistic): ఒక ప్రత్యేకమైన, స్థిరమైన మోడల్ స్పెసిఫికేషన్ నాణ్యత మరియు ఇంప్లిమెంటేషన్ ఖచ్చితత్వాన్ని స్కోర్ చేస్తుంది.

కోడ్ రన్ అవుతుందో లేదో కోడ్ గ్రేడర్స్ చెబుతాయి. కోడ్ బాగుందో లేదో జడ్జ్ చెబుతుంది. మీకు ఈ రెండూ అవసరం.

నేను సగటులను (averages) ఉపయోగించడం కూడా ఆపేశాను. ఏజెంట్ల విషయంలో 'means' మోసం చేస్తాయి. ఒక టాస్క్ 3 సార్లు చేసినప్పుడు 2 సార్లు విజయవంతమైతే, అది బాగున్నట్లు అనిపిస్తుంది. కానీ అది నమ్మదగినది కాదు. దానికి బదులుగా, నేను రెండు మెట్రిక్స్‌ను ఉపయోగిస్తాను:

  • pass@k: ఏజెంట్ కనీసం ఒక్కసారైనా విజయవంతమైందా? (Capability)
  • pass^k: ఏజెంట్ ప్రతిసారీ విజయవంతమైందా? (Reliability)

pass^k లో వచ్చే పెరుగుదలే నిజమైన విజయం. అంటే మీరు ఏజెంట్‌ను కేవలం అదృష్టంతో కాకుండా, స్థిరంగా (consistent) మార్చారని అర్థం.

వ్యవస్థను పదునుగా ఉంచడానికి, లోతైన అవగాహన అవసరమయ్యే కష్టమైన టాస్క్‌లను నేను జోడిస్తాను. ఏజెంట్ ఏదైనా నిజమైన బగ్‌పై విఫలమైనప్పుడు, ఆ వైఫల్యాన్ని ఒక శాశ్వత టాస్క్‌గా మారుస్తాను. ఇది ఒక క్లోజ్డ్ లూప్‌ను (closed loop) సృష్టిస్తుంది. ఏజెంట్ మెరుగుపడే కొద్దీ బెంచ్‌మార్క్ కూడా కష్టతరమవుతుంది.

ఈ ఇన్‌ఫ్రాస్ట్రక్చర్ నిర్మించడం చాలా కష్టమైన పని, కానీ నేను నిర్మించిన వాటిలో ఇది అత్యంత ప్రభావవంతమైనది. ఇది "ఇది మెరుగ్గా ఉందని నేను అనుకుంటున్నాను" అనే మాటను "ఇది తక్కువ ఖర్చుతో 20% ఎక్కువ నమ్మదగినది" గా మార్చింది.

కోడింగ్ ఏజెంట్లను డెమో చేయడం సులభం కానీ వాటిని నమ్మడం కష్టం. మీరు కేవలం డెమోల స్థాయి నుండి ముందుకు వెళ్లాలనుకుంటే, కొలవాలని (measure) నిర్ణయించుకోవాలి.

Source: https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189

Optional learning community: https://t.me/GyaanSetuAi