દરેક વ્યક્તિ પ્રોમ્પ્ટ પાછળ પાગલ છે. તેઓ અભિવાદન (greeting) ને ફાઇન-ટ્યુન કરે છે, ટોન બદલે છે, અને મોડેલ પૂરતું ઉષ્માભર્યું લાગે છે કે નહીં તેની ચિંતા કરે છે. તે એક વિક્ષેપ છે. જ્યારે AI એજન્ટ વાસ્તવિક વપરાશકર્તાઓને વાસ્તવિક ઈમેલ મોકલવાનું શરૂ કરે છે, ત્યારે જોખમ એ નથી કે તે "Cheers" ને બદલે "Best regards" લખે છે. જોખમ એ છે કે એજન્ટના નિર્ણય અને ઇનબોક્સમાં મેસેજ પહોંચવા વચ્ચે શું થયું તે તમે ચોકસાઈથી કહી શકતા નથી. હું પહેલા સીમા (boundary) ને જોઉં છું. ત્યાં જ પ્રોડક્શન સિસ્ટમ્સ શાંતિથી નિષ્ફળ જાય છે.
કોન્ટ્રાક્ટ એ નબળો બિંદુ છે
AI ડેમોમાં ભૂલોની ક્ષમતા વધુ હોય છે. બ્રાઉઝર વિન્ડોમાં એક સરળ વાતચીત ધારણાઓના જાળાને છુપાવે છે. પ્રોડક્શનમાં, વાસ્તવિક નબળાઈ ત્રણ વસ્તુઓ વચ્ચેના કોન્ટ્રાક્ટમાં રહેલી છે: એજન્ટનો નિર્ણય, એક્શન એક્ઝિક્યુટ કરતું ટૂલ, અને પરિણામની ચકાસણી કરતું સ્ટેપ. જો તે સીમા અસ્પષ્ટ હોય, તો સિસ્ટમ ત્યાં સુધી સુંદર રીતે કામ કરે છે જ્યાં સુધી તે કામ કરવાનું બંધ ન કરે. પછી તે શાંતિથી નિષ્ફળ જાય છે, આખા ગ્રાહક સેગમેન્ટને ડુપ્લીકેટ મેસેજ મોકલે છે, અથવા શા માટે તે થયું તેનો કોઈ સ્પષ્ટ રેકોર્ડ વિના ખોટા સમયે મેસેજ મોકલી દે છે. પ્રોમ્પ્ટ કદાચ કવિતા જેવો લાગે. પરંતુ તેની નીચેનું આર્કિટેક્ચર હજુ પણ દોરીથી બાંધેલું હોઈ શકે છે.
એજન્ટને મુક્ત રીતે લખવા દેવાનું બંધ કરો
સૌથી સામાન્ય ભૂલ એજન્ટને ખાલી પેજ આપવી તે છે. ટીમો તેને કાચા ટેક્સ્ટમાં ઈમેલનું વર્ણન કરવા દે છે અને પછી ગદ્ય (prose) માંથી ઈરાદો (intent) સમજવા માટે ડાઉનસ્ટ્રીમ ટૂલ પર વિશ્વાસ કરે છે. તે નાજુક છે. એક LLM વ્યાજબી ઈરાદો સૂચવી શકે છે, પરંતુ તમારા ઇન્ફ્રાસ્ટ્રક્ચરને સર્જનાત્મકતાની જરૂર નથી. તેને કોન્ટ્રાક્ટની જરૂર છે. તેને ચોક્કસ ફીલ્ડ્સની જરૂર છે જેને મશીન અસ્પષ્ટતા વિના વેલિડેટ કરી શકે.
જ્યારે એજન્ટ ઈમેલ વિનંતી બહાર મોકલે છે, ત્યારે આઉટપુટમાં બરાબર તે જ હોવું જોઈએ જે પ્લમ્બિંગને જરૂરી છે:
- Template version: ઈમેલ બોડીનું કયું વર્ઝન વપરાઈ રહ્યું છે, જેથી તમે જાણી શકો કે વપરાશકર્તાએ શું જોયું હતું.
- Recipient scope: આ કોને મળશે, જે યુઝર આઈડી અથવા સેગમેન્ટ નિયમો દ્વારા વ્યાખ્યાયિત કરવામાં આવે છે, "જે વપરાશકર્તાએ હમણાં જ સાઇન અપ કર્યું છે" જેવા નેચરલ લેંગ્વેજ દ્વારા નહીં.
- Trace ID: એક યુનિક આઈડેન્ટિફાયર જે આ વિનંતીને એજન્ટથી તમારા એક્ઝિક્યુટર દ્વારા, ઈમેલ પ્રોવાઈડર દ્વારા, અને તમારા લોગ્સમાં અનુસરે છે.
- Time window: આ મોકલવાનું ક્યારે માન્ય છે, જેથી જૂના એજન્ટના નિર્ણયો કલાકો પછી મધ્યરાત્રિના ઈમેલ ટ્રિગર ન કરે.
- Idempotency: એક કી જે એજન્ટ ફરી પ્રયાસ કરે અથવા નેટવર્ક સમસ્યા આવે તો પણ એક જ લોજિકલ મોકલવાનું કાર્ય બે વાર થતું અટકાવે છે.
કાચો ટેક્સ્ટ એ એક ખરાબ API છે. તે તાકીદ, પ્રેક્ષકો અને એક્શન વિશે અસ્પષ્ટતા માટે જગ્યા છોડે છે. ચોક્કસ ફીલ્ડ્સ મશીન-રીડેબલ, ઓડિટેબલ અને ટેસ્ટેબલ હોય છે. તેઓ અસ્પષ્ટ સૂચનાને વેરિફાઇ કરી શકાય તેવા કમાન્ડમાં ફેરવે છે.
ગદ્ય નહીં, એક્શન્સ
એજન્ટને ખુલ્લી લેખન કાર્ય આપવાને બદલે, તેને મંજૂર એક્શન્સના મેનૂ સુધી મર્યાદિત કરો. તેને ફિક્સ્ડ enum ધરાવતા ઇન્ટરનલ API તરીકે વિચારો. એજન્ટ સબ્જેક્ટ લાઇન ડ્રાફ્ટ કરતું નથી અથવા અભિવાદન વિશે વિચારતું નથી. તે send_review_request અથવા send_retry_notice જેવું એક્શન પસંદ કરે છે. તેની સર્જનાત્મક સ્વતંત્રતા આટલી જ છે.
ત્યારબાદ એક ડિટરમિનિસ્ટિક એક્ઝિક્યુટર તે એક્શન કી લે છે, વર્ઝન કંટ્રોલમાંથી સાચું ટેમ્પલેટ ખેંચે છે, તેને સેનિટાઈઝ્ડ ડેટા સાથે ભરે છે, વેરિફાઇડ સોર્સમાંથી રિસીપિયન્ટ લિસ્ટ ભરે છે, અને અંતિમ કમાન્ડ બનાવે છે. એજન્ટ નક્કી કરે છે કે શું થવું જોઈએ. બોરિંગ, અનુમાનિત કોડ નક્કી કરે છે કે તે કેવી રીતે થશે.
આ અલગતા સિસ્ટમને ટેસ્ટ કરવામાં સરળ બનાવે છે. તમે LLM ઇન્ફરન્સ ચલાવ્યા વિના પણ એ વેરિફાય કરી શકો છો કે આપેલ ઇનપુટ સ્ટેટ વિશ્વસનીય રીતે send_retry_notice ટ્રિગર કરે છે. તમારા યુનિટ ટેસ્ટ ઝડપી અને ડિટરમિનિસ્ટિક બની જાય છે કારણ કે તેઓ મેપિંગ લોજિક તપાસે છે, મોડેલ ટેમ્પરેચર નહીં. તમારા ઇન્ટિગ્રેશન ટેસ્ટ એ વાત પર ધ્યાન કેન્દ્રિત કરે છે કે એક્ઝિક્યુટર એક્શનને ઈમેલ સર્વિસ સાથે યોગ્ય રીતે મેપ કરે છે કે નહીં, નહીં કે મોડેલનો દિવસ સારો હતો કે નહીં.
પાંચ સ્તરોમાં બનાવો
એક મજબૂત સિસ્ટમ માત્ર એક પ્રોમ્પ્ટમાંથી ઉભી થતી નથી. તે સ્તરોમાં બનાવવામાં આવે છે, અને દરેક સ્તરની એક સિંગલ, સ્પષ્ટ જવાબદારી હોય છે.
1. બેકએન્ડ ઇવેન્ટને સુરક્ષિત ડેટામાં ઘટાડે છે.
ભલે ટ્રિગર વેબહૂક હોય, ડેટાબેઝમાં ફેરફાર હોય અથવા શેડ્યુલ કરેલ જોબ હોય, આ સ્તર ઇનપુટ્સને સેનિટાઈઝ કરે છે, અણધાર્યા ફીલ્ડ્સ દૂર કરે છે, અને એજન્ટને ફક્ત તેની જરૂર હોય તે જ આપે છે. જો વેબહૂક પેલોડમાં વીસ ફીલ્ડ્સ હોય પરંતુ એજન્ટને ફક્ત બેની જરૂર હોય, તો ફક્ત બે જ પાસ કરો. કોઈપણ કાચો યુઝર ટેક્સ્ટ વેરિફાઇડ થયા વિના નિર્ણય લેતા સ્તર સુધી પહોંચવો જોઈએ.
2. એજન્ટ ફિક્સ્ડ સ્કીમામાંથી એક્શન પસંદ કરે છે.
તે સંદર્ભ (context) જુએ છે, નિર્ણય લે છે, અને જરૂરી મેટાડેટા સાથે પૂર્વનિર્ધારિત એક્શન કીમાંથી એક આઉટપુટ આપે છે. તે ગદ્ય ડ્રાફ્ટ કરતું નથી. તે રિસીપિયન્ટ્સનો અંદાજ લગાવતું નથી. તે સ્ટ્રક્ચર્ડ પેલોડ રિટર્ન કરે છે જેને આગલું સ્તર JSON સ્કીમા સામે વેલિડેટ કરી શકે છે.
3. સાધન પરવાનગીઓ અને જરૂરી ફિલ્ડ્સની ચકાસણી કરે છે.
શું આ એજન્ટ કોન્ટેક્સ્ટ પાસે આ વપરાશકર્તા માટે send_review_request ટ્રિગર કરવાનો અધિકાર છે? શું પ્રાપ્તકર્તા સ્કોપ (recipient scope) ખાલી નથી અને મંજૂર મર્યાદામાં છે? શું તમારા લોગમાં idempotency key હાજર અને અનન્ય છે? શું trace ID યોગ્ય રીતે રચાયેલ છે? કોઈપણ ઇમેઇલ સર્વિસનો ઉપયોગ કરતા પહેલા, અહીં જ સ્પષ્ટ રીતે નિષ્ફળતા દર્શાવો.
4. ઇમેઇલ સર્વિસ trace ID સાથે મોકલવાની પ્રક્રિયાને લોગ કરે છે.
તમારા સિસ્ટમમાંથી બહાર નીકળતો દરેક સંદેશ પ્રોવાઇડરના API દ્વારા અને તમારા observability stack માં તે trace identifier સાથે હોવો જોઈએ. જો કોઈ વપરાશકર્તા ફરિયાદ કરે કે તેમને બે નકલો મળી છે, તો તમે એક ID ક્વેરી કરીને ચોક્કસપણે જોઈ શકવા સક્ષમ હોવા જોઈએ કે ડુપ્લીકેશન ક્યાંથી ઉદભવ્યું હતું: રિટ્રાય કરેલ એજન્ટ કોલ, અસ્થિર executor, અથવા ખોટી રીતે કામ કરતું callback.
5. એન્ડ-ટુ-એન્ડ ટેસ્ટ સામગ્રી અને અસર માટે વાસ્તવિક ઇનબોક્સ તપાસે છે.
વાસ્તવિક મેઇલબોક્સમાં રેન્ડર કરેલો સંદેશ ખોલો. શું વિષય રેખા (subject line) યોગ્ય રીતે ભરાયેલી છે? શું અનસબ્સ્ક્રાઇબ લિંક કામ કરે છે? શું મુખ્ય call-to-action બટન પર ક્લિક કરવાથી યોગ્ય વપરાશકર્તા સ્ટેટ સાથેના સાચા પેજ પર પહોંચાય છે? પાસ થયેલ unit test નો અર્થ છે કે કોડ ચાલ્યો. માત્ર ઇનબોક્સ ટેસ્ટ જ તમને જણાવશે કે ઇમેઇલ ખરેખર માણસ માટે કામ કરે છે.
અનુમાન કરતાં પુરાવા વધુ મહત્વના
જ્યારે આ પાઇપલાઇનમાં ટેસ્ટ નિષ્ફળ જાય છે, ત્યારે તમારે પુરાવાના ચાર ચોક્કસ ભાગોની જરૂર હોય છે. તેનાથી ઓછું કંઈપણ સ્વીકારશો નહીં.
- એજન્ટનો મૂળ નિર્ણય. તેણે કઈ ક્રિયા પસંદ કરી હતી, અને સંપૂર્ણ ઇનપુટ કોન્ટેક્સ્ટ શું હતો?
- સાધન (tool) તરફથી નોર્મલાઇઝ્ડ કમાન્ડ. ટેમ્પલેટ, hydration logic અને વેલિડેશન નિયમો લાગુ કર્યા પછી ડિટરમિનિસ્ટિક executor એ શું બનાવ્યું?
- અલગ કરેલા ઇનબોક્સમાં સંદેશ. તમે જે મોકલ્યું છે તેમ તમે શું વિચારો છો તેનો લોગ નહીં, પરંતુ સમર્પિત ટેસ્ટ મેઇલબોક્સમાં કેપ્ચર કરેલ વાસ્તવિક MIME સંદેશ, હેડર્સ અને બધું જ.
- લિંક પર ક્લિક કર્યા પછીની અંતિમ અસર. પરિણામી પેજ સ્ટેટ, ડેટાબેઝ ફેરફાર અથવા બાહ્ય ઇવેન્ટ જે સાબિત કરે છે કે ઇમેઇલે તેનો હેતુ સિદ્ધ કર્યો છે.
જો એક ભાગ ખૂટતો હશે, તો તમારી ટીમ ધારણાઓ સાથે તે ખાલી જગ્યા ભરી દેશે. તેઓ અનુમાન લગાવશે. ઓટોમેશનમાં અનુમાન લગાવવું ખર્ચાળ છે. તે કલાકો બગાડે છે, વિશ્વાસ ઘટાડે છે, અને દરેક ઘટનાને ફોરેન્સિક રહસ્યમાં ફેરવી દે છે...