ओलामा में जेईवी समाधान मॉडल: व्यावहारिक उपयोग /v1/systemone

संस्करण 0.35 से शुरू होकर, ओलामा टाइपसेफ से जेईवी एपीआई पर निर्मित निर्णय मॉडल का समर्थन करता है। ये सामान्य अर्थों में चैट मॉडल नहीं हैं: वे पाठ नहीं लिखते हैं, लेकिन स्थानांतरित स्थिति के बारे में टाइप किए गए प्रश्नों के एक सेट का उत्तर देते हैं। वर्गीकरण, रूटिंग, मॉडरेशन और ट्राइएज के लिए, यह एक नियमित एलएलएम से JSON लौटाने के लिए कहने और फिर उसकी प्रतिक्रिया को पार्स करने की तुलना में तेज़ और अधिक विश्वसनीय साबित होता है।

इस पोस्ट में, मैं देखूंगा कि निर्णय मॉडल क्या हैं, वे HTTP स्तर पर कैसे काम करते हैं, कौन से मॉडल पहले से ही उपलब्ध हैं, और उन्हें मौजूदा कोड में कैसे बनाया जाए ताकि नियमित जेनरेटर मॉडल काम करना जारी रखें।

निर्णय मॉडल नियमित मॉडल से किस प्रकार भिन्न हैं

एक नियमित एलएलएम एक संकेत प्राप्त करता है और टोकन द्वारा टेक्स्ट टोकन उत्पन्न करता है। यहां तक ​​कि अगर आप उससे एक शब्द में उत्तर देने के लिए कहते हैं, तब भी पीढ़ी अंदर होती है, और उत्तर के प्रारूप को एक आरेख, निर्देशों और उसके बाद के सत्यापन द्वारा नियंत्रित किया जाना चाहिए। निर्णय मॉडल अलग तरीके से काम करता है: आप प्रकार के साथ स्थिति और प्रश्नों को पास करते हैं, और मॉडल संभावनाओं और चयनित विकल्पों को लौटाता है। कोई निःशुल्क पाठ नहीं, प्रतिक्रिया से कोई JSON पार्सिंग नहीं।

नए समापन बिंदु को /v1/systemone कहा जाता है। एक अनुरोध में, आप एक साथ कई प्रश्न पूछ सकते हैं, और मॉडल उन सभी का उत्तर देगा। यह उन कार्यों के लिए सुविधाजनक है जहां आपको कई संबंधित निर्णय लेने की आवश्यकता होती है: उदाहरण के लिए, टीम का निर्धारण, वापसी की आवश्यकता और टिकट की तात्कालिकता।

कौन से मॉडल उपलब्ध हैं

अब आप ओलामा के माध्यम से तीन निर्णय मॉडल चला सकते हैं:

• फुर्तीला बेस्पोक लैब्स के 9 अरब मापदंडों वाला एक खुला मॉडल है। यह उपलब्ध सबसे बड़ा और सबसे सटीक है।
• tev1 एक प्रायोगिक मॉडल है जिसमें टुगेदर एआई से 4 बिलियन पैरामीटर हैं।
• tev1:0.8b टुगेदर AI के 0.8 बिलियन पैरामीटर वाला एक प्रायोगिक मॉडल है। सबसे तेज़ और आसान.

वे सभी स्थानीय रूप से काम करते हैं, भुगतान की आवश्यकता नहीं होती है और किसी बाहरी सेवा को डेटा नहीं भेजते हैं। ओलामा 0.35 और बाद के संस्करण समर्थित हैं।

स्थापना

पहले ओलामा संस्करण की जाँच करें:

ollama --version

फिर वांछित मॉडल डाउनलोड करें. सबसे आसान के लिए:

ollama pull tev1:0.8b

Tev1 के पूर्ण संस्करण के लिए:

ollama pull tev1

फुर्तीला के लिए:

ollama pull nimble

फुर्तीला मॉडल लगभग 9.5 जीबी डिस्क स्थान लेता है, इसलिए डाउनलोड करने से पहले कुछ स्थान खाली करना एक अच्छा विचार है। Tev1:0.8b एक गीगाबाइट से भी कम समय लेता है।

कर्ल के माध्यम से पहला अनुरोध

सबसे सरल उदाहरण यह निर्धारित करना है कि कोई टेक्स्ट नौकरी का विज्ञापन है या नहीं:

curl http://localhost:11434/v1/systemone -d '{
  "model": "tev1:0.8b",
  "state": {
    "message": "Senior Swift developer, Berlin, remote friendly"
  },
  "questions": {
    "isJob": {
      "type": "noul",
      "instructions": "Does the message advertise a job posting that someone can apply to?"
    }
  }
}'

उत्तर इस प्रकार दिखता है:

{
  "model": "tev1:0.8b",
  "answers": {
    "isJob": {
      "type": "noul",
      "noul": 0.921
    }
  },
  "usage": {
    "input_tokens": 42,
    "output_tokens": 0
  }
}

नॉल फ़ील्ड 0 से 1 तक की संभावना है। निर्णय आमतौर पर 0.5 की सीमा के साथ तुलना करके किया जाता है। जेनरेटिव मॉडल के विपरीत, JSON प्रारूप में प्रतिक्रिया मांगने और फिर जांचने की आवश्यकता नहीं है कि मॉडल ने इसे तोड़ा नहीं है।

प्रश्नों के प्रकार

निर्णय मॉडल तीन प्रकार के प्रश्नों का समर्थन करते हैं।

noul एक द्विआधारी प्रश्न है। किसी कथन के सत्य होने की प्रायिकता लौटाता है:

{
  "questions": {
    "refund": {
      "type": "noul",
      "instructions": "Does the customer explicitly ask for a refund?"
    }
  }
}

विकल्प – दिए गए सेट में से एक विकल्प का चयन करना। चयनित विकल्प, सभी विकल्पों की संभावनाएँ और विश्वास लौटाता है:

{
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": {
        "billing": "Payments and refunds",
        "technical": "Bugs and integrations",
        "other": "None of the above"
      }
    }
  }
}

स्कोर – पैमाने पर रेटिंग। प्रत्येक स्केल बिंदु के लिए संख्या, किंवदंती और संभावनाएं लौटाता है:

{
  "questions": {
    "urgency": {
      "type": "score",
      "instructions": "How urgent is this ticket?",
      "criteria": ["Routine", "Soon", "Urgent"]
    }
  }
}

एक अनुरोध में एक साथ विभिन्न प्रकार के कई प्रश्न हो सकते हैं। यही वह है जो निर्णय मॉडल को ट्राइएज के लिए सुविधाजनक बनाता है: एक ऑपरेशन, एक राज्य, कई स्वतंत्र निर्णय।

अतिरिक्त पुस्तकालयों के बिना पायथन

अनुरोधों के लिए, मानक urllib पर्याप्त है; एक अलग SDK की आवश्यकता नहीं है:

import json
from urllib.request import Request, urlopen

OLLAMA_DECISION_URL = "http://localhost:11434/v1/systemone"

def ask_decision(state, questions, model="tev1:0.8b"):
    payload = {
        "model": model,
        "state": state,
        "questions": questions,
    }
    request = Request(
        OLLAMA_DECISION_URL,
        data=json.dumps(payload).encode(),
        headers={"Content-Type": "application/json"},
        method="POST",
    )
    with urlopen(request, timeout=3600) as response:
        return json.loads(response.read().decode())["answers"]

उपयोग:

answers = ask_decision(
    {"message": "Senior Swift developer, Berlin, remote friendly"},
    {
        "isJob": {
            "type": "noul",
            "instructions": "Does the message advertise a job posting that someone can apply to?"
        }
    },
)

probability = answers["isJob"]["noul"]
is_job = probability >= 0.5

यदि आपको आधिकारिक पायथन एसडीके की आवश्यकता है, तो इसे टाइपसेफ़-एसडीके कहा जाता है। लोकलहोस्ट के लिए, इसे पर्यावरण चर TYPESAFE_BASE_URL, TYPESAFE_API_KEY और TYPESAFE_DEFAULT_MODEL के साथ ओलामा को निर्देशित किया जा सकता है। लेकिन सरल कार्यों के लिए, सीधा HTTP अनुरोध पर्याप्त है।

कैसे समझें कि एक मॉडल निर्णय का समर्थन करता है

निर्णय मॉडल /api/generate या /api/chat के माध्यम से प्रतिक्रिया नहीं दे सकते। यदि आप ऐसा अनुरोध भेजते हैं, तो ओलामा इस पाठ के साथ 400 त्रुटि लौटाएगा:

"tev1:0.8b" does not support generate

यह महत्वपूर्ण है यदि आपके पास पहले से ही कोड है जो /api/generate के माध्यम से नियमित मॉडल के साथ काम करता है: यदि आप मॉडल को निर्णय मॉडल में बदलते हैं, तो यह काम करना बंद कर देगा। /api/show के माध्यम से मॉडल की क्षमताओं का पहले से पता लगाना और उचित कॉलिंग विधि चुनना बेहतर है:

import json
from urllib.request import Request, urlopen

OLLAMA_SHOW_URL = "http://localhost:11434/api/show"

def supports_decision(model):
    request = Request(
        OLLAMA_SHOW_URL,
        data=json.dumps({"model": model}).encode(),
        headers={"Content-Type": "application/json"},
        method="POST",
    )
    try:
        with urlopen(request, timeout=30) as response:
            capabilities = json.loads(response.read().decode()).get("capabilities", [])
    except (OSError, TypeError, ValueError):
        return False
    return "decision" in capabilities

निर्णय मॉडल में उनकी क्षमताओं में केवल निर्णय होगा। नियमित मॉडल में पूर्णता, उपकरण या अन्य सुविधाएं होंगी। यदि ओलामा उपलब्ध नहीं है, तो मॉडल को सामान्य मानना ​​और जेनरेटिव पथ का उपयोग करना उचित है।

मौजूदा कोड में कैसे एम्बेड करें

सबसे आसान तरीका क्लासिफायरियर को फिर से लिखना नहीं है, बल्कि इसे दो रणनीतियों में विभाजित करना है। जेनरेटिव रणनीति पहले की तरह काम करती है: यह प्रॉम्प्ट एकत्र करती है, इसे /api/generate पर भेजती है और JSON को पार्स करती है। निर्णय रणनीति राज्य और टाइप किए गए प्रश्न को /v1/systemone पर भेजती है और संभावना की तुलना सीमा से करती है।

क्लासिफायरियर बनाते समय रणनीति का चुनाव एक ही स्थान पर होता है:

def create_classifier(model):
    if supports_decision(model):
        return DecisionClassifier(model)
    return GenerativeClassifier(model)

इस दृष्टिकोण के कई फायदे हैं. जनरेटिव मॉडल अपरिवर्तित चलते रहते हैं। निर्णय मॉडल को एक पर्यावरण चर को बदलकर सक्षम किया जा सकता है। और दोनों विधियों के बीच का पूरा अंतर दो छोटे वर्गों में केंद्रित है, और पूरे एप्लिकेशन में फैला हुआ नहीं है।

द्विआधारी वर्गीकरण के लिए, निर्णय रणनीति कुछ इस तरह दिखती है:

async def classify(text):
    answers = await ask_decision(
        {"message": text},
        {
            "isJob": {
                "type": "noul",
                "instructions": instructions,
            }
        },
        model,
    )
    probability = answers["isJob"]["noul"]
    return probability >= 0.5, probability

कृपया ध्यान दें कि निर्णय मॉडल कोई स्पष्टीकरण नहीं लौटाता है। यदि आपके परिणाम प्रारूप में कोई कारण फ़ील्ड है, तो आप इसे संभाव्यता से बना सकते हैं: उदाहरण के लिए, संभाव्यता को स्वयं या “मॉडल ने रिक्ति के रूप में संदेश को 0.935 पर रेट किया है” जैसी स्ट्रिंग को संग्रहीत करें। यह उस कारण का आविष्कार करने से अधिक ईमानदार है जो मॉडल ने नहीं दिया।

निर्देश एक प्रश्न होना चाहिए

यह सबसे महत्वपूर्ण व्यावहारिक निष्कर्ष है. निर्णय मॉडल “आप संदेशों को वर्गीकृत करते हैं, सही उत्तर देते हैं…, अन्यथा गलत” की शैली में लंबे संकेतों को नहीं समझते हैं। वे एक छोटा, सीधा प्रश्न चाहते हैं।

रिक्ति के बारे में उसी संदेश पर, मुझे निम्नलिखित संभावनाएँ प्राप्त हुईं:

• सीधा प्रश्न “क्या यह संदेश नौकरी पोस्टिंग है?” — 0.921.
• रिक्त किसे माना जाता है, इसकी व्याख्या करने वाले लंबे निर्देश – 0.026।
• अंत में एक प्रश्न के साथ लंबे निर्देश – 0.391.

अंतर लगभग तीस गुना है. वर्गीकरण में मॉडल की गलती नहीं है, जब प्रश्न पैराग्राफ के अंदर छिपा होता है तो उसे यह समझ में नहीं आता कि वे उससे क्या चाहते हैं। इसलिए, निर्णय मॉडल के लिए अलग-अलग छोटे निर्देश रखना और जेनरेटिव मॉडल के लिए लंबे संकेत छोड़ना उचित है।

एक अलग पर्यावरण चर बनाना सुविधाजनक है:

OLLAMA_JOB_CLASSIFIER_DECISION_INSTRUCTIONS=Does the message advertise a job posting that someone can apply to?

और केवल जेनरेटिव पथ के लिए नियमित प्रॉम्प्ट का उपयोग करें।

सीमा और संभावनाएं

0.5 की सीमा डिफ़ॉल्ट मान के रूप में उपयुक्त है, लेकिन इसे कॉन्फ़िगरेशन में शामिल करना उपयोगी है। विभिन्न कार्यों के लिए, झूठी सकारात्मक और झूठी नकारात्मक प्रतिक्रिया की लागत अलग-अलग होती है। संयम के लिए, सीमा बढ़ाना अधिक सुरक्षित है; रिक्तियों की खोज के लिए, इसे कम करना अधिक सुरक्षित है, ताकि उपयोगी संदेश न छूटें।

यह स्वयं संभाव्यता को लॉग करने के लिए भी उपयोगी है, न कि केवल परिणामी बूलियन को। जब क्लासिफायर कोई त्रुटि करता है, तो लॉग दिखाता है कि क्या यह एक आश्वस्त उत्तर था या सीमा पर निर्णय था। पसंद के प्रश्नों के लिए, संभावनाओं और आत्मविश्वास को सहेजना उचित है: वे दिखाते हैं कि विकल्पों के बीच मॉडल में कितना उतार-चढ़ाव होता है।

प्रदर्शन और स्मृति

गति काफी हद तक मॉडल और हार्डवेयर के आकार पर निर्भर करती है। मेरे परीक्षणों में सीपीयू पर मुझे निम्नलिखित नंबर मिले:

• tev1:0.8b – हल करने के लिए सेकंड विभाजित करें, आसानी से मेमोरी में फिट हो जाता है।
• tev1 – 4बी, काफ़ी धीमा, लेकिन फिर भी इंटरैक्टिव कार्यों के लिए उपयुक्त।
• फुर्तीला – Q8_0 में 9बी, लगभग 10 जीबी मेमोरी। मॉडल को लोड करने सहित पहले अनुरोध में लगभग 137 सेकंड का समय लगा, बाद के समाधानों में सीपीयू पर 12 से 32 सेकंड का समय लगा।

निंबले को बहुत अधिक रैम की आवश्यकता होती है। 16 जीबी वाली मशीन और लगभग 8 जीबी की सीमा वाली डॉकर/डब्लूएसएल पर, मॉडल फिट नहीं बैठता: सिस्टम स्वैप करना शुरू कर देता है और कंटेनर प्रतिक्रिया देना बंद कर देते हैं। .wslconfig फ़ाइल के माध्यम से WSL सीमा को 12 जीबी तक बढ़ाने से मदद मिली:

[wsl2]
memory=12GB
swap=8GB

परिवर्तन के बाद, आपको wsl –shutdown और डॉकर डेस्कटॉप को पुनरारंभ करना होगा। लेकिन 12 जीबी के साथ भी, रिज़र्व छोटा रहता है: मॉडल लगभग 10 जीबी लेता है, और सिस्टम के लिए बहुत कुछ नहीं बचा है।

डिफ़ॉल्ट रूप से, ओलामा पांच मिनट की निष्क्रियता के बाद मेमोरी खाली करते हुए मॉडल को अनलोड कर देता है। यह सुविधाजनक है: फुर्तीला हर समय 10 जीबी व्यस्त नहीं रखता है, लेकिन प्रत्येक नए लॉन्च के बाद एक ठहराव के बाद मॉडल फिर से लोड होना शुरू हो जाता है।

निर्णय मॉडल का उपयोग कब करें

निर्णय मॉडल उन कार्यों के लिए उपयुक्त हैं जहां आपको स्पष्ट रूप से तैयार किए गए प्रश्न के त्वरित और सस्ते उत्तर की आवश्यकता होती है:

• संदेशों, टिकटों और अनुरोधों का वर्गीकरण।
• आदेशों या निष्पादकों द्वारा रूटिंग।
• सामग्री मॉडरेशन और सुरक्षा जांच।
• गेमिंग या इंटरैक्टिव अनुप्रयोगों में तेज़ बाइनरी और बहुभिन्नरूपी समाधान।

वे उन कार्यों के लिए उपयुक्त नहीं हैं जहां विस्तृत पाठ की आवश्यकता होती है: स्पष्टीकरण, फ़ील्ड निष्कर्षण, सारांश, उत्तर सृजन। इस प्रयोजन के लिए, सामान्य जनरेटिव मॉडल बने रहते हैं। संयुक्त होने पर सबसे अच्छा परिणाम प्राप्त होता है: एक निर्णय मॉडल एक निर्णय लेता है, और एक जेनरेटिव मॉडल इसे समझाता है या डेटा निकालता है।

कुल

ओलामा में निर्णय मॉडल नियमित एलएलएम की तुलना में एक अलग, संकीर्ण उपकरण हैं। वे जेनरेटिव मॉडल को प्रतिस्थापित नहीं करते हैं, लेकिन वे काम के नियमित हिस्से को हटा देते हैं: टाइप की गई प्रतिक्रियाएं, टेक्स्ट पार्सिंग के बजाय संभावनाएं, और एक पूर्वानुमानित प्रारूप। यदि आपके पास पहले से ही एक वर्गीकरण पाइपलाइन है, तो संक्रमण मॉडल की क्षमताओं की जांच, एक अलग कॉलिंग रणनीति और संक्षिप्त निर्देशात्मक प्रश्नों तक पहुंच जाता है।

सूत्रों का कहना है
https://ollama.com/blog/ollama-now-supports-jev-style-decision-models
https://ollama.com/library/nimble
https://ollama.com/library/tev1
https://typesafe.ai