Foreman, large-language-model (LLM) ఏజెంట్లను నేటివ్ Kubernetes రిసోర్స్‌లుగా మారుస్తుంది, దీనివల్ల బృందాలు ఖర్చులను మరియు భద్రతను కఠినంగా నియంత్రిస్తూనే, AI-జనరేటెడ్ కోడ్‌ను ప్రొడక్షన్‌లో రన్ చేయవచ్చు.

ఈ ఆలోచన నేటి డెవ్ (dev) వర్క్‌ఫ్లోలోకి ఎలా సరిపోతుంది

ఎంటర్‌ప్రైజ్‌లు కోడ్ రాయగల LLMలతో ప్రయోగాలు చేస్తున్నాయి, కానీ చాలా అమలులు (implementations) మోడల్‌ను ఒక నమ్మదగిన బ్లాక్ బాక్స్‌గా పరిగణిస్తాయి. మోడల్ నుండి వచ్చే ఒకే ఒక్క “done” సిగ్నల్, పరీక్షించని మార్పులను నేరుగా రిపోజిటరీలోకి పంపవచ్చు, ఇది భద్రత మరియు విశ్వసనీయతపై ఆందోళనలను పెంచుతుంది. అదే సమయంలో, క్లౌడ్‌లో AI సర్వీసులను రన్ చేయడం ఖరీదైనదిగా మారవచ్చు, ముఖ్యంగా CI పైప్‌లైన్‌ల నుండి ఒకే మోడల్‌ను పదేపదే పిలిచినప్పుడు.

కోడింగ్ లూప్‌ మొత్తాన్ని Kubernetes క్లస్టర్ లోపల ఉంచడమే Foreman పరిష్కారం. Foreman, Kubernetes రిసోర్స్‌లుగా రన్ అవుతుంది.

ఇది సాధ్యం చేసే నాలుగు ప్రధాన ఆబ్జెక్ట్‌లు

  • Agent – ఒక వర్కర్‌ను నిర్వచిస్తుంది. ఇది పిలవాల్సిన LLM పేరును, మోడల్ ఉపయోగించగల టూల్స్ జాబితాను (ఉదా: file-write లేదా git-push) పేర్కొంటుంది మరియు మోడల్ కాల్స్‌ను పరిమితం చేసే బడ్జెట్‌ను సెట్ చేస్తుంది. ఇక్కడ రోల్స్ (Roles) జత చేయబడతాయి; ఒక coder agent కోడ్‌ను రాస్తుంది, ఒక verifier agent దానిని తనిఖీ చేస్తుంది.
  • Workload – వినియోగదారు రాసిన పని యూనిట్. ఇది హై-లెవల్ ఉద్దేశ్యాన్ని (ఉదా: “module X కోసం unit tests జోడించు”), టార్గెట్ రిపోజిటరీ యొక్క రిఫరెన్స్‌ను మరియు ఆ పనిని నిర్వహించాల్సిన ఏజెంట్ల జాబితాను కలిగి ఉంటుంది.
  • AgenticTask – Workload ద్వారా సృష్టించబడే నిర్దిష్టమైన టాస్క్. పని పురోగమిస్తున్న కొద్దీ, ప్రతి AgenticTask స్టేటస్ అప్‌డేట్‌లను రికార్డ్ చేస్తుంది, దీనివల్ల ఆపరేటర్లు పైప్‌లైన్‌ను రియల్ టైమ్‌లో పర్యవేక్షించవచ్చు.
  • FleetNode – టాస్క్‌లను నిజంగా రన్ చేసే Kubernetes నోడ్. ఇన్‌బిల్ట్ షెడ్యూలర్ పెండింగ్‌లో ఉన్న AgenticTasksను, అవసరమైన రోల్ మరియు రిసోర్స్‌లు ఉన్న FleetNodesతో మ్యాచ్ చేస్తుంది.

బ్లైండ్ ట్రస్ట్‌కు బదులుగా వెరిఫికేషన్ (Verification)

మోడల్ అవుట్‌పుట్ సరైనదని Foreman ఊహించదు. ఒక coder agent తన పనిని పూర్తి చేసినప్పుడు, అది తుది ఫలితానికి బదులుగా ఒక రిక్వెస్ట్‌ను పంపుతుంది. ఒక verifier—సాధారణంగా ఇది మరొక LLM కాకుండా, ఒక డిటర్మినిస్టిక్ స్క్రిప్ట్—కోడ్‌ను linters, unit tests లేదా ఫుల్ బిల్డ్స్ ద్వారా రన్ చేస్తుంది. ఆ చెక్‌లు పాస్ అయితేనే, Foreman కొత్త బ్రాంచ్‌ను రిపోజిటరీలోకి రాస్తుంది.

ఒకవేళ verifier విఫలమైతే, ఆ టాస్క్ రిజెక్టెడ్ (rejected) గా గుర్తించబడుతుంది మరియు మార్పులు ఎప్పటికీ అప్లై అవ్వవు. ఈ విభజన వల్ల మోడల్ సృజనాత్మకంగా పనిచేయగలదు, అదే సమయంలో భద్రతా వలయం (safety net) పూర్తిగా మానవ నియంత్రణలో ఉంటుంది.

క్లస్టర్‌పై స్టాక్‌ను ఇన్‌స్టాల్ చేయడం

  1. Helm ఉపయోగించి LLMKube కోర్ చార్ట్‌ను డిప్లాయ్ చేయండి.
  2. అలాగే Helm ద్వారానే Foreman చార్ట్‌ను డిప్లాయ్ చేయండి.
  3. రియల్ రిక్వెస్ట్-రెస్పాన్స్ లూప్ యాక్టివ్‌గా ఉండటానికి ఏజెంట్ మోడ్‌ను “native” కి మార్చండి.
  4. పనిని హోస్ట్ చేసే FleetNodesలకు రోల్స్ (coder, verifier) కేటాయించండి.

రెండు క్రెడెన్షియల్ సెట్‌లు అవసరం: ఇష్యూస్‌ను చదవడానికి మరియు బ్రాంచ్‌లను పుష్ చేయడానికి git క్రెడెన్షియల్స్, మరియు హోస్టెడ్ API లేదా సెల్ఫ్-హోస్టెడ్ ఇన్ఫరెన్స్ సర్వీస్‌ను పిలవడానికి మోడల్ క్రెడెన్షియల్స్.

మీరు నిజంగా నియంత్రించగల ఖర్చు మరియు భద్రత అంశాలు

ఏజెంట్ డెఫినిషన్ నుండి టూల్స్‌ను తొలగించడం ద్వారా మోడల్ యొక్క అధికారాన్ని పరిమితం చేయడానికి Foreman ఆపరేటర్లకు అనుమతిస్తుంది. “bash” లేదా “write_file” ను తొలగించడం వల్ల మోడల్ ఏదైనా షెల్ కమాండ్స్‌ను అమలు చేయడం లేదా కేటాయించిన వర్క్‌స్పేస్ వెలుపల రాయడాన్ని నిరోధించవచ్చు.

ఒక టర్న్ లిమిట్ (turn limit) ప్రతి టాస్క్‌కు మోడల్ ఇన్‌వోకేషన్ల సంఖ్యను పరిమితం చేస్తుంది, తద్వారా ఖర్చును నేరుగా నియంత్రించవచ్చు. కాంటెక్స్ట్ విండోను (context window)—మోడల్ ఎంత ప్రాంప్ట్‌ను చూస్తుందో—అడ్జస్ట్ చేయడం ద్వారా టోకెన్ వినియోగాన్ని మరింత తగ్గించవచ్చు. మోడల్ లోకల్‌గా ఆన్-ప్రిమ్ హార్డ్‌వేర్‌పై రన్ అయినప్పుడు, ఎటువంటి డేటా సంస్థ నుండి బయటకు వెళ్లదు, ఇది కఠినమైన డేటా-ప్రైవసీ పాలసీలను సంతృప్తిపరుస్తుంది.

ఈ ప్లాట్‌ఫారమ్ ఎక్కడ మెరుస్తుంది మరియు ఎక్కడ ఇబ్బంది పడుతుంది

Foreman మెకానికల్ మరియు స్పష్టమైన పరిధి ఉన్న పనులలో అద్భుతంగా పనిచేస్తుంది:

  • డాక్యుమెంట్ చేయబడిన బగ్‌ను ఫిక్స్ చేయడం.
  • మిస్ అయిన టెస్ట్ కేస్‌లను జోడించడం.
  • స్పష్టత లేదా స్టైల్ కోసం డాక్యుమెంటేషన్‌ను అప్‌డేట్ చేయడం.

ఈ పనులకు స్పష్టమైన సక్సెస్ క్రైటీరియా ఉంటాయి, వీటిని verifier ఆటోమేటిక్‌గా తనిఖీ చేయగలదు. అయితే, హై-లెవల్ ఆర్కిటెక్చరల్ రీడిజైన్స్ లేదా "సరైనది" అనేది మానవ తీర్పుపై ఆధారపడి ఉండే అస్పష్టమైన ఫీచర్ పనుల విషయంలో ఈ సిస్టమ్ ఇంకా ఇబ్బంది పడుతోంది.

ముగింపు (Takeaway)

LLM-డ్రివెన్ కోడర్లను ఫస్ట్-క్లాస్ Kubernetes రిసోర్స్‌లుగా పరిగణించడం మరియు డిటర్మినిస్టిక్ వెరిఫికేషన్ స్టెప్‌ను అమలు చేయడం ద్వారా, Foreman ఖర్చును కనిపిస్తూ మరియు భద్రతను నియంత్రిస్తూ, ప్రొడక్షన్ AI కోడ్ జనరేషన్‌కు ఒక ప్రాగ్మాటిక్ మార్గాన్ని అందిస్తుంది. ఇది అన్ని డెవలప్‌మెంట్ పనులకు ఒక సిల్వర్ బుల్లెట్ (silver bullet) కాకపోవచ్చు, కానీ పునరావృతమయ్యే, పరీక్షించదగిన పనుల కోసం ఇది ప్రస్తుతం ఉన్న క్లౌడ్-నేటివ్ ఆపరేషన్లకు సహజంగా సరిపోయే ఆడిటబుల్ వర్క్‌ఫ్లోను అందిస్తుంది.