தொகுதி மற்றும் ஒத்திசைவற்ற பணிச்சுமைகள்

ஆதாயங்கள்:

• எந்த பணிச்சுமைகளுக்கு தொகுதி செயலாக்கம் பொருத்தமானது என்பதை தீர்மானிக்கிறது
• சின்க்ரோனஸ், அசின்க்ரோனஸ் மற்றும் பேட்ச் ப்ராசஸிங்கிற்கு இடையேயான விலை/தாமத பரிமாற்றத்தைப் புரிந்துகொள்கிறது
• கஸ்டம்_ஐடியுடன் முடிவுகளுடன் பொருந்தக்கூடிய வலுவான தொகுதி பணிப்பாய்வுகளை வடிவமைக்கிறது

பெரும்பாலான LLM ஒருங்கிணைப்புகள் "நேரடி" காட்சிகளில் கவனம் செலுத்துகின்றன, அங்கு ஒரு பயனர் ஒரு திரையின் முன் பதிலுக்காக காத்திருக்கிறார். ஆனால் பெரும்பாலான தொழில்முறை பணிச்சுமைகள் உண்மையில் நேரலையில் இல்லை: ஆயிரக்கணக்கான ஆவணங்களை ஒரே இரவில் குறியிடுதல், முழு தரவுத்தொகுப்பைச் சுருக்கி, காப்பகத்தில் உள்ள முழு அழைப்புப் பதிவுகளையும் வகைப்படுத்துதல். இந்த விவகாரங்களில், உடனடி பதிலை யாரும் எதிர்பார்க்க மாட்டார்கள்; முக்கிய விஷயம் என்னவென்றால், வேலையை மலிவாகவும் நம்பகத்தன்மையுடனும் முடிக்க வேண்டும். இந்த பணிச்சுமைகளுக்கு தொகுதி சரியாக உள்ளது. இந்த யூனிட்டில், சின்க்ரோனஸ், அசின்க்ரோனஸ் மற்றும் பேட்ச் ப்ராசஸிங் ஆகியவற்றுக்கு இடையேயான வித்தியாசத்தை நீங்கள் கற்றுக்கொள்வீர்கள், தொகுப்பே சரியான தேர்வாக இருக்கும் போது, ​​மற்றும் கஸ்டம்_ஐடி மற்றும் முடிவுகளுடன் நம்பிக்கையுடன் பொருந்தக்கூடிய வலுவான ஓட்டம்.

மூன்று வேலை முறைகள்

முறை

இது எப்படி வேலை செய்கிறது

தாமதம்

வழக்கமான செலவு

பொருத்தமான வேலை

ஒத்திசைவான

நீங்கள் ஒரு கோரிக்கையை வைத்து, பதிலுக்காக காத்திருக்கவும்

வினாடிகள்

தரநிலை

நேரடி அரட்டை, உடனடி உதவியாளர்

ஒத்திசைவற்ற

நீங்கள் வேலையை வரிசைப்படுத்தி, அது முடிந்ததும் அறிவிப்பைப் பெறுவீர்கள்.

வினாடிகள்-நிமிடங்கள்

தரநிலை

பின்னணி பணிகள், ஆட்டோமேஷன் படிகள்

தொகுதி

ஒரு தொகுப்பில் ஆயிரக்கணக்கான கோரிக்கைகளை அனுப்புகிறது, பின்னர் முடிவுகளைப் பெறுகிறது

நிமிடங்கள் - மணிநேரம்

பொதுவாக தள்ளுபடி

அதிக அளவு, தாமதத்தைத் தாங்கும் வேலைகள்

தொகுதி செயலாக்கம் இதுதான்: நீங்கள் நூற்றுக்கணக்கான/ஆயிரக்கணக்கான கோரிக்கைகளை ஒரே "வேலையாக" வழங்குநருக்கு அனுப்புகிறீர்கள்; வழங்குநர் அவற்றை அதன் சொந்த வேகத்தில் செயலாக்குகிறார் மற்றும் முடிந்ததும் அனைத்து முடிவுகளையும் மொத்தமாகத் தருகிறார். பதிலுக்கு நீங்கள் இரண்டு விஷயங்களைப் பெறுவீர்கள்: (1) பொதுவாக குறைந்த யூனிட் செலவு, (2) வேக வரம்புகளைக் கையாளாமல் அதிக ஒலியை நகர்த்தும் திறன். விலை என்னவென்றால், முடிவுகள் உடனடியாக வராது, ஆனால் சிறிது நேரம் கழித்து.

எப்போது பேட்ச் செய்வது, எப்போது இல்லை?

முடிவு ஒரு கேள்விக்கு கீழே வருகிறது: பயனர் இப்போது முடிவுக்காக காத்திருக்கிறாரா?

• இல்லை, நான் அதை வைத்திருக்க முடியும் → தொகுதி வேட்பாளர். இரவு குறியிடல், தொகுதி சுருக்கம், காப்பக வகைப்பாடு, தரவு செறிவூட்டல், மதிப்பீடு (eval) செயல்படுத்தல்.
• ஆம், திரையில் காத்திருக்கிறது → ஒத்திசைவு. நேரடி அரட்டை, உடனடி ஆலோசனை, படிவங்களை நிரப்பும்போது உதவி.

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

வலுவான தொகுதி ஓட்டத்தின் உடற்கூறியல்

தொகுதி செயலாக்கத்தின் மிக முக்கியமான தொழில்நுட்ப விதி முடிவு பொருத்தம் ஆகும்.

1. ஒவ்வொரு கோரிக்கைக்கும் ஒரு தனிப்பட்ட `கஸ்டம்_ஐடி` வழங்கவும். கோரிக்கையை அடையாளம் காணும் நீங்கள் உருவாக்கிய ஐடி இதுவாகும் (எ.கா. விலைப்பட்டியல்-2026-07-18-000431).
2. வேலையைச் சமர்ப்பிக்கவும். அனைத்து கோரிக்கைகளும் ஒரு தொகுப்பில் செல்கின்றன; ஒவ்வொன்றும் அதன் சொந்த custom_id.
3. நிலைமையை வாக்களிக்கவும். வேலை "முடியும்" வரை இடைவெளியில் அந்தஸ்து கேட்கிறீர்கள்.
4. முடிவுகளை `கஸ்டம்_ஐடி` உடன் பொருத்தவும். சமர்ப்பிப்பு வரிசையை விட வேறு வரிசையில் முடிவுகள் வழங்கப்படலாம்; எனவே நிலையுடன் பொருந்தாது ஆனால் custom_id மூலம் ஒவ்வொரு முடிவும் உள்ளது.
5. ஒவ்வொரு முடிவின் வகையையும் சரிபார்க்கவும். ஒரு கோரிக்கை வெற்றியடையலாம், ஒன்று தோல்வியடையலாம், ஒன்று காலாவதியாகலாம். வெற்றி/தோல்வி அடிப்படையிலான செயல்முறை.

{ "கோரிக்கைகள்": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "விலைப்பட்டியலை வகைப்படுத்தவும். JSON மட்டும் திரும்பப் பெறவும்.", "{செய்திகளை": "{{invoice_text}}" }] }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Classify invoice:" "user", "content": "{{invoice_text_2}}" }] } } ]}

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

நகலெடுக்கக்கூடிய வார்ப்புருக்கள்

# தனிப்பயன்_ஐடி தலைமுறை விதி (தனித்துவமானது மற்றும் கண்டறியக்கூடியது) வடிவம்: <isture>-<date>-<வரிசை>. உதாரணம்: கோரிக்கை-20260718-000431விதி: வேலையில் திரும்ப வேண்டாம்; ஆதார பதிவு ஐடியை அதில் உட்பொதிக்கவும்.

# தொகுதி வேலை அட்டை (திட்டமிடல் டெம்ப்ளேட்)வேலையின் பெயர்: .............பதிவுகளின் எண்ணிக்கை: .............மாடல்: ............. (எளிய வேலை → வேகமான மாடல்)ஒரு கோரிக்கைக்கான அதிகபட்ச_டோக்கன்கள்: .............எதிர்பார்க்கப்படும் டெலிவரி நேர சகிப்புத்தன்மை: ......... மணிநேரம் முடிவு பொருந்தக்கூடிய விசை: custom_id பிழை ஏற்பட்டால்: வரிசை / அறிக்கை / மறு முயற்சி

# தொகுப்பில் ஒற்றை கோரிக்கை வரியில் (குறுகிய மற்றும் திட்டவட்டமான) இந்த ஆவணத்தை வகைப்படுத்தவும். இந்த JSON ஐத் திருப்பி, கருத்துத் தெரிவிக்கவும்:{"வகை":"...","அவசரம்":"குறைந்த|நடுத்தர|உயர்"}ஆவணம்: """{{ஆவணம்}}"""

# ஒவ்வொரு முடிவிற்கும் போலி-குறியீடு செயலாக்கம்: result.status == "வெற்றி": பதிவு = கண்டறிதல் (கஸ்டம்_ஐடி) சேமி(பதிவு, முடிவு.அவுட்புட்) இல்லையெனில்: add_to_fail(custom_id, result.error) # பிறகு மீண்டும் முயலவும்

பலவீனமான ப்ராம்ட் / ஸ்ட்ராங் ப்ராம்ட் (தொகுதி வேலை வடிவமைப்பு)

# பலவீனமான (பலவீனமான வடிவமைப்பு) வலுவான மாதிரியுடன் 10,000 ஆவணங்களை அனுப்பவும், திரும்பிய முடிவுகளை அவை வரும் வரிசையில் சேமிக்கவும்.

# வலுவான (நீடித்த வடிவமைப்பு) வேகமான மாதிரியுடன் ஒரு தொகுப்பில் 10,000 ஆவணங்களை அனுப்பவும். ஒவ்வொரு ஆவணத்திற்கும் மூல-பதிவு ஐடியைக் கொண்ட தனித்துவமான தனிப்பயன்_ஐடியை வழங்கவும். முடிவுகளை custom_id உடன் பொருத்தவும்; தோல்வியுற்றவற்றை வரிசைப்படுத்தி மீண்டும் முயற்சிக்கவும்.இரவு சாளரத்தில் இயக்கவும்; டெலிவரி சகிப்புத்தன்மை 6 மணி நேரம்.

சக்திவாய்ந்த பதிப்பு; இது மாதிரி தேர்வு, பொருந்தும் விசை, பிழை கையாளுதல் மற்றும் நேரம் ஆகியவற்றை முன் வரையறுக்கிறது. பல்லாயிரக்கணக்கான பதிவுகளைப் பாதுகாப்பாகச் செயலாக்குவதில் உள்ள வித்தியாசம் இதுதான்.

மூன்று சிறிய வழக்குகள்

வழக்கு 1 - இரவு குறியிடல். ஒரு ஈ-காமர்ஸ் குழு 200,000 தயாரிப்பு மதிப்புரைகளை உணர்வு குறிச்சொற்களாக வரிசைப்படுத்தும். நேரடி ஒத்திசைவான ஸ்ட்ரீமிங் வேக வரம்புகளுக்கு உட்பட்டது மற்றும் விலை உயர்ந்தது. வேகமான மாதிரியுடன் ஒரு தொகுதியாக இரவு வரை வேலையைச் செய்தனர்; யூனிட் விலை குறைந்தது, முழு செட் காலையில் தயாராக இருந்தது, வேக வரம்பு பிரச்சனைகள் இல்லை.

வழக்கு 2 - ஒழுங்கு குழப்பம். ஒரு ஆராய்ச்சி குழு தொகுதி 5,000 கட்டுரைகளை சுருக்கியது, ஆனால் அவை வந்த வரிசையில் முடிவுகளை கோப்புகளாக எழுதியது. முடிவுகள் வேறு வரிசையில் அனுப்பப்பட்டதால், 5,000 சுருக்கங்களில் தோராயமாக 900 தவறான கட்டுரையுடன் இணைக்கப்பட்டுள்ளன. அவர்கள் அதை custom_idக்கு மறுவடிவமைத்தனர்; சிக்கல் தீர்க்கப்பட்டது மற்றும் இந்த அனுபவம் நிரந்தர விதியாக மாறியது: "எப்போதும் custom_id தொகுப்பில்."

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

பொதுவான தவறுகள்

• நிலையின்படி முடிவுகளைப் பொருத்துதல்: ஒழுங்கு பாதுகாக்கப்படவில்லை; custom_id ஐப் பயன்படுத்தவும்.
• நேரடி வேலையை தொகுதிக்கு மாற்றுதல்: பயனர் நிமிடங்களுக்கு காத்திருக்க முடியாது; தொகுதி தாமதத்தை பொறுத்துக்கொள்ளும் வேலைகளுக்கானது.
• பிழை வழக்குகளைக் கையாளவில்லை: சில கோரிக்கைகள் தோல்வியுற்ற/காலாவதியானதாகத் திரும்பலாம்; தனி வரிசையில் வைத்து மீண்டும் முயலவும்.
• தொகுதியில் வலுவான மாடல் பயன்பாட்டு ரிஃப்ளெக்ஸ்: வேகமான மாடல் + தொகுதி எளிய வேலைகளில் மலிவான கலவையாகும்.
• தனிப்பயன்_ஐடியை கண்டறிய முடியாது: ஐடியில் எந்த மூலப் பதிவும் உட்பொதிக்கப்படவில்லை என்றால், முடிவை மீண்டும் இணைப்பது கடினமாகிவிடும்.
• நிலைமையை ஆய்வு செய்ய மறந்துவிட்டது: வேலை முடிவதற்குள் முடிவுகளை எதிர்பார்க்கிறது; நிறைவு நிலையை சரிபார்க்கவும்.

ஆழமான: கண்காணிப்பு தொகுதி மற்றும் பகுதி தோல்வியை நிர்வகித்தல்

தொகுதி செயலாக்கத்தின் மிகவும் முதிர்ந்த அம்சம் என்னவென்றால், தனிப்பட்ட அழைப்புகளை விட வித்தியாசமான மனநிலை தேவைப்படுகிறது: ஒரு தொகுதி வேலை என்பது ஒரு "செயல்முறை", ஒரு "நிகழ்வு" அல்ல. பல்லாயிரக்கணக்கான கோரிக்கைகள் அனைத்தும் வெற்றியடையும் என்று கருதுவது உடையக்கூடியது; யதார்த்தமான வடிவமைப்பு தொடக்கத்திலிருந்தே ஓரளவு தோல்வியை ஏற்றுக்கொள்கிறது. ஒவ்வொரு முடிவின் நிலையும் வித்தியாசமாக இருக்கலாம்: வெற்றி, தோல்வி (எ.கா. தவறான உள்ளீடு), ரத்து செய்யப்பட்டது அல்லது காலாவதியானது. ஒரு வலுவான ஓட்டமானது, ஒவ்வொரு முடிவுகளின் நிலையையும் தனித்தனியாகச் செயல்படுத்துகிறது, அது அதன் வழியாக பயணிக்கும்போது, ​​தோல்விகளை ஒரு தனி "மீண்டும் முயற்சி வரிசையில்" வைத்து, அந்த வரிசையை தனித்தனியாக இயக்குகிறது.

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

மூன்றாவது புள்ளி, லைவ் ஸ்ட்ரீம்களை தொகுப்புடன் தடுமாறச் செய்வது. சில வேலைகள் நேரடி மற்றும் தொகுதி பரிமாணங்களைக் கொண்டிருக்கின்றன: பயனர் ஒரு ஆவணத்தை ஏற்றும்போது, ​​நீங்கள் அவர்களுக்கு விரைவான ஆரம்ப சுருக்கத்தை (ஒத்திசைவு) வழங்குகிறீர்கள், மேலும் இரவில் ஆழமான பகுப்பாய்வுக்காக அதே ஆவணத்தை மீண்டும் செயலாக்கவும் (தொகுதி). இரண்டு முறைகளையும் உணர்வுபூர்வமாகப் பிரிப்பது பயனர் அனுபவம் மற்றும் செலவு இரண்டையும் மேம்படுத்துகிறது.

இறுதியாக, பேட்சிங் என்பது வேக வரம்புகளைக் கையாள்வதற்கான ஒரு வழியாகும் (அலகு 8). நேரடி ஒத்திசைவான ஓட்டத்தில் அதிக ஒலியளவை அனுப்புவது நிலையான 429 ஐ உருவாக்குகிறது, அதே வேளையில் அதே ஒலியளவை தொகுதி பரிமாற்றங்களுக்கு அனுப்புவது வழங்குநரின் சொந்த திட்டமிடலுக்கு அழுத்தம் கொடுக்கிறது மற்றும் வேலையை மேலும் கணிக்கக்கூடியதாக ஆக்குகிறது.

சுருக்கமாக

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

விண்ணப்ப பணி

அதிக அளவிலான வேலையைத் தேர்ந்தெடுக்கவும் (எ.கா. காப்பக வகைப்பாடு). (1) இந்த வேலை நேரடிதா அல்லது கூட்டுதா என்பதை முடிவு செய்து அதை நியாயப்படுத்தவும். (2) custom_id வடிவமைப்பை வடிவமைக்கவும் (வளப் பதிவையும் சேர்த்து). (3) தொகுதி வேலை அட்டையை நிரப்பவும் (மாதிரி, அதிகபட்ச_டோக்கன்கள், சகிப்புத்தன்மை, பிழை கொள்கை). (4) தோல்வியுற்ற கோரிக்கைகளைச் சேர்க்க முடிவு செயலாக்க சூடோகுறியீட்டை எழுதவும்.

சரிபார்ப்பு பட்டியல்

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