درون معماری Infrai برای ساده‌سازی جابجایی بین مدل‌های هوش مصنوعی

تصور کنید مدیر محصول یک پلتفرم بزرگ هستید و سیستم نظارت بر محتوای شما به‌دلیل خطای یک مدل، ناگهان از کار می‌افتد. در دنیای واقعی، یک پاسخ HTTP 200 لزوماً به معنای موفقیت نیست، بلکه می‌تواند یک پاسخ ساختاری درست اما از نظر منطقی پوچ باشد.

بسیاری از چت‌بات‌های SaaS با آشفتگی اعتبارنامه‌های مختلف تامین‌کنندگان برای دستیابی به پایداری بالا دست‌وپنجه نرم می‌کنند. اکنون می‌توان این پیچیدگی را با یک کلید API واحد جایگزین کرد. با هدایت درخواست‌ها از طریق یک محیط اجرای مدیریت‌شده مانند Infrai، توسعه‌دهندگان می‌توانند سیاست‌های جایگزینی (Fallback) سخت‌گیرانه‌ای پیاده کنند؛ به‌طوری که یک گزارش تنها زمانی «موفق» تلقی شود که هم از فیلتر بررسی طرحواره JSON و هم از اعتبارسنجی‌های تخصصی دامنه عبور کند. هدف عملیاتی در اینجا صرفاً دریافت یک کد HTTP 200 نیست؛ بلکه دستیابی به یک تصمیم نظارتی قابل‌استفاده است که تنها یک‌بار تحویل داده شود و شواهد کافی برای بازبینی انسانی داشته باشد تا بازبین متوجه شود چرا گزارش به این مسیر هدایت شده است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی لایه‌های انتزاع مدل‌ها اشاره کردیم، اکثر جریان‌های کاری هوش مصنوعی در محیط تولید، هر پاسخ HTTP 200 را به عنوان موفقیت تلقی می‌کنند. اما در واقعیت، یک مدل ممکن است شیئی از JSON برگرداند که از نظر نحوی (Syntactically) کاملاً درست است، اما حاوی یک دسته‌بندی نامعتبر یا یک امتیاز اطمینان (Confidence Score) غیرممکن باشد. برای یک سیستم نظارت بر محتوا، این «شکست خاموش» به‌اندازه یک Timeout یا قطع اتصال آسیب‌زا است، زیرا می‌تواند منجر به مسیریابی اشتباه در سیستم یا حتی کرش کردن کامل برنامه شود. این نوع چالش‌ها دقیقاً همان موانعی هستند که در بررسی ۴ مسیر شکست مانع از استقرار تجاری عامل‌های هوش مصنوعی به آن‌ها اشاره کردیم. یک پاسخ ارائه‌دهنده تنها زمانی موفق است که گزارش به‌درستی تجزیه (Parse) شود، با طرحواره مطابقت داشته باشد و از بررسی‌های دامنه عبور کند.

بر اساس مستندات Infrai و با تکیه بر تغییر رویکرد صنعت به سمت لایه‌های مستقل از مدل (Model-agnostic)، این روش سطح کنترل را از تامین‌کننده مدل دور کرده و به منطق برنامه منتقل می‌کند. به‌جای پخش پراکنده گزارش‌ها بین چندین ارائه‌دهنده، برنامه مالک «قرارداد نظارتی» (Moderation Contract) است و دقیقاً تعریف می‌کند کدام برچسب‌ها پذیرفتنی هستند و چه شواهدی باید برای بازبین‌های انسانی حفظ شود. این قرارداد نظارتی در واقع به عنوان یک مرز حاکمیتی (Governance Boundary) عمل می‌کند. هدف این است که سرویس بتواند شناسه‌های مدل‌های موجود را کشف کند، درخواست ساختاریافته یکسانی را از طریق یک API چت ارسال کند و بدون نیاز به تغییر در احراز هویت یا نحوه مدیریت پاسخ‌ها، به مدل تاییدشده بعدی منتقل شود.

انتخاب سطح یکپارچه‌سازی

بسته به عمق عملیاتی تیم و الزامات انطباق (Compliance)، چهار راه اصلی برای مدیریت این مسیریابی چندمدلی وجود دارد. هر انتخاب، میزان مسئولیتی که تیم داخلی بر عهده می‌گیرد را تغییر می‌دهد:

• APIهای مستقیم (OpenAI, Anthropic, Gemini): این روش پاک‌ترین رابطه را با تامین‌کنندگان حفظ می‌کند. با این حال، تیم باید مالکیت کلاینت، مسیر مدیریت اعتبارنامه‌ها و یک آداپتور متقاطع (Cross-provider adapter) را بر عهده بگیرد. این بهترین انتخاب برای زمانی است که یک تامین‌کننده خاص به‌طور آگاهانه به عنوان اولویت اصلی انتخاب شده و کنترل مستقیم بیشترین اهمیت را دارد.
• LiteLLM: یک درگاه (Gateway) متن‌باز و میزبانی شخصی (Self-hosted) است. این ابزار به تیم‌های پلتفرم کنترل کامل روی مسیریابی و تله‌متری (Telemetry) می‌دهد، اما بار مدیریت یک سرویس تولیدی دیگر، شامل استقرار، به‌روزرسانی‌ها و پاسخ به حوادث (Incident Response) را به تیم تحمیل می‌کند.
• Infrai: یک سطح مدیریت‌شده و سازگار با OpenAI است که کشف مدل و صورت‌حساب یکپارچه را فراهم می‌کند. این ابزار نیاز به فاکتورهای جداگانه از تامین‌کنندگان مختلف را حذف کرده و جریان کاری گزارش را از طریق یک رابط REST ساده، مستقل از نیاز به SDKهای خاص می‌کند. در این حالت، تیم مالک سیاست‌های برنامه، اعتبارسنجی خروجی و Idempotency کسب‌وکار است.
• آداپتورهای سفارشی: ساخت یک سازگارساز داخلی برای چندین ارائه‌دهنده که تنها زمانی توصیه می‌شود که کنترل مستقیم و مطلق روی تامین‌کننده، تنها الزام اصلی باشد.

مکانیسم‌های حلقه جایگزینی مستحکم

در یک راهنمای فنی برای تریاژ نظارتی، تاکید شده است که تلاش‌های مجدد (Retries) در واقع «تغییر وضعیت» (State Transitions) هستند، نه یک جزئیات ساده شبکه. هسته این مکانیسم بر یک «قرارداد خروجی کوچک» متکی است. برای مثال، یک طبقه‌بندی‌کننده باید تنها چهار دسته خاص را بپذیرد: spam ،harassment ،self_harm یا other. همچنین باید یک امتیاز اطمینان بین 0 تا 1 و یک دلیل کوتاه برای بازبین را الزامی کند. این رویکرد ساختاریافته مشابه معماری چهارمرحله‌ای API برای مقابله با توهمات است که دقت خروجی را در سیستم‌های اتوماسیون تضمین می‌کند.

از آنجا که نقطه انتهایی (Endpoint) اختصاصی برای نظارت در این محیط موجود نیست، سازوکار مورد نظر استفاده از یک مدل چت با خروجی json_schema و اعتبارسنجی محلی است. طرحواره (Schema) تولید مدل را محدود می‌کند، اما اعتبارسنج (Validator) است که درباره پذیرش نهایی تصمیم می‌گیرد. این تمایز حیاتی است زیرا یک JSON از نظر نحوی درست می‌تواند از نظر عملیاتی کاملاً غلط باشد.

اگر مدل اصلی دسته‌ای مانند 'abuse' را برگرداند — که منطقی به نظر می‌رسد اما در لیست تاییدشده نیست — سیستم باید آن را به عنوان «رد دامنه» (Domain Rejection) تلقی کند. برای مثال در گزارش rpt_2048 اگر مدل پاسخی با ساختار {"report_id":"rpt_2048","category":"abuse","confidence":0.91,"reason":"threatening language"} بدهد، رمزگشایی JSON موفق است اما چون دسته 'abuse' خارج از قرارداد چهارگانه است، این تلاش به عنوان رد دامنه ثبت شده و هیچ چیزی در صف نوشته نمی‌شود. سپس درخواست به‌طور خودکار به مدل کاندید بعدی در پیکربندی نسخه‌بندی‌شده منتقل می‌شود.

برای جلوگیری از ورودی‌های تکراری در صف بازبینی، سیستم از یک شناسه گزارش پایدار به عنوان کلید Idempotency استفاده می‌کند. این کار تضمین می‌کند که اگر پاسخ مدل اصلی با تاخیر برسد (در حالی که مدل جایگزین قبلاً پاسخ را ثبت کرده است)، سیستم دو مورد بازبینی مجزا برای یک گزارش واحد ایجاد نکند. پذیرش در مرز مدل و Idempotency در مرز نوشتن داده، دو بررسی مجزا هستند.

پیاده‌سازی کشف مدل در Go

به‌جای کدنویسی سخت (Hard-coding) شناسه‌های مدل از حافظه، توصیه می‌شود از مسیر کشف (Discovery Route) استفاده شود. یک پیاده‌سازی مبتنی بر زبان Go می‌تواند نقطه انتهایی /ai/models را فراخوانی کند تا بررسی کند کدام مدل‌های سازگار با چت در حال حاضر در دسترس هستند و سپس حلقه جایگزینی را آغاز کند.

این فرآیند شامل تنظیم INFRAI_BASE_URL و INFRAI_API_KEY در پیکربندی است. سیستم خطاهای HTTP 429 (Too Many Requests) را با رعایت هدر Retry-After در صورت وجود و اعمال عقب‌نشینی نمایی (Exponential Backoff) پیش از تلاش برای مدل بعدی در توالی، مدیریت می‌کند.

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"
)

type model struct {
    ID string `json:"id"`
    Available bool `json:"available"`
    Capability string `json:"capability"`
}

type catalog struct {
    Count int `json:"count"`
    Data []model `json:"data"`
}

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second)
    defer cancel()
    models, err := getModels(ctx, os.Getenv("INFRAI_BASE_URL"), os.Getenv("INFRAI_API_KEY"))
    if err != nil {
        panic(err)
    }
    for _, m := range models.Data {
        if m.Available && m.Capability == "chat" {
        fmt.Println(m.ID)
        }
    }
}

func getModels(ctx context.Context, baseURL, key string) (catalog, error) {
    if baseURL == "" || key == "" {
        return catalog{}, fmt.Errorf("INFRAI_BASE_URL and INFRAI_API_KEY are required")
    }
    var lastErr error
    for attempt := 0; attempt < 3; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodGet, strings.TrimRight(baseURL, "/") + "/ai/models", nil)
        if err != nil {
            return catalog{}, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := http.DefaultClient.Do(req)
        if err != nil {
            lastErr = err
            continue
        }
        body, readErr := io.ReadAll(io.LimitReader(resp.Body, 1<<20))
        resp.Body.Close()
        if readErr != nil {
            return catalog{}, readErr
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Duration(1<<attempt) * time.Second
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
                delay = time.Duration(seconds) * time.Second
            }
            select {
            case <-ctx.Done():
                return catalog{}, ctx.Err()
            case <-time.After(delay):
                lastErr = fmt.Errorf("rate limited")
                continue
            }
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return catalog{}, fmt.Errorf("model discovery status %d: %s", resp.StatusCode, body)
        }
        var result catalog
        if err := json.Unmarshal(body, &result); err != nil {
            return catalog{}, err
        }
        return result, nil
    }
    return catalog{}, fmt.Errorf("model discovery retries exhausted: %w", lastErr)
}

اعتبارسنجی و تست سایه

موفقیت در این سیستم با یک دروازه سه مرحله‌ای تعریف می‌شود: رمزگشایی JSON، انطباق با طرحواره و اعتبارسنجی دامنه. مدلی که امتیاز اطمینان ۱.۴ برگرداند (که خارج از بازه ۰ تا ۱ است) یا متنی توضیحی و گفتگو-محور دور شیء JSON اضافه کند، فوراً رد می‌شود. سیستم باید داده‌ها را در یک ساختار Go شامل report_id ،category ،confidence و reason رمزگشایی کند، فیلدهای ناشناخته را رد نماید و بازه بسته ۰ تا ۱ را برای امتیاز اطمینان اجبار کند.

پیش از استقرار نهایی در محیط تولید، توصیه می‌شود کاندیدها در «حالت سایه» (Shadow Mode) اجرا شوند. این کار شامل فراخوانی مدل جایگزین بدون اجازه ثبت کار در صف است تا خروجی آن با مسیر اصلی مقایسه شود. این روش اجازه می‌دهد تیم به‌جای استفاده از امتیازات قابلیت اطمینان ساختگی، نرخ‌های خام و واقعی را اندازه‌گیری کند:

• نرخ رد طرحواره (Schema-rejection rates): دفعاتی که JSON بدشکل است یا فیلدهای ضروری را کم دارد.
• نرخ رد دامنه (Domain-rejection rates): دفعاتی که مدل برچسب‌های غیرتاییدشده (مانند 'abuse') به‌جای چهار دسته مورد تایید برمی‌گرداند.
• تعداد خطای ۴۲۹: تکرار و فراوانی محدودیت‌های نرخ درخواست (Rate Limits).
• عمق پذیرش جایگزین (Accepted fallback depth): دفعاتی که سیستم مجبور شد برای رسیدن به پاسخ موفق، به دومین یا سومین کاندید برسد.
• سرکوب نوشتن تکراری: تایید عملیاتی اینکه کلید Idempotency از ثبت دوگانه در صف جلوگیری می‌کند.

حفاظ‌های عملیاتی

برای جلوگیری از تبدیل یک طبقه‌بندی‌کننده سریع به یک سیستم کند، توسعه‌دهندگان باید تعداد کل تلاش‌ها را محدود کرده و یک بودجه زمانی سخت‌گیرانه (Wall-clock budget) تعیین کنند. استفاده از سه کاندید با تلاش‌های نامحدود می‌تواند تأخیر (Latency) را به‌شدت افزایش دهد. به هر تلاش یک ضرب‌الاجل (Deadline) بدهید، تعداد کل تلاش‌ها را سقف‌گذاری کنید و گزارش‌هایی که تمام تلاش‌هایشان به پایان رسیده را به‌جای حدس زدن، مستقیماً به بازبینی انسانی ارجاع دهید.

در نهایت، ترتیب مدل‌های جایگزین باید به عنوان یک پیکربندی نسخه‌بندی‌شده مدیریت شود. اگر اختلاف نظر بازبین‌ها یا محدودیت‌های نرخ از یک آستانه خاص گذشت، تیم می‌تواند به لیست قبلی مدل‌های تاییدشده بازگردد (Rollback). طبقه‌بندی‌های پذیرفته‌شده قبلی باید به عنوان سوابق قابل حسابرسی باقی بمانند و در زمان بازگشت بازنویسی نشوند. تنها گزارش‌هایی که هرگز به یک وضعیت نهایی پذیرفته‌شده نرسیدند باید با استفاده از شناسه گزارش اصلی برای حفظ Idempotency، مجدداً در صف قرار گیرند.

جایگزینی یک مکانیسم مهارکننده است، نه اجازه برای پایین آوردن استانداردهای کیفیت. اگر هر سه کاندید قرارداد را نقض کردند، سیستم باید در حالت «بسته» (Fail Closed) عمل کرده و گزارش را به انسان ارجاع دهد. این رویکرد زمانی مناسب نیست که سیاست‌های سازمان نیازمند کنترل‌های مستقیم و خاص هر تامین‌کننده باشد، یا زمانی که جریان کاری نیازمند قابلیت‌هایی مانند ASR (تشخیص خودکار گفتار)، صدای بلادرنگ یا ارتقای تصویر فراتر از روش Lanczos باشد.

گام بعدی شما

• بررسی ساختار json_schema در مدل‌های مورد استفاده برای کاهش نرخ رد طرحواره.
• پیاده‌سازی لایه اعتبارسنجی دامنه (Domain Validation) جدا از رمزگشایی JSON.
• اجرای تست سایه برای مدل‌های جایگزین جهت محاسبه نرخ پذیرش واقعی پیش از استقرار.

اما مدیریت هزینه‌های استنتاج در مقیاس بالا چالش دیگری است — به تحلیل ما درباره بهینه‌سازی GPU مراجعه کنید.