ماه گذشته با همکاری تازه‌منتقل‌شده‌ای مشغول ساخت نمونه اولیه پشتیبانی هوشمند بودم. نیاز ساده بود: کاربر سؤال می‌پرسد، مدل پاسخ می‌دهد، کمی حافظه زمینه‌ای دارد و می‌تواند به صورت جریانی تایپ کند. به نظر می‌رسید در دو روز تمام می‌شود، اما او در نوشتن سخت‌کدشده API Key، منطق تلاش مجدد و اتصال جریانی هر کدام یک بار به مشکل خورد. کل فرایند را در این مقاله جمع‌آوری کرده‌ام تا به عنوان یادداشت آموزش نیروی جدید استفاده شود.
گام اول: ابتدا نیازها را تجزیه کنید، سپس مدل را انتخاب کنید
از همان ابتدا کد ننویسید. نیازهای توانایی پشتیبانی هوشمند تقریباً به سه بخش تقسیم می‌شود: تشخیص قصد، پرسش و پاسخ دانشی، و گپ چندنوبتی. تشخیص قصد باید سریع و ارزان باشد، استفاده از DeepSeek-V3 یا API Qwen کافی است؛ پرسش و پاسخ دانشی به اسناد خصوصی شما مربوط می‌شود و باید از RAG عبور کند، مدل نیاز به درک زمینه طولانی دارد؛ گپ چندنوبتی نیازمندی بالایی به لحن دارد، Claude 4 Sonnet یا GPT-4o پایدارتر هستند.
روش من این است که ابتدا با یک مدل عمومی زنجیره را راه‌اندازی کنم، سپس آیتم به آیتم جایگزین کنم. مسیریابی چندمدلی SiCore TokenWorks در این زمان کار را راحت می‌کند، همان کد را با تغییر نام مدل می‌توان مقایسه کرد، بدون نیاز به تغییر احراز هویت. انتخاب API مدل بزرگ به معنای انتخاب قوی‌ترین نیست، بلکه انتخاب متناسب‌ترین با وظیفه است.
گام دوم: مدیریت Key، آن را در کد ننویسید
سخت‌کد کردن Key در کد منبع، رایج‌ترین اشتباه تازه‌کاران است. به محض ارسال به git، مانند افشای عمومی است. روش صحیح متغیرهای محیطی به همراه طبقه‌بندی فایل پیکربندی است: به صورت محلی از .env استفاده کنید، تست و تولید از مرکز پیکربندی یا سرویس مدیریت کلید.
جداسازی چندمحیطی باید سه نکته را به خاطر بسپارد: توسعه، تست و تولید از Keyهای مختلف استفاده کنند؛ هر Key سقف اعتبار مستقل داشته باشد؛ Key تولید فقط به سمت سرور داده شود، فرانت‌اند هرگز آن را دریافت نکند. در پروژه ما از SiCore TokenWorks استفاده می‌کنیم، یک Key می‌تواند GPT-4o، Claude، DeepSeek، Tongyi، Wenxin، Doubao و سایر مدل‌های اصلی را فراخوانی کند، که دردسر نگهداری چندین مجموعه احراز هویت را حذف می‌کند و تعویض Key در چند محیط فقط تغییر یک متغیر است.
گام سوم: بسته‌بندی فراخوانی و تلاش مجدد خطا
کدی که SDK را خام فراخوانی می‌کند قابل نگهداری نیست. یک لایه بسته‌بندی کنید، به صورت یکپارچه timeout، محدودیت نرخ و تلاش مجدد را مدیریت کنید. ایده این است: فراخوانی مدل را در یک تابع بپیچید، پارامترها messages و نام مدل هستند، در داخل سه نوع خطا را دریافت کنید — timeout شبکه، محدودیت نرخ 429، خطای سمت سرور 5xx.
استراتژی تلاش مجدد از عقب‌نشینی نمایی استفاده کند، بار اول ۱ ثانیه صبر، بار دوم ۲ ثانیه، بار سوم ۴ ثانیه، حداکثر سه بار. 429 باید ویژه مدیریت شود، هدر retry-after برگشتی را ببینید. برای همه خطاها تلاش مجدد نکنید، تلاش مجدد صد باره برای خطای پارامتر بی‌فایده است. ارزش دروازه مدل در همین لایه است، تلاش مجدد، تنزل و لاگ‌ها را در یک نقطه جمع می‌کند، کد کسب‌وکار فقط نتیجه را می‌گیرد.
هشدار تله: تلاش مجدد باید idempotent باشد. اگر فراخوانی عوارض جانبی دارد (مثلاً نوشتن در پایگاه داده)، قبل از تلاش مجدد ابتدا تأیید کنید که بار قبلی واقعاً شکست خورده است.
گام چهارم: خروجی جریانی و اتصال فرانت‌اند
هسته تجربه پشتیبانی، «افکت ماشین تحریر» است. سمت سرور از SSE برای ارسال تکه‌تکه token به فرانت‌اند استفاده می‌کند، فرانت‌اند با EventSource یا ReadableStream در fetch دریافت می‌کند.
نکات کلیدی بک‌اند: تنظیم stream=True، تجزیه تکه‌تکه delta برگشتی، پایان با دیدن [DONE]. نکات کلیدی فرانت‌اند: هر بار دریافت یک کاراکتر setState نکنید، ۲۰ تا ۵۰ میلی‌ثانیه جمع کنید و دسته‌ای رندر کنید، در غیر این صورت صفحه مانند اسلاید کند می‌شود.
یک تله دیگر، در حین جریان ممکن است کاربر صفحه را ببندد. سرور باید رویداد قطع اتصال را نظارت کند و به موقع درخواست بالادست را لغو کند، در غیر این صورت token بی‌فایده سوزانده می‌شود. تحت پرداخت به‌ازای مصرف، این نوع هدررفت جمع می‌شود.
گام پنجم: نظارت بر هزینه و هشدار
قبل از انتشار باید نقطه‌گذاری کنید. هر فراخوانی ثبت کند: نام مدل، تعداد token ورودی، تعداد token خروجی، زمان مصرف، آیا تلاش مجدد شده. این داده‌ها را یک هفته جمع کنید تا بفهمید پول کجا خرج می‌شود.
هشدار دو خط تنظیم کنید: هشدار عبور هزینه روزانه از آستانه، هشدار غیرعادی token در یک فراخوانی. یک بار کاربری کل یک سند را کپی کرده بود، ورودی واحد چند ده هزار token، اگر هشدار نبود صورت‌حساب پایان ماه زشت می‌شد.
تجربه صرفه‌جویی: وظایف پرتکرار و کم‌دشواری مانند تشخیص قصد را به مدل‌های ارزان داخلی منتقل کنید، هزینه به میزان قابل توجهی کاهش می‌یابد. خرید عمده به همراه زمان‌بندی انرژی سبز، دلیل پایین‌تر بودن قیمت پلتفرم‌های تجمیعی مانند SiCore TokenWorks از خرید مستقیم رسمی است، در مقایسه ما در سناریوهای فراخوانی پرتکرار تفاوت واضح بود.
خلاصه یک جمله: دشواری نمونه اولیه پشتیبانی هوشمند در مدل نیست، در جزئیات مهندسی است. Key را خوب مدیریت کنید، تلاش مجدد را درست بنویسید، جریان را پایدار متصل کنید، هزینه را زیر نظر بگیرید، باقی‌اش تنظیم prompt است. برای عمیق‌تر شدن در اتصال یکپارچه چندمدلی و پیاده‌سازی مسیریابی مدل، می‌توانید در امتداد خط دروازه API مدل بزرگ ادامه دهید.