OpenAI-ன் உள்முறை Astra அமைப்பு, நீண்டகாலமாகத் தீர்க்கப்படாத பத்து கணிதப் பிரச்சனைகளுக்கு முறையான நிரூபணங்களை (formal proofs) உருவாக்கியுள்ளதாக அறிவித்துள்ளது, மேலும் இது Lean 4-ல் இயந்திரத்தால் சரிபார்க்கப்பட்ட சரிபார்ப்புடன் ஒவ்வொரு கூற்றையும் உறுதிப்படுத்தியுள்ளது. குழுவினர் ஒரு தொழில்நுட்பக் கட்டுரையையும் மற்றும் ஒரு திறந்த மூல களஞ்சியத்தையும் (open-source repository) வெளியிட்டுள்ளனர், இதன் மூலம் மூலக் காரணத் தர்க்கத்தை (raw reasoning) ஒரு கம்பைலரால் ஏற்கவோ அல்லது நிராகரிக்கவோ கூடிய நிரூபணமாக மாற்றும் குறியீட்டை எவரும் காண முடியும். அதிக முக்கியத்துவம் வாய்ந்த துறைகளில் AI உதவியை விரும்பும் டெவலப்பர்களுக்கு, இந்த முடிவு ஒரு மாதிரி யோசனைகளை உருவாக்கும் ஆனால் எது உண்மை என்று ஒருபோதும் தீர்மானிக்காது என்ற பணிப்பாய்வை (workflow) உருவாக்குவதற்கான ஒரு உறுதியான முன்மாதிரியாகும்.

Astra-வின் இந்த முன்னேற்றம் ஏன் முக்கியமானது

பெரிய மொழி மாதிரிகள் (LLMs) நம்பகமானதாகத் தோன்றும் உரையை உருவாக்குகின்றன, இருப்பினும் அவை அடிக்கடி உண்மைகளைத் தவறாகக் கூறுகின்றன (hallucinate) அல்லது தர்க்கரீதியாகத் தொடர்பில்லாத படிநிலைகளை இணைக்கின்றன. குறைந்த ஆபத்துள்ள சூழல்களில், ஒரு மனித ஆய்வாளர் பெரும்பாலான தவறுகளைக் கண்டறிந்துவிடலாம், ஆனால் நிதி, மருத்துவம் அல்லது அறிவியல் ஆராய்ச்சியில், கண்டறியப்படாத ஒரு பிழையின் விளைவு பேரழிவாக அமையலாம். Astra, ஒரு LLM-ன் ஆக்கபூர்வமான ஆற்றலைத் தக்கவைத்துக் கொள்ளும் அதே வேளையில், அதன் வெளியீட்டை கண்மூடித்தனமாக நம்ப வேண்டிய அவசியத்தை நீக்கும் ஒரு வழியைக் காட்டுகிறது.

சரிபார்க்கப்பட்ட முடிவுக்கு இட்டுச் சென்ற பாதை

OpenAI பொறியாளர்கள் Astra-வை மூன்று கட்டங்களைக் கொண்ட ஒரு pipeline-ஐ அடிப்படையாகக் கொண்டு உருவாக்கினர்:

  1. Generation – மாதிரி (model) தொடர்ச்சியான காரணத் தர்க்கச் சுழற்சிகளை (reasoning loops) இயக்கி, சாத்தியமான நிரூபணப் படிநிலைகளை முன்மொழிகிறது.
  2. Exposition – மனிதர்களும் மாதிரியும் இணைந்து அந்தப் படிநிலைகளை வாசிக்கக்கூடிய ஒரு விவரிப்பாக (narrative) மாற்றுகிறார்கள்.
  3. Formalization – அந்த விவரிப்பு Lean 4 குறியீடாக மாற்றப்படுகிறது, அதை ஒரு கம்பைலர் வரி வரியாகச் சரிபார்க்கிறது.

இதன் முக்கிய அம்சம் Lean 4-க்கு மாற்றிக் கொடுப்பதாகும். சாதாரண உரை விளக்கத்தைப் போலல்லாமல், Lean 4 ஒவ்வொரு அனுமானத்தையும் ஒரு கடுமையான தர்க்கக் கருத்தின் (logical kernel) படி நியாயப்படுத்தக் கட்டாயப்படுத்துகிறது. கம்பைலர் ஏதேனும் முரண்பாட்டைக் கண்டறிந்து எச்சரித்தால், அந்தப் பிழை திருத்தப்படுவதற்காக மீண்டும் மாதிரிக்கு அனுப்பப்படுகிறது. LLM அல்ல, சரிபார்ப்பவர் (verifier) தான் இறுதித் தீர்ப்பை வழங்குகிறார்.

டெவலப்பர்கள் மற்றும் நிறுவனங்களுக்கான முக்கியத்துவம்

  • நம்பகத்தன்மை (Reliability) – ஒரு AI-ஆல் உருவாக்கப்பட்ட பொருள் ஒழுங்குமுறை அல்லது பாதுகாப்புத் தரங்களைச் சந்திக்க வேண்டியிருக்கும் போது, ஒரு முறையான சரிபார்ப்பவர் (formal verifier), வெறும் டெவலப்பருக்கு மட்டுமல்லாமல், தணிக்கையாளர்களும் (auditors) ஆய்வு செய்யக்கூடிய ஒரு தணிக்கைப் பாதையை (audit trail) வழங்குகிறார்.

இந்த அணுகுமுறை கூடுதல் பணிச்சுமையையும் (overhead) ஏற்படுத்துகிறது. ஒரு சரிபார்ப்பவரால் புரிந்துகொள்ளக்கூடிய விவரக்குறிப்புகளை (specifications) எழுதுவது, முறையான நிரூபணச் சூழலைப் பராமரிப்பது மற்றும் சரிபார்ப்புத் தோல்விகளைப் புரிந்துகொள்ள பொறியாளர்களுக்குப் பயிற்சி அளிப்பது ஆகிய அனைத்திற்கும் முதலீடு தேவைப்படுகிறது. ஒவ்வொரு துறையிலும் இறுதித் தீர்ப்பாகச் செயல்பட முதிர்ந்த தேவர்மா நிரூபிப்பான் (theorem prover) அல்லது வகை அமைப்பு (type system) இருக்காது.

பெரும்பாலான கட்டுரைகள் விடுபடும் விவரங்கள்

  • இயந்திரம் வாசிக்கக்கூடிய வெளியீடு அவசியமானது (Machine-readable output is essential). Astra மாதிரியிடம் தன்னிச்சையான உரை விளக்கத்தைக் கேட்கவில்லை; Lean 4 கம்பைலரால் உள்வாங்கக்கூடிய குறியீடு துண்டுகள் (code snippets) மற்றும் ஸ்கீமா வரையறைகளை (schema definitions) அது வெளிப்படையாகக் கேட்டது.
  • பின்னூட்டச் சுழற்சிகள் இடைவெளியைக் குறைக்கின்றன (Feedback loops close the gap). கம்பைலர் ஒரு வகை பிழையையோ (type error) அல்லது நிரூபிக்கப்படாத லெம்மாவையோ (unproven lemma) அறிக்கையிடும் போது, அந்தத் தரவு மீண்டும் உருவாக்கும் சுழற்சிக்கு அனுப்பப்படுகிறது, இது மாதிரி தனது ஊகத்தை தானாகவே திருத்த அனுமதிக்கிறது.
  • மனிதத் தலையீடு (Human-in-the-loop) மூலோபாயமாகவே உள்ளது.

உங்களுக்கான சரிபார்க்கக்கூடிய AI பணிப்பாய்வை (workflow) உருவாக்குதல்

  • உருவாக்கத்தையும் சரிபார்ப்பையும் தனித்தனியாக வைத்திருங்கள் (Separate generation from validation). ஒவ்வொரு கூற்றையும் சுதந்திரமாக உறுதிப்படுத்தக்கூடிய ஒரு தீர்மானிக்கப்பட்ட கருவியுடன் (deterministic tool) — ஒரு கம்பைலர், ஒரு static analyzer அல்லது ஒரு unit-test harness — LLM-ஐ இணைக்கவும்.
  • கட்டமைக்கப்பட்டப் பொருட்களைக் கேளுங்கள் (Ask for structured artifacts). "அல்காரிதத்தை விளக்கு" என்பதற்குப் பதிலாக, ஒரு இயந்திரம் பகுப்பாய்வு செய்யக்கூடிய ஒரு குறியீடு கோப்பு, ஒரு JSON ஸ்கீமா அல்லது ஒரு நிரூபண ஸ்கிரிப்டைக் கேட்கவும்.
  • பிழை பின்னூட்டத்தை மாதிரியில் சுழற்சி செய்யுங்கள் (Loop error feedback into the model). சரிபார்ப்பவரின் பிழைச் செய்தைகளைப் பெற்று அவற்றை மீண்டும் prompts-களாக அளிக்கவும், இதன் மூலம் மனிதத் தலையீடு இன்றி மாதிரியே அதைச் சரிசெய்ய முயற்சிக்கும்.
  • துல்லியமான விவரக்குறிப்புகளை முன்கூட்டியே வரையறுக்கவும் (Define precise specifications up front). நீங்கள் கொடுக்கும் விதிகளின் அடிப்படையில் மட்டுமே சரிபார்ப்பவரால் சரிபார்க்க முடியும்; விவரக்குறிப்பு தெளிவற்றதாகவோ அல்லது தவறாகவோ இருந்தால், நிரூபணம் அர்த்தமற்றதாகிவிடும்.

முரண்பட்ட கருத்துக்கள் மற்றும் வரம்புகள்

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

சுருக்கம்

ஒரு LLM-ஐ ஒரு தீர்ப்பாளராகக் கருதாமல், ஒரு மூளைச்சலவை கூட்டாளியாக (brainstorming partner) கருதுங்கள். ஒரு தீர்மானிக்கப்பட்ட சரிபார்ப்பவர் — அது கம்பைலராகவோ, லின்டராகவோ (linter) அல்லது முறையான நிரூபண இயந்திரமாகவோ இருக்கலாம் — இறுதித் தீர்ப்பை வழங்கட்டும். இவை இரண்டும் சரியாக இணைக்கப்படும் போது, சரிபார்க்கப்படாத மாயத்தோற்றங்களின் (hallucinations) மறைமுக ஆபத்து இல்லாமல், உருவாக்கும் AI-ன் வேகத்தைப் பெற முடியும்.