నేను ఒకసారి ఒక బ్రాండ్ వెబ్సైట్ను నిర్మించమని AIని అడిగాను. మొదటి చూపులో అది నమ్మదగ్గదిగా అనిపించినప్పటికీ, నిజంగా ముఖ్యమైన విషయాల్లో అది విఫలమైంది. హెడర్లో సరిగ్గా రెండు లింక్లు మాత్రమే ఉన్నాయి. ఎక్కడా "About" పేజీ లేదు. బ్యాకెండ్లో ఒక అడ్మిన్ ప్యానెల్ ఉంది, కానీ ఫ్రంటెండ్లో దానికి చేరువయ్యేలా ఏ బటన్ లేదా రూట్ లేదు. సర్వర్ సైడ్ పని చేసింది, కానీ యూజర్ సైడ్ పని చేయలేదు.
ఇలా ఎదురైన చాలామంది AI బద్ధకపడిందని లేదా టోకెన్ లిమిట్ను చేరుకుందని అనుకుంటారు. కానీ అది జరగడం లేదు. సమస్య నిర్మాణాత్మకమైనది (structural). AI కోడింగ్ టూల్స్ అంతర్గత స్థిరత్వాన్ని (internal consistency) పర్యవేక్షించడానికి రూపొందించబడ్డాయి. అవి "నేను ప్రకటించినవన్నీ ఒకదానితో ఒకటి సరిపోలుతున్నాయా?" అని అడుగుతాయి. కానీ "ఈ డెలివరబుల్లో ఉండాల్సినవన్నీ ఇందులో ఉన్నాయా?" అని అడగవు. మీరు మీ బ్రాండ్ సైట్ కోసం రెండు పేజీలను పేర్కొంటే, ఆ రెండు పేజీలు ఒకదానికొకటి లింక్ అయ్యాయో లేదో మోడల్ శ్రద్ధగా తనిఖీ చేస్తుంది. లింక్లు సరిగ్గా ఉంటే, పని పూర్తయిందని అది భావిస్తుంది. ఒక బ్రాండ్ సైట్కు 'About' పేజీ, నమ్మకాన్ని కలిగించే అంశాలు (trust signals), లేదా కాంటాక్ట్ మార్గం అవసరమనే అవగాహన దానికి సహజంగా ఉండదు. దాని మెదడులో ఎటువంటి ప్రమాణం (standard) లేదు.
ఈ సమస్యకు పరిష్కారాన్ని నేను Completeness Baseline అని పిలుస్తాను.
Completeness baseline అంటే ఒక డెలివరబుల్లో ఉండాల్సిన అంశాల యొక్క ప్రామాణిక చెక్లిస్ట్. మీరు ఆర్టిఫాక్ట్ను (artifact) రూపొందించిన తర్వాత, టూల్ యొక్క అంతర్గత "పూర్తయింది" అనే భావనను నమ్మడానికి బదులుగా, ఈ బాహ్య ప్రమాణంతో వాస్తవ అవుట్పుట్ను సరిపోల్చుకోవాలి.
మూడు పొరల ద్వారా తనిఖీ చేయడం
అన్ని లోపాలు ఒకేలా స్పష్టంగా ఉండవు. ఒక ఉపయోగకరమైన బేస్లైన్ మూడు విభిన్న పొరలను తనిఖీ చేస్తుంది.
ఉనికి (Existence). ఆ భాగం నిజంగా ఉందా? ఇది చాలా ప్రాథమికంగా అనిపించవచ్చు, కానీ ఒక AI డ్యాష్బోర్డ్ పేజీని సృష్టించకుండానే, ఆ పేజీని రిఫరెన్స్ చేసే నావిగేషన్ రాపర్ను (navigation wrapper) సంతోషంగా నిర్మిస్తుంది. రిఫరెన్స్ ఉంటుంది, కానీ టార్గెట్ ఉండదు.
చేరువయ్యే సామర్థ్యం (Reachability). ఒక నిజమైన వినియోగదారు నిజంగా అక్కడికి చేరుకోగలరా? దాగి ఉన్న అడ్మిన్ ప్యానెల్స్ దీనికి క్లాసిక్ ఉదాహరణలు. కోడ్బేస్లో రూట్ మరియు కాంపోనెంట్ రెండూ ఉండవచ్చు, కానీ ఏ మెనూ ఐటమ్, బటన్ లేదా రీడైరెక్ట్ కూడా వాటిని ఇంటర్ఫేస్కు చూపించకపోవచ్చు. సాధారణ వినియోగంలో ఒక వినియోగదారు దాన్ని చూడలేకపోతే, అది నిజంగా అక్కడ లేనట్టే.
నిరూపణ (Substantiation). ఉపరితలం వెనుక నిజమైన డేటా లేదా నిర్మాణం ఉందా? లోడ్ అయ్యే ఒక పేజీలో కేవలం ప్లేస్హోల్డర్ టెక్స్ట్ మాత్రమే ఉండి, ఇమేజ్ అప్లోడ్ స్లాట్ లేకపోతే, అది కేవలం ఒక డ్రెస్ వేసుకున్న అస్థిపంజరం లాంటిది. ఇమేజ్ స్లాట్ లేదా ఎడిటబుల్ టెక్స్ట్ ఫీల్డ్ లేని 'About' పేజీ, HTML స్పష్టంగా కనిపించినప్పటికీ, అది సంపూర్ణం కాదు.
ఈ మూడు పొరలు వేర్వేరు రకాల లోపాలను గుర్తిస్తాయి. Existence పోయిన షూను గుర్తిస్తుంది. Reachability బీరువాలో లాక్ చేయబడిన షూను గుర్తిస్తుంది. Substantiation అడుగు లేని షూను గుర్తిస్తుంది.
రకాన్ని బట్టి బేస్లైన్లు
ఒకే బేస్లైన్ ప్రతి ప్రాజెక్ట్కు సరిపోదు. మీరు ఏమి నిర్మిస్తున్నారో వర్గీకరించాలి మరియు ఆ కేటగిరీకి సంబంధించి తప్పనిసరి అంశాలను (non-negotiables) నిర్వచించాలి.
బ్రాండ్ సైట్లకు (Brand sites) నిర్దిష్ట విభాగాలు మరియు చేరువయ్యే పేజీలు అవసరం. About, Contact, ప్రైవసీ లింక్లు మరియు ప్రతి ప్రధాన వ్యూను చూపే నావిగేషన్ వంటి వాటిని గుర్తుంచుకోండి.
APIsలకు డాక్యుమెంటేషన్, సమగ్రమైన ఎర్రర్ కోడ్లు మరియు రేట్ లిమిట్లు అవసరం. సక్సెస్ కోసం 200 OK మరియు మిగిలినవన్నీ కోసం జనరిక్ 500 రిటర్న్ చేసే వర్కింగ్ ఎండ్పాయింట్ పూర్తిస్థాయి API కాదు. అది ఒక ప్రమాదం.
ఆటోమేషన్లకు (Automations) లాగ్లు మరియు ఫెయిల్యూర్ అలర్ట్లు అవసరం. ఒక వర్క్ఫ్లో తెల్లవారుజామున 2 గంటలకు విఫలమైతే మరియు మనిషి రన్ హిస్టరీని తనిఖీ చేసే వరకు ఎవరికీ తెలియకపోతే, ఆ ఆటోమేషన్ అసంపూర్ణం. అబ్జర్వబిలిటీ (Observability) అనేది అదనపు ఫీచర్ కాదు. అది డెలివరబుల్లో భాగం.
మీరు కేటగిరీని నిర్ణయించిన తర్వాత, బేస్లైన్ దానంతట అదే తయారవుతుంది. కోడ్ జనరేట్ అయిన తర్వాత దానిని అమలు చేయడం (enforcing) కష్టమైన పని.
నిలకడగా ఉండే డిజైన్ నియమాలు
నేను నా స్వంత వర్క్ఫ్లోను ఈ ఆలోచన చుట్టూ మళ్ళీ నిర్మించుకున్నాను మరియు ప్రాజెక్ట్లు క్రమంగా విచ్ఛిన్నం కాకుండా ఉండే మూడు ఆచరణాత్మక నియమాలను రూపొందించుకున్నాను.
కెపాబిలిటీ-గేటెడ్ డిజైన్ (Capability-gated design). మీరు ఏదైనా టూల్ లేదా జనరేట్ చేయబడిన మాడ్యూల్ను ఎంచుకునే ముందు, అది నిజంగా ఏమి చేయగలదో గుర్తించండి. ఒక కాంపోనెంట్ లైబ్రరీలో నేటివ్ మొబైల్ డ్రాయర్ సపోర్ట్ లేకపోతే, అది ఉందని ఊహించి పూర్తి నావిగేషన్ స్కీమ్ను AIని రూపొందించనివ్వకండి. సామర్థ్యం లేనప్పుడు సిస్టమ్ విచ్ఛిన్నం కాకుండా, క్రమంగా తగ్గుతూ (degrade gracefully) ఉండాలి. ముందుగా పరిమితులను తెలుసుకోండి. వాటి లోపలే డిజైన్ చేయండి.
పబ్లిక్ ఇంజిన్, ప్రైవేట్ వాల్యూస్ (Public engine, private values). భారీ పనుల కోసం పబ్లిక్ ఇంజిన్ను ఉపయోగించండి, కానీ మీ ప్రైవేట్ డేటా, కాన్ఫిగరేషన్లు మరియు కన్వెన్షన్లను రన్టైమ్లో ఇంజెక్ట్ చేయండి. ఇది మీ వ్యక్తిగత లేదా కంపెనీ పద్ధతులను జనరేట్ చేయబడిన స్క్యాఫోల్డ్ (scaffold) నుండి సురక్షితంగా మరియు వేరుగా ఉంచుతుంది. AI ఫ్రేమ్ను నిర్మిస్తుంది. మీరు అందులో గ్లాస్ను అమర్చుతారు. ఇది మోడల్ మీ అసలు ప్రమాణాలను ఉల్లంఘించేలా లేదా సెన్సిటివ్ ప్యాటర్న్లను పబ్లిక్ ట్రైనింగ్ కాంటెక్స్ట్లలో లీక్ చేసేలా హార్డ్-కోడ్ చేయకుండా నిరోధిస్తుంది.
ప్రతిపాదించండి, ఆటోమేటిక్గా ముందుకు వెళ్లనివ్వకండి. AI తదుపరి దశను సూచించనివ్వండి, కానీ నిర్ణయం తీసుకోవడానికి మనిషిని మాత్రమే అనుమతించండి. అమలు ప్రక్రియను (flow of execution) ఆటోమేట్ చేయండి, కానీ తీర్పును (judgment) కాదు. ఒక మోడల్ ఒకే శ్వాసలో డేటాబేస్ మైగ్రేషన్, ఒక ఆథ్ స్కీమ్ (auth scheme), మరియు ఒక పేమెంట్ హుక్ను ఆటోమేటిక్గా జనరేట్ చేసినప్పుడు, మీరు పర్యవేక్షణను కోల్పోయి సౌకర్యాన్ని మాత్రమే పొందుతారు. టూల్ ప్లాన్ను మాత్రమే చూపాలి. డెవలపర్ బటన్ నొక్కేలా చూడండి.
పనికి తగిన మోడల్ను ఎంచుకోవడం
నేను వివిధ మోడల్స్పై దీనిని పరీక్షించాను మరియు వాటి విలువలో స్పష్టమైన తేడాను గమనించాను. తక్కువ ధర కలిగిన మోడల్స్ యాంత్రికమైన భారీ పనులను (mechanical bulk) ఆశ్చర్యకరంగా బాగా నిర్వహిస్తాయి. మీరు టైప్ చేసే వేగం కంటే వేగంగా అవి బాయిలర్ప్లేట్ (boilerplate), పునరావృతమయ్యే కాంపోనెంట్స్ మరియు స్ట్రక్చరల్ స్టబ్బ్లను సిద్ధం చేస్తాయి. ఖరీదైన మోడల్స్ వాటి ధరను అదరగొట్టాలంటే, అవి సంయమనాన్ని ప్రదర్శించినప్పుడే అది సాధ్యమవుతుంది. తప్పుడు పరిష్కారాలను సృష్టించకుండా, అసలైన లోపాన్ని గుర్తించినప్పుడు మీరు ప్రీమియం ఆప్షన్ను కోరుకుంటారు. ఒక మిస్సింగ్ API ఎండ్పాయింట్కు తప్పుడు పరిష్కారాన్ని (hallucinate a workaround) సృష్టించే మోడల్ ప్రమాదకరం. కానీ, "ఈ వర్క్ఫ్లోకు నిర్వచించబడని వెబ్హుక్ టార్గెట్ అవసరం" అని ఆగి చెప్పే మోడల్ ఖచ్చితంగా ఆ ధరకు తగినది. పరిమాణం (volume) కోసం కాకుండా, విచక్షణ (discernment) కోసం డబ్బు చెల్లించండి.
బిల్డ్ సిస్టమ్స్ను నిర్మించండి, మ్యాజిక్ కోసం వెతకకండి
పెద్ద మోడల్స్ను లేదా మరిన్ని ప్రాంప్టింగ్ ట్రిక్స్ను ఉపయోగించి AI లోపాలను సరిదిద్దడానికి ప్రయత్నించకండి. వాటిని ఒక బేస్లైన్తో (baseline) సరిదిద్దండి. ఆ లోపం సామర్థ్యానికి (capacity) సంబంధించిన సమస్య కాదు, అది అంచనాల (expectations) సమస్య.
మిస్సింగ్ బ్లాక్స్ను ఆపడానికి, ఈ మూడు పనులు చేయండి.
ఏ కోడ్ రాయకముందు సిస్టమ్కు ఒక కంప్లీట్నెస్ బేస్లైన్ను అందించండి. దానిని టాస్క్తో పాటు ఉండే ఒక ఫిజికల్ చెక్లిస్ట్గా మార్చండి.
మీ కన్వెన్షన్స్ను (conventions) తిరిగి ఉపయోగించదగిన భాగాలలో (reusable parts) చేర్చండి. మీరు టెంప్లేట్లు, లింట్ రూల్స్ లేదా ప్రీ-బిల్ట్ స్కాఫోల్డ్స్ ద్వారా మీ బేస్లైన్ను అమలు చేస్తే, AI మీ ప్రమాణాలను ఊహించే వరకు వేచి చూడకుండా, సరైన స్థితి నుండి పనిని ప్రారంభిస్తుంది.
తీర్పు తీసుకునే అధికారం మనిషి వద్దే ఉంచుతూ, ఫ్లోను ఆటోమేట్ చేయండి. పునరావృతమయ్యే పనులను యంత్రాలకు వదిలేయండి. సందర్భాన్ని (context) అర్థం చేసుకునే వ్యక్తుల కోసం నిర్ణయాలను ఉంచండి.
నా పని విధానాన్ని మార్చిన చివరి అలవాటు ఇది. మీరు ఒకే డిజైన్ నిర్ణయాన్ని ఏడుసార్లు తీసుకుంటే, దానిని ఒకసారి తీసుకున్న నిర్ణయంగా చూడటం ఆపండి. అది కేవలం పునరావృతం కాదు, అది ఒక నియమం. దానికి ఒక పేరు పెట్టండి. దానిని ఒక రూల్గా మార్చండి. డాక్యుమెంట్ చేయండి. మీరు ఆ ప్యాటర్న్ను కోడిఫై (codify) చేసినప్పుడు, ఎనిమిదవ సారి AI దాని నుండి తప్పుదారి పట్టే అవకాశం ఉండదు.
ఈ ఫ్రేమ్వర్క్ మరియు అసలు పరిశోధన యొక్క మూలాన్ని ఇక్కడ చూడవచ్చు.
అదే సమస్యలతో పోరాడుతున్న ఇతరులతో కలిసి చర్చించాలనుకుంటే, మీరు GyaanSetu learning communityలో చేరవచ్చు.