आरएमआई एडीके एजेंट को, डोमेन के हिसाब से विशेषज्ञता और कौशल के आधार पर तैयार करना

खास जानकारी

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

RMI ADK एजेंट, स्किल के ज़रिए इस समस्या को हल करता है. उस उपयोगकर्ता के बारे में सोचें जिसने "कल स्ट्रो ड्राइव पर कितना ट्रैफ़िक था?" पूछा है. जवाब देने के लिए, एजेंट को यह पता होना चाहिए कि आरएमआई, ट्रैवल टाइम इंडेक्स (टीटीआई) के तौर पर ट्रैफ़िक की जानकारी देता है. यह historical_travel_time टेबल में, लाइव duration_in_seconds और फ़्री-फ़्लो static_duration_in_seconds का अनुपात होता है. जिन एजेंट के पास ज़रूरी कौशल नहीं होता वे इसके बजाय, average_speed कॉलम (आरएमआई सिर्फ़ कैटगरी के हिसाब से स्पीड की जानकारी देता है, कभी भी किमी/घंटा में नहीं) बना सकते हैं या गलत फ़ॉर्मूला लागू कर सकते हैं. इससे उन्हें सही जवाब मिलने का भरोसा होता है, लेकिन जवाब गलत होता है.

एजेंट को इस डोमेन के बारे में जानकारी होनी चाहिए. हालांकि, हर मेट्रिक की परिभाषा, टेबल स्कीमा, और एसक्यूएल की चेतावनी को एक ही सिस्टम प्रॉम्प्ट में डालना सही नहीं है.

बड़े सिस्टम प्रॉम्प्ट की सीमाएं

डोमेन से जुड़े सभी नियमों और स्कीमा को एक ही सिस्टम प्रॉम्प्ट में डालने से कई समस्याएं होती हैं:

  • ज़्यादा लागत और जवाब मिलने में ज़्यादा समय लगना: हर बार बहुत बड़ा प्रॉम्प्ट भेजने से, टोकन बर्बाद होते हैं और जवाब मिलने में ज़्यादा समय लगता है. ऐसा उन सवालों के लिए भी होता है जिनके लिए उन नियमों की ज़रूरत नहीं होती.
  • निर्देशों का सही तरीके से पालन न करना: प्रॉम्प्ट में कुछ खास मामलों के बारे में जानकारी देने पर, मॉडल कुछ नियमों को अनदेखा कर सकता है या उन्हें भूल सकता है.
  • अपडेट करना मुश्किल: सभी नियमों को एक ही प्रॉम्प्ट में शामिल करने से, किसी एक नियम को अपडेट करना या उसकी जांच करना मुश्किल हो जाता है. ऐसा करने पर, हो सकता है कि दूसरे नियम काम न करें.

स्किल

एजेंट की स्किल, डोमेन की जानकारी को मॉड्यूलर फ़ोल्डर में व्यवस्थित करती हैं. एजेंट इन फ़ोल्डर को सिर्फ़ तब लोड करता है, जब इनकी ज़रूरत होती है. हर स्किल एक डायरेक्ट्री होती है. इसमें SKILL.md फ़ाइल होती है. इसमें मार्कडाउन निर्देश और वाईएएमएल हेडर होता है.

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

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

किसी स्किल के बारे में पूरी जानकारी

SKILL.md फ़ाइल के दो हिस्से होते हैं: राउटिंग के लिए YAML हेडर और निर्देशों के लिए मार्कडाउन बॉडी.

1. YAML हेडर

---
name: rmi-traffic-metrics-grounding
description: >
  Standard traffic performance metrics computable from RMI BigQuery
  tables. Covers congestion severity (TTI), delay, travel time
  reliability (LOTTR, BTI, PTI, CoV), congestion frequency, speed
  breakdowns, and network-wide congestion rates. Use when the user asks
  about traffic conditions, congestion, reliability, delay, or network
  health.
---

मॉडल, description का इस्तेमाल करके यह तय करता है कि स्किल को लोड करना है या नहीं. मॉडल, स्किल को लोड करने का फ़ैसला लेने से पहले सिर्फ़ इस जानकारी को देखता है. इसलिए, पक्का करें कि इसमें इन बातों के बारे में साफ़ तौर पर बताया गया हो: कवर किए गए विषय, उपयोगकर्ता के सामान्य वाक्यांश, और इसे कब ट्रिगर करना है.

2. मार्कडाउन फ़ॉर्मैट में मुख्य हिस्सा

बॉडी में, डोमेन से जुड़े दिशा-निर्देश दिए जाते हैं. मॉडल, लोड होने के बाद इन दिशा-निर्देशों का पालन करता है. आरएमआई मेट्रिक की स्किल बॉडी में, टीटीआई का सटीक फ़ॉर्मूला (duration_in_seconds / static_duration_in_seconds), हर मेट्रिक के लिए पुष्टि किया गया BigQuery एसक्यूएल टेंप्लेट, और ट्रिगर फ़्रेज़ शामिल होते हैं. ये ट्रिगर फ़्रेज़, उपयोगकर्ता के मकसद को सही मेट्रिक से मैप करते हैं. पुष्टि किए गए स्ट्रक्चर्ड निर्देश देने से, मॉडल को सही जानकारी मिलती है. साथ ही, यह स्कीमा या फ़ॉर्मूले की जानकारी का अनुमान लगाने से बचता है.

ADK के साथ स्किल रजिस्टर करना

स्किल को SkillToolset में ग्रुप करें और उन्हें एजेंट के टूल की सूची में जोड़ें:

from google.adk import skills
from google.adk.tools import skill_toolset

rmi_skill_toolset = skill_toolset.SkillToolset(
    skills=[
        # TRAFFIC_METRICS_SKILL_DIR points to the skill's SKILL.md folder.
        skills.load_skill_from_dir(TRAFFIC_METRICS_SKILL_DIR),
    ],
)

# root_agent = llm_agent.Agent(..., tools=[*bq_tools, rmi_skill_toolset])

यहां, TRAFFIC_METRICS_SKILL_DIR का मतलब उस डायरेक्ट्री से है जिसमें ट्रैफ़िक मेट्रिक की जानकारी देने वाली स्किल मौजूद है.

स्किल के साथ टूल बंडल करना

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

बंडलिंग टूल, ग्लोबल कॉन्टेक्स्ट के साइज़ को भी कम करते हैं. हर खास टूल को पहले से ही उपलब्ध कराने के बजाय, टूल को सिर्फ़ तब लोड किया जाता है, जब उससे जुड़ी डोमेन स्किल चालू हो.

किसी स्किल के YAML हेडर में, सीधे तौर पर कुछ टूल अटैच किए जा सकते हैं:

metadata:
  adk_additional_tools:
    - calculate_custom_metric

इससे यह पक्का होता है कि मॉडल को टूल स्कीमा और उसके इस्तेमाल से जुड़े निर्देश, दोनों एक साथ समय पर मिलें. इससे टूलसेट को कम से कम रखा जा सकता है.

उदाहरण: ट्रैफ़िक की जानकारी से जुड़ी क्वेरी के लिए भरोसेमंद सोर्स से जानकारी पाना

  1. उपयोगकर्ता पूछता है कि "शाम के समय, स्ट्रो ड्राइव पर कितना ट्रैफ़िक होता है?"
  2. सिस्टम के बुनियादी प्रॉम्प्ट में, सिर्फ़ हर स्किल का नाम और ब्यौरा शामिल होता है. इसलिए, एजेंट को दिखता है कि rmi-traffic-metrics-grounding में "भीड़भाड़" की जानकारी शामिल है. इसके बाद, वह इस क्वेरी के लिए पूरे निर्देश पाने के लिए load_skill को कॉल करता है.
  3. स्किल लोड होने के बाद, एजेंट टीटीआई की परिभाषा और पुष्टि किए गए एसक्यूएल टेंप्लेट को लागू करता है. साथ ही, फ़ॉर्मूले का अनुमान लगाने के बजाय, historical_travel_time के हिसाब से रेशियो का हिसाब लगाता है.

किसी स्किल के कॉन्टेंट को सिर्फ़ तब फ़ेच किया जाता है, जब किसी क्वेरी के लिए उसकी ज़रूरत होती है. इसलिए, एजेंट जिन स्किल का इस्तेमाल कभी नहीं करता वे कॉन्टेक्स्ट में शामिल नहीं होती हैं. इससे सिस्टम के प्रॉम्प्ट का साइज़ छोटा रहता है.

ज़रूरी बातें

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

अगले चरण

योगदानकर्ता

नैथनियल थॉमस | सॉफ़्टवेयर इंजीनियरिंग इंटर्न, Google Maps Platform