அங்கு எந்த ஒரு மந்திரச் சொல்லும் இல்லை. எந்தவொரு மறைமுகக் கட்டளையும் ஒரு பெரிய மொழி மாதிரியை (large language model) ஒரு தீர்க்கதரிசியாக மாற்றாது, மேலும் எந்தவொரு ரகசிய முன்னொட்டும் (prefix) Claude உங்கள் வணிகத்தை உங்களை விடச் சிறப்பாகத் திடீரென்று புரிந்துகொள்ளச் செய்துவிடாது. ப்ராம்ப்ட் இன்ஜினியரிங் (Prompt engineering) என்பது ஒரு குறியீட்டை உடைப்பதைப் பற்றியது அல்ல. இது இணையத்தின் பெரும் பகுதியைப் படித்திருந்தாலும், உங்களைச் சந்தித்ததில்லை, உங்கள் அலுவலகத்தைப் பார்த்ததில்லை அல்லது உங்கள் தயாரிப்பைப் பற்றி கேள்விப்பட்டதில்லை என்ற ஒரு திறமையான சக ஊழியருடன் தெளிவாகத் தொடர்புகொள்ளும் ஒரு ஒழுங்குமுறை ஆகும். Claude-ஐ அதன் முதல் நாளில் இருக்கும் ஒரு புத்திசாலித்தனமான புதிய ஊழியரைப் போலக் கருதுங்கள். அவர்கள் உங்களுக்கு உதவ ஆர்வமாக இருப்பார்கள், ஆனால் நீங்கள் தெளிவற்ற அறிவுறுத்தல்களைக் கொடுத்தால், உங்களுக்குக் கிடைக்கும் முடிவுகளும் தெளிவற்றதாகவே இருக்கும். எந்தவொரு அலுவலகத்திலும் கடைப்பிடிக்கப்படும் அதே விதி இதற்கும் பொருந்தும்: குப்பை உள்ளே சென்றால், குப்பைதான் வெளியே வரும் (garbage in, garbage out).

Claude-ஐ ஒரு புதிய பணியாளரைப் போல நடத்துங்கள்

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

Claude-க்கு உங்கள் குறிப்பிட்ட சூழ்நிலையைப் பற்றி எந்தத் தகவலும் இல்லை என்று கருதித் தொடங்குங்கள். அதற்கு இலக்கணம், கோடிங் முறைகள் (coding patterns) மற்றும் வரலாறு தெரியும், ஆனால் நீங்கள் விளக்கிக் கூறாதவரை உங்கள் நிறுவனத்தின் தொனி (tone), உங்கள் வாடிக்கையாளரின் குறைகள் அல்லது உங்கள் சட்டக் கட்டுப்பாடுகள் பற்றி அதற்குத் தெரியாது. சிறந்த ப்ராம்ப்டிங் (prompting) என்பது சிறந்த மேலாண்மை மட்டுமே. நீங்கள் கட்டுப்பாடுகளை நிர்ணயிக்கிறீர்கள், பார்வையாளர்களை வரையறுக்கிறீர்கள் மற்றும் வழங்க வேண்டியதை (deliverable) தெளிவுபடுத்துகிறீர்கள். அதைச் சரியாகச் செய்தால், மாதிரியின் (model) ஏற்கனவே உள்ள அறிவு திடீரென்று பயனுள்ளதாக மாறும்.

ஒரு சிறந்த ப்ராம்ப்ட்டின் (Prompt) ஐந்து பகுதிகள்

ஒவ்வொரு தொழில்முறை ப்ராம்ப்ட்டும் ஐந்து தனித்துவமான கூறுகளைக் கொண்டிருக்க வேண்டும். ஒவ்வொன்றிற்கும் நீங்கள் ஒரு கட்டுரை எழுதத் தேவையில்லை, ஆனால் நீங்கள் 'enter' அழுத்துவதற்கு முன் அனைத்தையும் தொட்டுவிட வேண்டும்.

பங்கு (Role)
மாதிரி (model) யார் என்று சொல்லுங்கள். இது அதன் சொல்லகராதி, பார்வை மற்றும் முன்னுரிமையை வடிவமைக்கிறது. "நீங்கள் ஒரு தொழில்நுட்பத் திருத்தர்" என்று சொல்வதை விட, "நீங்கள் பிளாக்செயினில் (blockchain) புதியவர்களான ஃபின்டெக் (fintech) டெவலப்பர்களுக்காக API ஆவணங்களை எளிமையாக்கும் ஒரு தொழில்நுட்பத் திருத்தர்" என்று சொல்வது மிகவும் சிறப்பாகச் செயல்படும். அந்தப் பாத்திரம் (persona) எவ்வளவு குறிப்பிட்டதாக இருக்கிறதோ, அவ்வளவு துல்லியமான வெளியீடு கிடைக்கும்.

சூழல் (Context)
சூழலை விளக்குங்கள். இதை யார் படிக்கிறார்கள்? இலக்கு என்ன? மருத்துவமனை நிர்வாகிகளை இலக்காகக் கொண்ட சைபர் பாதுகாப்பு (cybersecurity) பற்றிய ஒரு வலைப்பதிவுப் பதிவு, பதின்ம வயது கேமர்களை (gamers) இலக்காகக் கொண்ட பதிவிலிருந்து முற்றிலும் மாறுபட்டதாக இருக்க வேண்டும். சூழலில் அதன் முக்கியத்துவமும் (stakes) அடங்கும். நீங்கள் ஒரு யோசனையை உருவாக்குகிறீர்களா (brainstorming), அல்லது இது நேரலையில் வெளியாகும் இறுதி வரைவுத் திருத்தமா?

பணி (Task)
துல்லியமான வினைச்சொற்களைப் பயன்படுத்துங்கள். "மேம்படுத்து" (improve), "மேம்படுத்தி" (enhance) அல்லது "சிறப்பாக்கு" (make better) போன்ற தெளிவற்ற சொற்களைத் தவிர்க்கவும். அவற்றுக்கு எந்தப் பொருளும் இல்லை. அதற்குப் பதிலாக, இவ்வாறு எழுதுங்கள்: "இந்த உரையாடலைத் தலா 20 வார்த்தைகளுக்குக் குறைவான மூன்று முக்கியப் புள்ளிகளாகச் சுருக்கவும்." அல்லது: "async/await-ஐப் பயன்படுத்த இந்தச் செயல்பாட்டை (function) மாற்றி அமைத்து (refactor), timeout-களுக்கான பிழை கையாளுதலைச் (error handling) சேர்க்கவும்." பணி என்பது உங்கள் கட்டளை, எனவே அதை ஒரு விருப்பமாக இல்லாமல் கட்டளையாகச் செய்யுங்கள்.

வடிவம் (Format)
Claude எழுதத் தொடங்குவதற்கு முன்பே பதிலின் வடிவத்தை வரையறுக்கவும். உங்களுக்கு ஒரு எண் வரிசைப் பட்டியலா, ஒரு மார்க்‌டவுன் அட்டவணையா (markdown table), சரியான JSON-ஆ, தலைப்புடன் கூடிய மின்னஞ்சலா அல்லது ஒரு சட்ட ஆவணமா? உங்களுக்கு குறிப்பிட்ட நெடுவரிசைகளுடன் கூடிய ஒப்பீட்டு அட்டவணை தேவைப்பட்டால், அவற்றின் பெயர்களைக் குறிப்பிடுங்கள். உங்களுக்கு வெளியீடு கருத்துகளுடன் (comments) கூடிய ஒரு code block-இல் வேண்டுமென்றால், அப்படியே சொல்லுங்கள். வடிவமைப்பு அறிவுறுத்தல்கள், நீங்கள் கட்டமைக்கப்பட்ட தரவை (structured data) எதிர்பார்க்கும் போது, ஒரு நீண்ட உரைத் தொகுப்பைப் பெறுவதைத் தவிர்க்க உதவும்.

கட்டுப்பாடுகள் (Constraints)
எதைத் தவிர்க்க வேண்டும் என்பதைப் பட்டியலிடுங்கள். இதில் தொனி, நீளம், தடைசெய்யப்பட்ட சொற்கள் மற்றும் தவிர்க்க வேண்டிய தலைப்புகள் ஆகியவை அடங்கும். உதாரணமாக: "பதிலை 150 வார்த்தைகளுக்குக் குறைவாக வைத்திருக்கவும். உரையாடல் போன்ற தொனியைப் பயன்படுத்தவும். 'synergy' என்ற வார்த்தையைப் பயன்படுத்த வேண்டாம். $500-க்கும் அதிகமான பட்ஜெட் தேவைப்படும் தீர்வுகளைப் பரிந்துரைப்பதைத் தவிர்க்கவும்." கட்டுப்பாடுகள் என்பவை பாதுகாப்பு வேலிகள் (guardrails). நீங்கள் அவற்றைச் சரியாகக் கூறினால் மட்டுமே மாதிரி அவற்றைச் சரியாகக் கையாளும்.

சிறந்த முடிவுகளுக்கான நான்கு நுட்பங்கள்

அடிப்படை விஷயங்களைக் கற்றுக்கொண்ட பிறகு, சில மேம்பட்ட முறைகளைப் பயன்படுத்தி உங்கள் அணுகுமுறையைச் செம்மைப்படுத்தலாம். அவற்றுள் எதற்கும் சிறப்புப் பயிற்சி தேவையில்லை. அவை உங்கள் சிந்தனையை ஒரு கட்டமைப்பிற்குள் கொண்டு வருவதற்கான வழிகள் மட்டுமே, அப்போதுதான் மாதிரியால் அதைப் பின்பற்ற முடியும்.

சிக்கலான பணிகளைப் படிநிலைகளாகப் பிரிக்கவும் (Break complex work into steps)
அனைத்தையும் ஒரே நேரத்தில் கேட்காதீர்கள். உங்களுக்கு ஒரு சந்தைப்படுத்தல் பிரச்சாரம் (marketing campaign) தேவைப்பட்டால், பார்வையாளர் பகுப்பாய்வுடன் (audience analysis) தொடங்குங்கள். அந்த வெளியீட்டை ஆய்வு செய்துவிட்டு, பின்னர் செய்திகளை (messaging) உருவாக்கச் சொல்லுங்கள். பிறகு சேனல் தேர்வை (channel selection) கேளுங்கள். இந்த படிநிலை அணுகுமுறை பிழைகளை ஆரம்பத்திலேயே கண்டறிய உதவும். மேலும், ஒரே நேரத்தில் பத்து மாறுபட்ட தேவைகளைச் சமநிலைப்படுத்த முயலும்போது மாதிரி குழப்பமடைவதையும் இது தடுக்கிறது. கோடிங் பணிகளுக்கு, முதலில் கட்டமைப்பைக் (architecture) கேளுங்கள், பின்னர் அதன் செயலாக்கத்தையும் (implementation), பிறகு சோதனைகளையும் (tests) கேளுங்கள். ஒவ்வொரு படியும் முந்தைய படியின் அடிப்படையில் அமையும், மேலும் நீங்கள் முழு கட்டுப்பாட்டிலும் இருப்பீர்கள்.

காரணங்களைக் கேட்கவும் (Ask for the reasoning)
Chain-of-thought prompting என்பது இறுதிப் பதிலைக் கொடுப்பதற்கு முன் Claude தனது செயல்பாட்டை விளக்குமாறு கேட்பதாகும். "உங்கள் காரணங்களை படிப்படியாக விளக்கி, பின்னர் உங்கள் முடிவை வழங்கவும்" போன்ற சொற்றொடர்கள் தர்க்கப் பிரச்சனைகள், கணிதம் மற்றும் கோடிங் பிழைத்திருத்தம் (coding debugging) ஆகியவற்றிற்குப் பெரிதும் உதவும். மாடல் எவ்வாறு ஒரு பதிலுக்கு வந்தது என்பதை நீங்கள் பார்க்கும்போது, அது எந்தத் தருணத்தில் தேவையைப் தவறாகப் புரிந்துகொண்டது அல்லது தரவுத்தொகுப்பிலிருந்து (dataset) தவறான மதிப்பைப் பெற்றது என்பதை நீங்கள் கண்டறிய முடியும். இது ஒரு 'பிளாக் பாக்ஸ்' (black box) போன்ற மர்மமான செயல்பாட்டை நீங்கள் தணிக்கை (audit) செய்யக்கூடிய ஒன்றாக மாற்றுகிறது.

தகவல்களைப் பிரிக்க XML டேக்குகளைப் பயன்படுத்தவும் (Use XML tags to separate information)
ஒரு ப்ராம்ப்ட்டில் (prompt) பெரிய அளவிலான உரை இருக்கும்போது, மாடல் மூலப் பொருளையும் (source material) அறிவுறுத்தல்களையும் குழப்பிக் கொள்ளக்கூடும். தனித்தனிப் பகுதிகளை <context>, <task>, அல்லது <example> போன்ற டேக்குகளுக்குள் வைக்கவும். உதாரணமாக:

We are a remote-first SaaS company with 40 employees. Draft a company-wide memo announcing the switch from Slack to Microsoft Teams. Tone should be upbeat but not cringe. Keep it under 200 words.

இந்த அமைப்பு ஒரு ஆவணத்தில் உள்ள தலைப்புகளைப் போலச் செயல்படுகிறது. இது உங்கள் பின்னணித் தகவலைத் தவறுதலாகப் பணியின் ஒரு பகுதியாக மாடல் கருதுவதைத் தடுக்கிறது, மேலும் நீண்ட ப்ராம்ப்ட்களைப் பின்னாளில் நீங்கள் எளிதாகத் திருத்தவும் உதவுகிறது.

சொல்லுவதை விடக் காட்டுங்கள் (Show, do not just tell)
Few-shot prompting என்பது நீங்கள் விரும்பும் பாணி அல்லது வடிவத்திற்கு இரண்டு முதல் நான்கு உதாரணங்களைக் கொடுப்பதாகும். மாடல்கள் பேட்டர்ன்-மேட்சிங் என்ஜின்கள் (pattern-matching engines). அடர்த்தியான விளக்கங்களை விட உதாரணங்களிலிருந்து அவை பெரும்பாலும் வேகமாகப் கற்றுக்கொள்கின்றன. நீங்கள் கூட்டக் குறிப்புகளைச் செயல்பாட்டுத் திட்டங்களாக (action items) மாற்ற விரும்பினால், இரண்டு உதாரணக் குறிப்புகளைப் பதிவிட்டு, அதைத் தொடர்ந்து நீங்கள் எதிர்பார்க்கும் துல்லியமான கட்டமைக்கப்பட்ட வெளியீட்டை வழங்கவும். புதிய உள்ளீட்டில் Claude அந்தப் பேட்டர்னை வியக்கத்தக்க துல்லியத்துடன் பொருந்தும். பத்து வாக்கியங்களில் ஒரு வடிவத்தை விவரிப்பதை விட, மூன்று தெளிவான உதாரணங்களைக் காட்டுவது பொதுவாக அதிகத் திறன் வாய்ந்தது.

பயன்பாட்டிற்குத் தயார் நிலையில் உள்ள டெம்ப்ளேட் (A Ready-to-Use Template)

நீங்கள் ஒரு வெற்று ப்ராம்ப்ட் பெட்டியைப் பார்த்துக் கொண்டிருக்க如果您, இந்த அடிப்படை வடிவத்தைப் பயன்படுத்தவும். பதில் சிறியதாக இருந்தாலும், ஒவ்வொரு அடைப்புக்குறிப்பிற்குள்ளும் தகவல்களை நிரப்பவும்.

Role: [குறிப்பிட்ட பங்கு மற்றும் தொடர்புடைய நிபுணத்துவத்தை உள்ளிடவும்] Context: [பின்னணி, பார்வையாளர்கள் மற்றும் இலக்கை உள்ளிடவும்] Task: [ஒரு வலுவான வினைச்சொல்லைப் பயன்படுத்திச் சரியான பணியை உள்ளிடவும்] Format: [விரும்பிய அமைப்பு: பட்டியல், அட்டவணை, கட்டுரை, JSON போன்றவை] Constraints: [தொனி, நீளம், தவிர்க்கப்பட வேண்டிய சொற்கள் அல்லது தலைப்புகள்]

அது எவ்வாறு நிரப்பப்பட்டிருக்கும் என்பதற்கான உதாரணம் இதோ:

Role: நீங்கள் ஒரு B2B பேரோல் ஸ்டார்ட்அப்பில் (payroll startup) பணிபுரியும் தயாரிப்பு சந்தைப்படுத்தல் மேலாளர் (product marketing manager). Context: நடுத்தர நிறுவனங்களுக்கான மாநில வரித் தாக்கல் (state tax filings) முறையைத் தானியக்கமாக்கும் ஒரு அம்சத்தை நாங்கள் அறிமுகப்படுத்துகிறோம். இதன் பார்வையாளர்கள் இணக்க ஆவணங்களில் (compliance paperwork) மூழ்கியிருக்கும் HR இயக்குநர்கள். அவர்களின் இலக்கு ஒரு டெமோவை (demo) முன்பதிவு செய்ய வைப்பதாகும். Task: கைமுறையாகத் தாக்கல் செய்வதால் ஏற்படும் சிரமத்துடன் தொடங்கி, 15 நிமிட அழைப்பைத் திட்டமிட ஒரு மென்மையான வேண்டுகோளுடன் முடிவடையும் 120 வார்த்தைகள் கொண்ட மின்னஞ்சலை எழுதவும். Format: Subject line, இரண்டு சிறிய உடல் பத்திகள் மற்றும் ஒரு அழைப்புச் செயல் (call-to-action) பொத்தான் லேபிள். Constraints: "synergy" அல்லது "bandwidth" போன்ற தொழில்நுட்பச் சொற்களைத் தவிர்க்கவும். தொனி தொழில்முறை ரீதியாகவும் அதே சமயம் கனிவாகவும் இருக்க வேண்டும். ஆச்சரியக்குறி (exclamation marks) பயன்படுத்த வேண்டாம்.

அந்த ப்ராம்ப்ட் Claude-க்குத் தேவையான அனைத்தையும் வழங்குகிறது. முடிவு முழுமையாகத் துல்லியமாக இருக்காது, ஆனால் அதைத் தொடக்கத்திலிருந்து மீண்டும் எழுதுவதற்குப் பதிலாகச் சிறிய மாற்றங்கள் செய்து பயன்படுத்தும் அளவுக்கு நெருக்கமாக இருக்கும்.

உண்மையான முக்கியக் கருத்து (The Real Takeaway)

ஒவ்வொரு தனிப்பட்ட கோரிக்கைக்கும் நீங்கள் ஐந்து பகுதிகளைக் கொண்ட ஒரு சிறந்த படைப்பை உருவாக்கத் தேவையில்லை. "பருப்பு சமைக்க ஒரு நல்ல ரெசிபி என்ன?" என்று கேட்பதற்குப் பங்கு அல்லது XML டேக்குகள் தேவையில்லை. ஆனால் வெளியீடு முக்கியமாக இருக்கும்போது, பணி சிக்கலானதாக இருக்கும்போது அல்லது தொடர்ந்து மூன்று முறை தவறான பதில்களைப் பெறும்போது, இந்தச் சரிபார்ப்புப் பட்டியலைப் பயன்படுத்தவும். பெரும்பாலான தோல்வியுற்ற ப்ராம்ப்ட்கள், மனிதர் இன்னும் சத்தமாகச் சிந்தித்துக் கொண்டிருந்ததால் தோல்வியடைகின்றன. நீங்கள் உண்மையில் என்ன விரும்புகிறீர்கள், அது யாருக்காக, மற்றும் அது எப்படி இருக்க வேண்டும் என்பதைத் தீர்மானிக்க முப்பது வினாடிகளை எடுத்துக்கொள்ளுங்கள். அந்தச் சிந்தனையை முன்கூட்டியே செய்துவிட்டால், பதில்களைச் சரிசெய்வதற்கு நீங்கள் செலவிடும் நேரம் வெகுவாகக் குறையும். தெளிவான அறிவுறுத்தல்கள் தெளிவான முடிவுகளைத் தரும். மற்றவை அனைத்தும் வெறும் இரைச்சல் (noise) மட்டுமே.