Watengenezaji sasa wanaweza kudhibiti gharama ya kurekebisha JSON iliyoharibika kutoka kwa mifumo ya lugha kubwa (LLMs) kwa kuweka kikomo cha majaribio mawili ya ukarabati, kama loop rahisi ya Python inavyoonyesha. Mtindo huu—tengeneza, changanua, thibitisha, jaribu tena, kisha kubali au shindwa—huubadilisha "JSON inayoweza kuwa sahihi" kuwa kiwango cha mafanikio kinachopimika na kuzuia matumizi ya tokeni yasiyodhibitiwa.

Kwa nini loop ya ukarabati ni muhimu

LLMs mara nyingi hupewa maelekezo ya "kurudisha JSON," lakini matokeo mara nyingi huwa na makosa ya sintaksia, funguo (keys) zilizokosekana, au thamani zinazovunja kanuni za biashara. Mfumo unaofuata (downstream system) unaotarajia data iliyopangwa vizuri utafeli au kutoa matokeo yasiyo sahihi ukipokea matokeo kama hayo. Bila njia ya kimfumo ya kukamata na kurekebisha matatizo haya, timu ama hukubali kiwango kikubwa cha kushindwa au hupoteza pesa kwa kuipa modeli maelekezo (prompts) mara kwa mara hadi inapopata jibu sahihi.

Tabaka tatu za uthibitishaji

Loop inayofaa hutenganisha uthibitishaji katika:

  • Syntax – je, mfululizo wa maandishi (string) unaweza kuchanganuliwa kama JSON kabisa?
  • Shape – je, kitu cha ngazi ya juu (top-level object) kina funguo zote zinazotarajiwa?
  • Semantic – je, thamani zinafuata vizuizi vya uwanja (kwa mfano, "category" lazima iwe katika seti iliyofafanuliwa mapema)?

Kwa kusimama kwenye tabaka la kwanza linalofeli, loop inaweza kuipa modeli ujumbe sahihi wa kosa, jambo ambalo huongeza kwa kiasi kikubwa nafasi ya kurekebishwa kwa usahihi katika jaribio linalofuata.

Mfano rahisi wa Python

Msimbo (code) ufuatao unatumia maktaba ya kawaida (standard library) pekee. Unafafanua schema ndogo (kamusi yenye funguo za category na summary) na orodha iliyopangwa ya kategoria zinazoruhusiwa.

import json

CATEGORIES = {"bug", "feature", "question"}

def validate(raw: str):
    try:
        value = json.loads(raw)
    except json.JSONDecodeError as exc:
        return None, f"syntax: {exc.msg}"

    if not isinstance(value, dict):
        return None, "shape: root must be an object"
    if set(value) != {"category", "summary"}:
        return None, "shape: expected category and summary"
    if value["category"] not in CATEGORIES:
        return None, "semantic: invalid category"
    if not isinstance(value["summary"], str) or not value["summary"].strip():
        return None, "semantic: summary must be text"

    return value, None

Loop yenyewe ya ukarabati huweka kikomo cha juu cha majaribio:

MAX_ATTEMPTS = 2
raw = model_response   # initial LLM output

for attempt in range(MAX_ATTEMPTS + 1):
    value, error = validate(raw)
    if error is None:
        break
    if attempt == MAX_ATTEMPTS:
        raise RuntimeError(f"failed after {MAX_ATTEMPTS} retries: {error}")

    # Send the error and schema back to the model for a fix
    raw = ask_model_to_repair(raw, error)

Ikiwa JSON itapita katika uthibitishaji mara ya kwanza, loop itajisimamisha mara moja. Vinginevyo, inajaribu tena kwa kuipa modeli data fupi: matokeo ya awali, mfululizo sahihi wa kosa, na schema inayotarajiwa. Baada ya majaribio mawili ya kushindwa, mchakato unakatishwa na kutoa kosa (exception) la wazi.

Kanuni mbili kwa ajili ya ukarabati wenye gharama nafuu

  1. Weka prompts za ukarabati ziwe fupi – Jumuisha JSON ghafi pekee, ujumbe wa kosa, na schema. Kuongeza historia ndefu ya mazungumzo huongeza matumizi ya tokeni na inaweza kuichanganya modeli, jambo linaloongeza gharama kwa kila jaribio bila kuboresha usahihi.

  2. Tenganisha uthibitishaji na uhakiki wa ukweli – Mchanganuzi (parser) unaweza kugundua matatizo ya kimuundo, lakini hauwezi kuthibitisha ikiwa taarifa ya "summary" ni ya kweli. Uhakiki wa ukweli (fact-checking) ni wa katika hatua ya baadaye; kujaribu "kurekebisha" dai la uongo huifanya tu uongo huo uonekane nadhifu zaidi.

Kupima mafanikio

Kuweka kumbukumbu (logging) ya aina ya kosa la kila jaribio (sintaksia, umbo, semantic) na ikiwa loop ilifanikiwa kunatoa kipimo madhubuti: uwiano wa majibu ya LLM yanayoweza kutumika ndani ya majaribio yaliyowekwa kikomo. Timu zinaweza kufuatilia hili kwa muda, kulinganisha mitindo ya prompt, au kufanya majaribio ya tafsiri tofauti za schema.

Hasara zinazoweza kutokea

Kuweka kikomo kwenye loop inamaanisha baadhi ya matokeo yaliyoharibika yatatupwa baada ya kikomo kufikiwa, jambo ambalo linaweza kuongeza kiwango cha jumla cha kushindwa ikiwa ubora wa awali wa modeli ni mdogo. Katika mazingira ambapo kila jibu ni muhimu, watengenezaji wanaweza kupendelea kikomo cha juu cha majaribio kwa gharama ya tokeni za ziada. Chaguo ni wazi: gharama zaidi kwa utendaji mpana, au bajeti finyu yenye kikomo kinachotabirika.

Nini cha kufuatilia baadaye

  • Prompt engineering kwa ajili ya ukarabati – Kuboresha muundo wa ujumbe wa kosa kunaweza kupunguza idadi ya majaribio yanayohitajika.
  • Parsers mbadala – Baadhi ya maktaba hutoa uchanganuzi unaovumilia makosa unaoweza kurekebisha matatizo madogo kiotomatiki; kulinganisha gharama zao dhidi ya loop yenye kikomo kunafaa kufanywa.
  • Sasisho za modeli – Matoleo mapya ya LLM yanaweza kutoa JSON safi zaidi moja kwa moja, jambo linaloweza kuruhusu kikomo cha majaribio kupunguzwa zaidi.

Loop ya ukarabati wa JSON yenye kikomo inawapa watengenezaji zana ya vitendo ya kugeuza matokeo ya LLM yasiyoeleweka kuwa data inayofaa bila kuongezeka kwa gharama. Kwa kuchukua uthibitishaji kama hatua muhimu na kuweka kikomo cha majaribio, timu zinaweza kuweka bajeti na mifumo inayofuata katika hali nzuri.