DeepSeek-ன் முதன்மை மாடல் ஒரே இரவில் மாறியுள்ளது. எந்தவொரு அறிவிப்பு அல்லது வலைப்பதிவும் (blog post) இன்றி, பெரும்பாலான டெவலப்பர்கள் பயன்படுத்திய முன்னோட்டப் பதிப்பை (preview build), நிறுவனம் அதிகாரப்பூர்வமான V4 Pro 0813 வெளியீடாக மாற்றியுள்ளது; அதே சமயம் API endpoint பெயரையும் மாற்றாமல் அப்படியே வைத்துள்ளது.

இந்த மாற்றம் முக்கியமானது, ஏனெனில் மாடலின் உட்புற எடைகள் (internal weights) – அதாவது ப்ராம்ப்ட்களை (prompts) அது எவ்வாறு புரிந்துகொள்கிறது மற்றும் பதில்களை எவ்வாறு வடிவமைக்கிறது என்பதைத் தீர்மானிக்கும் தரவுகள் – மாறியுள்ளன. ஒரு குறிப்பிட்ட வெளியீட்டு நடைமுறை (output style), கருவி அழைப்பு தொடரியல் (tool-call syntax) அல்லது அறிவுறுத்தல் பின்பற்றும் நடையை (instruction-following behavior) நம்பியிருக்கும் எந்தவொரு விஷயமும், மாற்றப்படாத endpoint-ன் பின்னால் ஒரு புதிய பதிப்பு வெளியிடப்படும்போது செயலிழக்கக்கூடும்.

DeepSeek எவ்வாறு V4 Pro 0813-க்கு மாறியது

DeepSeek-ன் பொது API நீண்டகாலமாக அதன் பெரிய மொழி மாடலுக்கான (large language model) நுழைவுப் புள்ளியாக deepseek-v4-pro போன்ற ஒரு ஒற்றைப் பெயரை வழங்கி வருகிறது. உட்புறமாக, அந்தப் பெயர் என்பது விற்பனையாளர் எந்த நேரத்திலும் மாற்றக்கூடிய ஒரு சுட்டி (pointer) மட்டுமே. இந்தச் சூழலில், அந்தச் சுட்டி ஒரு முன்னோட்டப் பதிப்பிலிருந்து (preview build) அதிகாரப்பூர்வமாக வெளியிடப்பட்ட V4 Pro 0813 மாடலுக்கு மாற்றப்பட்டுள்ளது.

V4 Pro 0813 சில முக்கிய அம்சங்களைக் கொண்டுவருகிறது, இவை இந்த மாற்றத்திற்கு முக்கியக் காரணமாக இருந்திருக்கலாம்:

  • செலவுச் சாதகம் – இது Claude போன்ற போட்டியாளர்களின் சேவைகளை விடக் குறிப்பிடத்தக்க அளவு குறைவான விலையைக் கொண்டுள்ளது.
  • மிகப்பெரிய context window – இது ஒரே கோரிக்கையில் (single request) 1 மில்லியன் டோக்கன்கள் வரை கையாளும் திறன் கொண்டது; நீண்ட ஆவணங்கள் அல்லது விரிவான உரையாடல் வரலாறுகளுக்குப் பல டெவலப்பர்களுக்கு இவ்வளவு பெரிய அளவிலான திறன் தேவைப்படுகிறது.
  • போட்டித்தன்மை வாய்ந்த செயல்திறன் – தரநிலையான பணிகளில் (standard tasks) மிகச்சிறந்த மாடல்களுக்கும் இதற்கும் இடையே மிகச்சிறிய இடைவெளியே உள்ளதாக பெஞ்ச்மார்க் (benchmarks) முடிவுகள் காட்டுகின்றன.
  • எதிர்கால விலை மாற்றம் – தற்போதைய விலை பின்னர் அதிகரிக்கக்கூடும் என்று DeepSeek அறிவித்துள்ளது, இதனால் ஆரம்பகாலப் பயனர்களுக்கு (early adopters) தற்போதைய விலை மிகவும் ஈர்க்கக்கூடியதாக உள்ளது.

இந்த மாற்றங்கள் எதுவும் API ஒப்பந்தத்தில் (API contract) தெரியாது. endpoint பெயர், கோரிக்கை வடிவம் (request format) மற்றும் பதிலளிக்கும் ஸ்கீமா (response schema) ஆகியவை அப்படியே இருப்பதால், endpoint-ஐ அழைக்கும் ஒரு கிளையன்ட் (client), அதன் பின்னணியில் உள்ள மாடல் மாற்றப்பட்டுள்ளது என்பதற்கான எந்தத் தடயத்தையும் காண முடியாது.

அமைதியான அப்டேட்கள் (silent updates) ஏன் ஒரு மறைமுக ஆபத்து

பயிற்சியளித்த பின் செய்யப்படும் அப்டேட்கள் (Post-training updates), தயாரிப்புப் பாதைகளில் (production pipelines) மிக முக்கியமான மூன்று அம்சங்களை மாற்றக்கூடும்:

  1. அறிவுறுத்தல்களைப் பின்பற்றுதல் – மாடல் சிஸ்டம் ப்ராம்ப்ட்களை (system prompts) எவ்வாறு புரிந்துகொள்கிறது என்பதில் ஏற்படும் நுணுக்கமான மாற்றங்கள், வெவ்வேறு முடிவுகளைத் தரக்கூடும்; இது துல்லியமான சொற்றொடர்களை எதிர்பார்க்கும் அடுத்தகட்ட தர்க்கங்களை (downstream logic) செயலிழக்கச் செய்யும்.
  2. கருவி அழைப்பு வடிவம் (Tool-call formatting) – பல ஏஜென்ட்கள் (agents) வெளிப்புறக் கருவிகளை அழைப்பதற்கு ஒரு கண்டிப்பான JSON ஸ்கீமாவைச் சார்ந்துள்ளன. ஒரு புதிய மாடல் பதிப்பு புலங்களை (fields) சேர்க்கலாம், நீக்கலாம் அல்லது வரிசை மாற்றலாம், இது பார்சிங் பிழைகளை (parsing errors) ஏற்படுத்தும்.
  3. வெளியீட்டு நடை (Output style) – மேற்கோள் குறிகள் (quotation marks), இடைவெளிகள் (whitespace) அல்லது பட்டியலின் வரிசை போன்ற சிறிய மாற்றங்கள் கூட, சில செயலிகள் சரிபார்ப்பதற்காகப் பயன்படுத்தும் ஸ்ட்ரிங்-மேட்சிங் (string-matching) சோதனைகளைச் செயலிழக்கச் செய்யலாம்.

ஒரு சேவை வழங்குநர் மாடலை அமைதியாக மாற்றும்போது, தயாரிப்புச் சூழலில் (production) ஒரு தோல்வி ஏற்படும் வரை அந்த மாற்றத்தைக் கண்டறிய டெவலப்பர்களிடம் எந்தத் தானியங்கி வழியும் இல்லை. அந்தத் தோல்வியினால் ஏற்படும் பாதிப்புகள்—செயல்பாட்டு முடக்கம் (downtime), பயனர் அதிருப்தி அல்லது நிதி இழப்பு—மாடலின் பதிப்பைப் பாதுகாப்பாகப் பயன்படுத்துவதற்கு (version-pin) தேவைப்படும் முயற்சியை விடப் பல மடங்கு அதிகமாக இருக்கலாம்.

உங்கள் AI கட்டமைப்பைப் (AI stack) பாதுகாக்க நடைமுறைப் படிகள்

  • தேதியுடன் கூடிய ஒரு பெயரைக் குறிப்பிடுதல் (Pin to a dated alias) – பொதுவான deepseek-v4-pro என்பதைப் பயன்படுத்துவதற்குப் பதிலாக, வெளியீட்டுத் தேதி அல்லது பதிப்பு ஹாஷ் (version hash) கொண்ட ஒரு பெயரைப் பயன்படுத்துங்கள், உதாரணத்திற்கு deepseek-v4-pro-2024-08-13. பொதுவான பெயரைச் சோதனைகளுக்காக மட்டுமே ஒதுக்கி வையுங்கள்.
  • ஒரு சிறந்த சோதனைத் தொகுப்பைப் பராமரித்தல் (Maintain a golden test set) – பிரதிநிதித்துவமான ப்ராம்ப்ட்கள் மற்றும் எதிர்பார்க்கப்படும் பதில்களின் ஒரு நிலையான தொகுப்பைத் தயார் செய்யுங்கள். மாடல் அடையாளங்காட்டி (model identifier) மாறும்போது இந்தச் சோதனைகளைத் தானாகவே நடத்துங்கள். ஒரு மாற்றம் கண்டறியப்பட்டால், போக்குவரத்து (traffic) மாற்றப்படுவதற்கு முன்பே அது பிழையைக் காட்டிவிடும்.
  • மாடல் கைரேகைகளைப் பதிவு செய்தல் (Log model fingerprints) – ஒவ்வொரு API பதிலிலும் மாடல் பதிப்பு அல்லது ஹாஷ் போன்ற மெட்டாடேட்டா (metadata) இருக்கும். இதை உங்கள் லாக்ஸில் (logs) கோரிக்கையுடன் சேர்த்துச் சேமித்து வைத்து, எதிர்பாராத மாற்றங்களுக்கு எச்சரிக்கைகளை (alerts) அமைக்கவும்.
  • ஒரு ரூட்டிங் லேயரை (routing layer) அறிமுகப்படுத்துதல் – எந்த குறிப்பிட்ட மாடல் பெயரைப் பயன்படுத்த வேண்டும் என்பதைத் தீர்மானிக்கும் ஒரு உள் சேவையின் மூலம் மாடல் அழைப்பைத் தனிமைப்படுத்துங்கள். இந்த லேயர் ஒரு 'கனரி ரோல்அவுட்' (canary rollout) முறையைப் பின்பற்றலாம்: ஒரு சிறிய சதவீதப் போக்குவரத்தை புதிய பதிப்பிற்கு அனுப்பி, முடிவுகளைச் சிறந்த சோதனைத் தொகுப்புடன் ஒப்பிட்டுப் பார்த்து, அளவீடுகள் (metrics) உங்கள் வரம்புகளை எட்டும்போது மட்டும் அதை முழுமையாகப் பயன்படுத்தலாம்.
  • தயாரிப்பு மற்றும் சோதனைச் சூழல்களைப் பிரித்தல் (Separate production and testing environments) – தயாரிப்புப் பெயரினை (production alias) ஒரு தெரிந்த பதிப்பிலேயே பூட்டி வையுங்கள். ஸ்டேஜிங் (staging) சூழலில், புதிய நடத்தையை டெவலப்பர்கள் நேரடிப் பயனர்களைப் பாதிக்காமல் காணும் வகையில், அந்தப் பெயரைப் புதிய வெளியீட்டிற்கு மாற்றலாம்.

இந்த நடவடிக்கைகளைச் செயல்படுத்துவதன் மூலம், ஒரு அமைதியான மாடல் மாற்றத்தை "கட்டமைப்பைச் சிதைக்கும்" நிகழ்வாக இல்லாமல், ஒரு கட்டுப்படுத்தப்பட்ட பரிசோதனையாக மாற்ற முடியும். எதிர்பாராத வெளியீட்டு வடிவத்தால் ஏற்படும் சேவை முடக்கத்தின் செலவோடு ஒப்பிடும்போது, ஒரு ரூட்டிங் லேயர் அல்லது சிறந்த சோதனைத் தொகுப்பைப் பராமரிப்பதற்கான கூடுதல் செலவு மிகக் குறைவு.

அடுத்து கவனிக்க வேண்டியவை

DeepSeek எதிர்காலத்தில் விலையேற்றம் ஏற்படக்கூடும் என்று கோடிட்டுக் காட்டியுள்ளது, இது தற்போதைய விலையிலேயே பதிப்பைப் (version) பின்னி (pinning) வைத்துக்கொள்ள வாடிக்கையாளர்களைத் தூண்டலாம். வரவிருக்கும் புதுப்பிப்புகள் குறித்த குறிப்புகளை அறிய அதிகாரப்பூர்வத் தகவல்களைக் கவனியுங்கள்—அவை எவ்வளவு சுருக்கமானதாக இருந்தாலும் சரி—மற்றும் பிற டெவலப்பர்கள் மாற்றத்தின் (drift) ஆரம்ப அறிகுறிகளைப் பகிர்ந்து கொள்ளக்கூடிய சமூக மன்றங்களைக் கண்காணிப்பதே சிறந்தது. வழங்குநர் இறுதியில் ஒரு changelog-ஐ வெளியிட்டால், அதை உங்கள் version-pinning workflow-இல் இணைத்துக் கொள்ளுங்கள்; இதன் மூலம் புதிய model-ஐ ஏற்றுக்கொள்வதா அல்லது முந்தைய மாதிரியிலேயே தொடர்வதா என்பதை நீங்கள் தீர்மானிக்க முடியும்.

முக்கியக் கருத்து: மாறாத ஒரு endpoint, மாறாத model-ஐ உறுதி செய்வதில்லை. Model name-ஐ ஒரு ஒப்பந்தமாகப் பார்க்காமல், மாற்றப்படக்கூடிய ஒரு pointer-ஆகக் கருதுங்கள். Version-pinning செய்தல், ஒரு நிலையான golden set-ஐக் கொண்டு சோதனை செய்தல் மற்றும் ஒரு internal abstraction மூலம் அழைப்புகளைத் திசைதிருப்புதல் ஆகியவற்றின் மூலம், silent updates-களை ஒரு மறைமுக அச்சுறுத்தலில் இருந்து உங்கள் development lifecycle-இன் நிர்வகிக்கக்கூடிய ஒரு பகுதியாக மாற்றலாம்.