మీరు ఒక అంతర్గత సాధనాన్ని (internal tool) రూపొందించారు, ఇది మోడల్ యొక్క APIని పిలవకుండానే ఒక LLM-ఆధారిత ఫీచర్‌పై 28 యూనిట్ టెస్టులను (unit tests) రన్ చేయడానికి ఒక టీమ్‌కు అనుమతిస్తుంది. మీరు మోడల్‌ను ఒక fakeable interfaceలో చుట్టి, మూడు పొరలైన deterministic, heuristic మరియు LLM-ఆధారిత మూల్యాంకనాన్ని (evaluation) జోడించడం ద్వారా దీనిని సాధించారు.

LLM వచనాన్ని (prose) రూపొందించిన వెంటనే స్టాండర్డ్ అసర్షన్స్ (standard assertions) విఫలమవుతాయి. ఒకే ప్రాంప్ట్ ప్రతిసారీ వేర్వేరు వాక్యాలను ఇవ్వవచ్చు, కాబట్టి assertEqual(output, expected) మోడల్ సరిగ్గా పనిచేసినప్పటికీ వైఫల్యాన్ని సూచిస్తుంది. చాలా ఇంజనీరింగ్ గ్రూపులు ఫీచర్‌ను ఎటువంటి వెరిఫికేషన్ లేకుండా షిప్ చేస్తాయి లేదా మోడల్‌ను ఒక స్టాటిక్ లైబ్రరీలా భావించి, నిరంతరం మారుతున్న లక్ష్యాన్ని టెస్ట్ చేయడానికి ప్రయత్నిస్తాయి.

ఈ సమస్య ఎందుకు ముఖ్యమైనది

LLMs ఇప్పుడు కస్టమర్-ఫేసింగ్ వర్క్‌ఫ్లోలలో—ఈమెయిల్ అవుట్‌రీచ్, సపోర్ట్ రిప్లైలు, కంటెంట్ జనరేషన్ వంటి వాటిలో భాగంగా ఉన్నాయి. ఒకే ఒక హాలూసినేటెడ్ ఫ్యాక్ట్ (hallucinated fact) లేదా లీక్ అయిన ఐడెంటిఫైయర్ బ్రాండ్ ప్రతిష్టను దెబ్బతీయవచ్చు, ప్రైవేట్ డేటాను బహిర్గతం చేయవచ్చు లేదా కంప్లయన్స్ ఉల్లంఘనలకు దారితీయవచ్చు. నమ్మకమైన టెస్ట్ స్ట్రాటజీ లేకపోతే, టీమ్‌లు ఫ్లేకీ ఫెయిల్యూర్స్ (flaky failures) కోసం సమయాన్ని వృథా చేస్తాయి లేదా ప్రొడక్షన్‌లో మాత్రమే బయటపడే బగ్‌లను షిప్ చేస్తాయి.

విధానం: మోడల్ యొక్క బాధ్యతను తగ్గించడం

మొదటి దశ LLM నిజంగా ఏమి చేయాలో పరిమితం చేయడం. రచయిత యొక్క సిస్టమ్‌లో మోడల్ కేవలం అవుట్‌రీచ్ మెసేజ్‌లను మాత్రమే డ్రాఫ్ట్ చేస్తుంది. మొత్తం రూటింగ్ లాజిక్, స్టేట్ మేనేజ్‌మెంట్ మరియు సేఫ్టీ చెక్‌లు సాధారణ కోడ్‌లోనే ఉంటాయి. మోడల్‌ను ఒకే ఒక స్పష్టమైన అవుట్‌పుట్‌కు పరిమితం చేయడం ద్వారా, చుట్టూ ఉన్న సిస్టమ్ డిటర్మినిస్టిక్ (deterministic) గా మరియు టెస్టబుల్ (testable) గా ఉంటుంది.

దీనిని సాధ్యం చేయడానికి, LLM ఒక provider interface వెనుక ఉంటుంది, దీనివల్ల టెస్టులలో fake వెర్షన్‌ను ఉపయోగించడానికి వీలవుతుంది. ప్రొడక్షన్‌లో ఇంప్లిమెంటేషన్ ఎక్స్‌టర్నల్ APIని పిలుస్తుంది; టెస్ట్ సూట్‌లో ఒక లైట్‌వెయిట్ fake వెర్షన్ ముందే సిద్ధం చేసిన (canned) రెస్పాన్స్‌ను తిరిగి ఇస్తుంది. మిగిలిన కోడ్ కేవలం ఇంటర్‌ఫేస్‌తో మాత్రమే ఇంటరాక్ట్ అవుతుంది కాబట్టి, నెట్‌వర్క్‌ను తాకని యూనిట్ టెస్టుల ద్వారా మొత్తం వర్క్‌ఫ్లోను పరీక్షించవచ్చు. దీని ఫలితం 28 టెస్టులు ధృవీకరించే ఒక ప్రిడిక్టబుల్ కోర్ (predictable core).

ఒక నిజాయితీతో కూడిన ఎవాల్యుయేషన్ హార్నెస్

పరిధిని తగ్గించినప్పటికీ, మోడల్ అవుట్‌పుట్ నాన్-డిటర్మినిస్టిక్ (nondeterministic) గానే ఉంటుంది. అందువల్ల రచయిత మూడు పొరల మూల్యాంకన హార్నెస్ (evaluation harness)ను నిర్మించారు, ప్రతి పొర ఒక రకమైన రిస్క్‌ను నిర్వహిస్తుంది.

  • Layer 1 – Deterministic checks సింపుల్ రెగ్యులర్-ఎక్స్‌ప్రెషన్ రూల్స్ తప్పు బిల్డింగ్ ID లేదా నిషేధించబడిన టోకెన్‌ల వంటి నిర్దిష్ట లోపాలను గుర్తిస్తాయి. ఈ చెక్‌లు వేగంగా ఉంటాయి మరియు బైనరీ pass/fail ఫలితాలను ఇస్తాయి.

  • Layer 2 – Heuristic checks స్క్రిప్ట్‌లు హాలూసినేటెడ్ నంబర్లు లేదా తేదీల కోసం వెతుకుతాయి, స్పష్టమైన వాస్తవాల తప్పులను (factual fabrications) గుర్తిస్తాయి. సంఖ్యాపరమైన సూచనలు లేని తప్పుడు వాదనలను ఇవి గుర్తించలేవు, మరియు రచయిత ఈ పరిమితిని బహిరంగంగా అంగీకరించారు.

  • Layer 3 – LLM judge సెకండరీ మోడల్ టోన్ మరియు ప్రొఫెషనలిజం రేటింగ్‌ను ఇస్తుంది. ఈ దశ మరొక ప్రాబబిలిస్టిక్ సిస్టమ్ (probabilistic system) పై ఆధారపడి ఉంటుంది కాబట్టి, డిటర్మినిస్టిక్ రూల్స్ సాధ్యం కాని సబ్జెక్టివ్ అంశాల కోసం మాత్రమే దీనిని ఉపయోగిస్తారు.

ఈ హార్నెస్ యొక్క కీలకం మూల్యాంకనం కోసం ఉపయోగించే డేటాసెట్. రచయిత తెలిసిన ఫెయిల్యూర్ ప్యాటర్న్స్‌ను—నిర్దిష్ట ట్రాప్స్ మరియు డొమైన్ నాలెడ్జ్‌ను—ఎన్‌కోడ్ చేశారు, తద్వారా హార్నెస్ ప్రాక్టికల్‌గా ఎదురైన తప్పులను ఖచ్చితంగా పరీక్షిస్తుంది. ఇది ఒక మ్యాజికల్ “catch-all” కాదు కానీ ఒక టార్గెటెడ్ సేఫ్టీ నెట్.

టీమ్స్ కోసం దీని అర్థం ఏమిటి

  • LLM యొక్క పనిని చిన్నదిగా ఉంచండి. బాధ్యతలు తక్కువగా ఉంటే ఐసోలేషన్ మరియు టెస్టింగ్ సులభమవుతుంది.
  • రూటింగ్, స్టేట్ మరియు సేఫ్టీని కోడ్‌లో ఉంచండి. సాంప్రదాయ లాజిక్ డిటర్మినిస్టిక్ గా మరియు పూర్తిగా టెస్టబుల్ గా ఉంటుంది.
  • మోడల్‌ను ఒక fakeable interface ద్వారా ఎక్స్‌పోజ్ చేయండి. యూనిట్ టెస్టులు ఎక్స్‌టర్నల్ కాల్స్ లేకుండా నడుస్తాయి, దీనివల్ల టెస్ట్ సూట్ వేగంగా మరియు నమ్మదగినదిగా ఉంటుంది.
  • మీ మూల్యాంకనాలను లేయర్‌లుగా విభజించండి. డిటర్మినిస్టిక్ రూల్స్‌తో ప్రారంభించండి, తెలిసిన హాలూసినేషన్ల కోసం హ్యూరిస్టిక్స్‌ను జోడించండి, మరియు సబ్జెక్టివ్ క్వాలిటీ చెక్‌ల కోసం LLM జడ్జీలను కేటాయించండి.
  • పరిమితులను స్పష్టం చేయండి. ఏ పొర కూడా పరిపూర్ణతను గ్యారెంటీ చేయదు; మీరు దేనిని గుర్తించమని ప్రోగ్రామ్ చేస్తారో హార్నెస్ దానిని మాత్రమే పట్టుకుంటుంది.

ప్రతికూల అంశం: మీరు మోడల్‌ను నేరుగా యూనిట్-టెస్ట్ చేయలేరు

మోడల్ అనేది నిరంతరం మారుతున్న లక్ష్యం (moving target) అని రచయిత అంగీకరిస్తున్నారు. LLM జడ్జ్ లేయర్ కూడా అది అంచనా వేయడానికి ప్రయత్నించే అదే నాన్-డిటర్మినిజంను కలిగి ఉంటుంది. తత్ఫలితంగా, ప్రతి హాలూసినేషన్ లేదా పాలసీ ఉల్లంఘన విడుదల కంటే ముందే పట్టుకోబడుతుందని ఈ సిస్టమ్ ఎప్పటికీ గ్యారెంటీ ఇవ్వలేదు. ఈ విధానం రిస్క్‌ను తగ్గిస్తుంది కానీ పూర్తిగా తొలగించదు, మరియు కొత్త ఫెయిల్యూర్ మోడ్స్ కనిపించినప్పుడు ఎవాల్యుయేషన్ డేటాను అప్‌డేట్ చేయడంలో టీమ్ యొక్క సామర్థ్యంపై ఇది ఆధారపడి ఉంటుంది.

ముగింపు

మీరు LLM యొక్క ఖచ్చితమైన అవుట్‌పుట్‌ను అస్సర్ట్ చేసే క్లాసిక్ యూనిట్ టెస్ట్‌ను వ్రాయలేరు, కానీ మోడల్ యొక్క ప్రభావం పరిమితంగా ఉండేలా, దాని ఇంటర్‌ఫేస్ మార్చదగినదిగా ఉండేలా మరియు దాని అవుట్‌పుట్ లేయర్డ్, ట్రాన్స్‌పరెంట్ చెక్‌ల ద్వారా స్క్రీనింగ్ చేయబడేలా ఒక సిస్టమ్‌ను మీరు నిర్మించగలరు. ఆ కలయిక ఒక ఫ్లేకీ కాంపోనెంట్‌ను పెద్ద, టెస్టబుల్ అప్లికేషన్‌లో ఒక ప్రిడిక్టబుల్ భాగంగా మారుస్తుంది.