தன்னையே செயல்படுத்திகொள்கின்ற பைதானின் செயலி(Function)

ஆவணத்தின்சரம்(docstring) செயல்படுத்துவதாக இருக்கும் ஒரு பைதான் செயலியை எழுத முடிந்தால் என்ன செய்வது? உள்ளீடுகள், மீள்வு(return) வகையை வரையறுக்கின்றோம், மேலும் “correct” என்றால் என்ன என்பதை வரையறுக்கும் சரிபார்ப்பு தர்க்கத்தை எழுதுகின்றோம். மீதமுள்ளவற்றை செய்யறிவு(AI) ஆனது தானாகவே கையாளுகிறது.
செய்யறிவு(AI) ஆனது செயலிகளுக்குப் பின்னால் உள்ள நிரலாக்க மாதிரி அதுதான், இது Strandsஎனும் ஆய்வகத்தின் புதிய பரிசோதனை நூலகமாகும்.
Strands ஆய்வகம் என்பது ஒரு புதிய GitHub அமைப்பாகும், அங்கு Strandsஇன்முகவரின் SDK இன் பரிசோதனை வசதிகள் திறந்த நிலையில் கட்டமைக்கப்படுகின்றன.
செய்யறிவின்(AI) செயலிகளுடன் இன்னும் சரிபார்ப்பு தர்க்கத்தை எழுதுகின்றோம், ஆனால் செயலியை செயல்படுத்துவதற்குப் பதிலாக, செய்யறிவு(AI) உருவாக்கத்தைக் கையாளவும் நம்முடைய சரிபார்த்தல்களுக்கு எதிராக சுய-சரிசெய்தலையும் அனுமதிக்கின்றோம்.
செய்யறிவு(AI) -இயக்கப்படும் குறிமுறைவரிகளை எழுதுவதற்கான வேறுபட்ட வழிமுறை
பெரும்பாலான செய்யறிவு(AI)ஆனது -இயக்கப்படும் குறிமுறைவரிகளை அதே வழிமுறையைப் பின்பற்றுகிறது. மாதிரியை அழைக்கின்றோம், பதிலை அலசிஆய்வுசெய்கின்றோம், சரிபார்ப்பிற்கான சரிபார்த்தல்களை எழுதுகின்றோம், பிழைகளைக் கையாளுகின்றோம், செயல் தவறாக நடக்கும்போது மீண்டும் முயற்சிக்கின்றோம். இவ்வாறு எல்லோரும் சற்று வித்தியாசமாக எழுதுவது கடினமானது.
செய்யறிவு(AI) செயலிகள் இந்த வழிமுறையைத் தலைகீழாக மாற்றுகின்றன.
ஒரு செயல்பாட்டு கையொப்பம், தூண்டுதல்எழுத்துச் செயல்படும் ஒரு ஆவணச்சரம், ஒப்பந்தத்தை வரையறுக்கும் ஒரு மீள்வு வகை , சரியானது எவ்வாறு இருக்கும் என்பதை வரையறுக்கும் பின்நிபந்தனைகளை எழுதுகின்றோம். எந்தவொரு செயலியின் உள்ளடக்கமும் இல்லை. ஆனால் செயலியானதுCPU க்கு பதிலாக ஒரு LLM இல் இயங்குகிறது.
இங்கே முக்கியமானது என்னவென்றால், இன்னும் உண்மையான சரிபார்ப்பு குறிமுறைவரிகளை எழுதுகின்றோம். பின்நிபந்தனைகள் எழுதிய சாதாரண பைதான் செயலிகள். ஏற்றுக்கொள்ளும் அளவுகோல்களை வரையறுக்கின்றோம், மேலும் அமைவுஆனது அதை செயல்படுத்துகிறது.
ஏற்புகைஆவண பாகுபடுத்தி
ஏற்புகைஆவண பாகுபடுத்தியுடன் இது எப்படி இருக்கும் என்று பார்ப்போம்.
பிரித்தெடுத்தல்ஆனது தானே தெளிவற்றதாக இருப்பதால் ஏற்புகைஆவணங்கள் இந்த வடிவத்திற்கு ஒரு நல்ல பொருத்தமாகும் (விற்பனையாளர்கள் ஏற்புகைஆவணங்களை வித்தியாசமாக வடிவமைக்கிறார்கள், வரி உருப்படிகள் மாறுபடும், வரி விதிகள் மாறுகின்றன), ஆனால் சரிபார்ப்பு தீர்மானிக்கப்படுகிறது. கணிப்பான் எளிய எண்கணிதத்துடன் சேர்க்கப்படுகிறதா என்பதைச் சரிபார்க்க ஒரு பின்நிபந்தனையை எழுதலாம்.
நடைமுறையில், பெரும்பாலான ஏற்புகைஆவணங்கள் உருவப்படங்கள்(image) அல்லது PDFகளாகத் தொடங்குகின்றன. இந்த எடுத்துக்காட்டு நாம் ஏற்கனவே OCR அல்லது ஆவண செயலாக்க சேவையைப் பயன்படுத்தி உரையைப் பிரித்தெடுத்துவிட்டோம் என்று கருதுகிறது, இப்போது அந்த மூல உரையை கட்டமைக்கப்பட்ட, சரிபார்க்கப்பட்ட தரவாக மாற்ற வேண்டும்.
இரண்டாவது படிமுறையைக் கையாளும் ஒன்றை நாம் உருவாக்குவோம்: ஏற்புகைஆவண உரையிலிருந்து கட்டமைக்கப்பட்ட தரவைப் பிரித்தெடுப்பது . கணிப்பான் உண்மையில் சேர்க்கிறதா என்பதைச் சரிபார்ப்பது.
from pydantic import BaseModel, Field
from ai_functions import ai_function
class LineItem(BaseModel):
description: str = Field(description=”Item or service description”)
quantity: int = Field(description=”Number of units”)
unit_price: float = Field(description=”Price per unit”)
amount: float = Field(description=”Total for this line item (quantity * unit_price)”)
class ReceiptData(BaseModel):
vendor: str = Field(description=”Vendor or company name”)
invoice_number: str = Field(description=”Invoice or receipt number”)
date: str = Field(description=”Invoice date (YYYY-MM-DD format)”)
items: list[LineItem] = Field(description=”List of line items”)
subtotal: float = Field(description=”Sum of all line item amounts before tax”)
tax: float = Field(description=”Tax amount”)
total: float = Field(description=”Final total (subtotal + tax)”)
def validate_math(result: ReceiptData) -> None:
“””Validate that all math is internally consistent.”””
errors = []
# Check line items: amount = quantity × unit_price
for i, item in enumerate(result.items):
expected = item.quantity * item.unit_price
if abs(item.amount – expected) > 0.01:
errors.append(
f”Line item {i} ({item.description}): amount {item.amount} != “
f”quantity {item.quantity} * unit_price {item.unit_price} = {expected}”
)
# Verify subtotal = sum of line items
items_sum = sum(item.amount for item in result.items)
if abs(result.subtotal – items_sum) > 0.01:
errors.append(f”Subtotal {result.subtotal} != sum of line items {items_sum}”)
# Confirm total = subtotal + tax
expected_total = result.subtotal + result.tax
if abs(result.total – expected_total) > 0.01:
errors.append(f”Total {result.total} != subtotal {result.subtotal} + tax {result.tax} = {expected_total}”)
if errors:
raise ValueError(“\n”.join(errors))
@ai_function(
description=”Parse a receipt or invoice text and extract structured expense data”,
post_conditions=[validate_math],
max_attempts=3,
)
def parse_receipt(receipt_text: str) -> ReceiptData:
“””
Extract structured data from this receipt/invoice.
Receipt text: {receipt_text}
Instructions:
– Extract all line items with their quantity, unit price, and total amount
– Calculate subtotal as the sum of all line item amounts
– Extract tax amount (if no tax is listed, use 0.0)
– Calculate total as subtotal + tax
– Use YYYY-MM-DD format for the date
– Ensure all math is consistent
“””
Pydanticஇன் மாதிரிகள் வெளியீட்டின் வடிவத்தை வரையறுக்கின்றன. @ai_function எனும் அலங்காரியானது decorator இதை செய்யறிவு(AI)-இயங்கும் செயலியாகக் குறிக்கிறது. ஆவணத்தின்சரம் நினைவூட்டுதூண்டுதலாக மாறுகிறது, உள்ளீட்டிற்கான வரைச்சட்ட மாறியாக {receipt_text} உள்ளது. திரும்புதல் வகை கணினிக்கு எந்த கட்டமைப்பை உருவாக்க வேண்டும் என்று கூறுகிறது.
குறிப்பிட்ட களப்பெயரில் “correct” என்றால் என்ன என்பதை வரையறுக்க பிந்தைய-நிபந்தனைகள் நம்மை அனுமதிக்கின்றன. அவை வணிக தர்க்கத்தை செயல்படுத்தும் நிலையான பைதான் செயலிகள். கணிப்பான் சேர்க்கப்பட வேண்டும் . விற்பனையாளர் பெயர் காலியாக இருக்க முடியாது. தேதி சரியான வடிவத்தில் இருக்க வேண்டும். இவை தூண்டுதல்எழுத்துப்பெறியாளரின் மூலம் மட்டும் உத்தரவாதம் அளிக்கக்கூடிய செயல்கள் அல்ல.
சில ஏற்புகைஆவணத்தின் உரையுடன் parse_receipt ஐ அழைக்கும்போது என்ன நடக்கும் என்பது பின்வருமாறு.
Hoodஇன் கீழ், நூலகம் ஒரு Strandsஎனும் முகவர் மடக்கிக்கு ஒப்படைக்கிறது. இது ஆவணத்தின்சரத்தை (ஏற்புகைஆவண உரை நிரப்பப்பட்டவுடன்) எடுத்து, அதை மாதிரிக்கு அனுப்புகிறது, மேலும் ஒரு ஏற்புகைஆவண தரவு பொருளைத் திருப்பித் தரச் சொல்கிறது.
இது ஒரு Strandsஎனும்முகவரின் மூலம் இயங்குவதால், இந்த செயலியானது Strands முகவர்களிடம் உள்ள அதே கருவி-பயன்பாட்டு திறன்களுக்கான அணுகலைப் பெறுகிறது, மேலும் ஒருங்கிணைப்பு முதிர்ச்சியடையும் போது, ​​மற்ற Strands வசதிகளுக்கும் இது அணுகலைப் பெறுகிறது. ஆனால் நம்முடைய பார்வையில், அழைப்பாளராக, இது ஒரு Pydantic மாதிரியைத் தரும் ஒரு செயலியின் அழைப்பு மட்டுமே.
மாதிரி பதிலளித்தவுடன், validate_math என்பது முடிவுக்கு எதிராக இயங்குகிறது. ஒவ்வொரு வரி உருப்படியின் தொகையும் அதிகஅளவு மடங்கு அலகு விலைக்கு சமமா, துணைத்தொகை அனைத்து வரி உருப்படிகளின் கூட்டுத்தொகைக்கு சமமா, , மொத்தம் துணைத்தொகைக்கும் , வரிக்கும் சமமா என்பதை இது சரிபார்க்கிறது.
எல்லாம் சரிபார்க்கப்பட்டால், நம்முடைய ReceiptData ஐத் திரும்பப் பெற்றிடுவோம். Validate_math ஆனதுஒரு ValueError ஐ எழுப்பினால், நூலகம் அந்த பிழைச் செய்தியை (“துணைத்தொகை 1,492.30 != வரி உருப்படிகளின் கூட்டுத்தொகை 1,492.80”) எடுத்து, அசல் வரியின் பிரதிபலிப்புடன் மாதிரிக்குத் திருப்பி அனுப்புகிறது. மாதிரி என்ன தவறு செய்தது என்பதை சரியாகப் பார்த்து மீண்டும் முயற்சிக்கிறது. இந்த மடக்கியானது அதிகபட்ச முயற்சிகள் வரை மீண்டும் நிகழ்கிறது, எனவே max_attempts=3 உடன், மாதிரி பரிசோதனைகளை கடந்து செல்லும் வெளியீட்டை உருவாக்க மூன்று வாய்ப்புகளைப் பெறுகிறது.
கவனிக்க வேண்டியது: validate_mathஇன் பிரித்தெடுத்தல் துல்லியத்தை அன்று, உள்ளக நிலைத்தன்மையை சரிபார்க்கிறது. மாதிரியின் குழப்பமான OCR வெளியீட்டிலிருந்து “$8,400” ஐ “$840” என்று தவறாகப் படித்தால், கணிப்பான் முற்றிலும் தவறாக இருக்கும்போது சரிபார்க்க முடியும். ஆனால் கூடுதலான பிந்தைய நிபந்தனைகள் அதற்கானவை. மூல உள்ளீட்டு உரைக்கு எதிராக பிரித்தெடுக்கப்பட்ட மதிப்புகளை குறுக்கு-குறிப்புகள் என்று எழுதலாம், மாதிரியின் திருப்பி அனுப்பப்பட்ட மொத்தம் உண்மையில் ஏற்புகைஆவணத்தில் தோன்றுகிறதா என்பதைச் சரிபார்க்கலாம். அது நடக்கவில்லை என்றால், கணிப்பானின் போது மட்டுமல்ல, பிரித்தெடுத்தலின் போது ஏதோ தவறு நடந்துள்ளது. பயன்பாட்டு வழக்கிற்கு “correct” அர்த்தம் என்னவாக இருந்தாலும், வழிமுறை அளவிடப்படுகிறது.
நாம் கூடுதல் பின்-நிபந்தனைகளையும் சேர்க்கலாம். தேவையான புலங்கள் காலியாக இல்லை என்பதை சரிபார்க்க validate_completeness இருக்கலாம். தேதிகள் சரியாக பாகுபடுத்தப்படுவதை உறுதிசெய்ய validate_date_format இருக்கலாம். ஒவ்வொன்றும் ஏதோ தவறு இருக்கும்போது பிழையை எழுப்பும் ஒரு பைதான் செயலியாகும்.
பரிமாற்றங்கள்
இந்த வழிமுறை சுத்தமாக உள்ளது, ஆனால் சில பரிமாற்றங்கள் உள்ளன.
தாமதம் என்பது முதல் முயற்சி. ஒவ்வொரு மறு முயற்சியும் மற்றொரு மாதிரியின் அழைப்பாகும். max_attempts=3 ஐ அமைத்தால், மாதிரிக்கு மூன்று சுற்று பயணங்கள் வரை பார்க்கின்றோம். தொகுதியின் செயலாக்கம் , பின்னணி வேலைகளுக்கு அது நல்லது. துணை-வினாடி பதில்கள் தேவைப்படும் பயனர் எதிர்கொள்ளும் API களுக்கு இது சிறந்ததன்று.
இரண்டாவது பரிமாற்றம் செலவு. மறு முயற்சிகள் நம்முடைய APIஇன்செலவைப் பெருக்குகின்றன, மேலும் ஒவ்வொரு அழைப்பும் முகவரின் புதிய நிகழ்வைப் பயன்படுத்துகிறது. பிந்தைய நிபந்தனைகள் அடிக்கடி தோல்வியடைந்தால், பிரித்தெடுப்பதற்கு பல முயற்சிகளுக்கு பணம் செலுத்துகின்றோம்.
இந்த மறு முயற்சி வளையம் ஒரு இயல்பானவசதியாகும், பிழை அன்று. சரிபார்ப்பு தோல்வி விகிதங்களைக் கண்காணித்திடுக. பெரும்பாலான முதல் முயற்சிகளில் பிந்தைய-நிபந்தனைகள் தோல்வியடைந்தால், தூண்டப்படும் எழுத்திற்கு வேலை தேவை, அதிக மறு முயற்சிகள் அன்று. பிந்தைய-நிபந்தனைகள் edge cases களைப் பிடிக்கத்தான் உள்ளன, அடிப்படையில் உடைந்த தூண்டப்படும்எழுத்துகளை சரிசெய்ய அன்று.
நாம்ஒருபோதும் செயல்படுத்தாத தர்க்கத்தில் சரியான தன்மை உத்தரவாதங்களுக்கான தாமதத்தின் ,செலவை வர்த்தகம் செய்கின்றோம்.
ஒவ்வொரு ஏற்புகைஆவண வடிவமைப்பையும் எதிர்பார்க்க வேண்டியதில்லை, விற்பனையாளர்கள் வரி உருப்படிகளை எவ்வாறு பட்டியலிடுகிறார்கள் என்பதற்கான ஒவ்வொரு edge caseஐயும் கையாள வேண்டியதில்லை, அல்லது பொதுமக்கள் நாணயத்தை வடிவமைக்கும் டஜன்கணக்கிலான வழிகளைக் கணக்கிடும் ஒரு பாகுபடுத்தியை எழுத வேண்டியதில்லை. மாதிரியானது அந்த தெளிவின்மையைக் கையாளுகிறது, மேலும் பிந்தைய-நிபந்தனைகள் பிழைகளைகண்டு பிடிக்கின்றன.
ஆவண செயலாக்க குழாய்வழிகள், நிதி தரவு பிரித்தெடுத்தல், தவறான பதில் மெதுவான பதிலை விட மோசமான எந்தவொரு பணிக்கும் இது சரியான வர்த்தகமாகும். இது நிகழ்நேர அரட்டை இடைமுகங்கள் அல்லது அதிக அளவு, செலவு உணர்திறன் செயல்பாடுகளுக்கான தவறான வர்த்தகமாகும்.
நூலகம் பரிசோதனைக்குரியது , இது Strands ஆய்வகத்திலிருந்து ஒரு புதிய repo ஆகும். இது ஆராய்வது மதிப்புக்குரியது, மேலும் அது முதிர்ச்சியடையும் போது அது மாறும் என்று எதிர்பார்க்கலாம்.
கீழ் உள்ள தோரணி(Pattern)
இதை மிகவும் சுவாரசியமாக்குவது நிரலாக்க மாதிரி. செயலியின் கையொப்பம் , ஆவணச் சரத்தின் மூலம் நோக்கத்தை அறிவிக்கின்றோம். பிந்தைய-நிபந்தனைகள் மூலம் சரியான தன்மையை வரையறுக்கின்றோம், மேலும் செய்யறிவு(AI) ஆனது செயல்படுத்தலைக் கையாளுகிறது.
இந்தப் பிரிப்பு சரிபார்ப்பு தர்க்கத்தை கட்டுப்படுத்தும், பரிசோதிக்கும் , பதிப்பான உண்மையான பைதான் குறிமுறைவரிகளாக வைத்திருக்கிறது. இது ஒரு நினைவூட்டுதூண்டுதலில் புதைக்கப்படவில்லை அல்லது மாதிரி சரியானது என்று நாம் கூறுவதை “understands” என்று நம்புவதில்லை. தேவைகள் மாறும்போது, ​​ பிந்தைய-நிபந்தனைகளைப் புதுப்பிக்கின்றோம். மாதிரி மேம்படும்போது, குறிமுறைவரிகளை மாற்றாமல் சிறந்த முதல்-முயற்சி வெற்றி விகிதங்களைப் பெற்றிடுவோம்.
பிந்தைய-நிபந்தனைகள் நம்முடைய களப்பெயருக்கு “correct” என்பதை நிரல் ரீதியாக வரையறுக்க ஒரு வழியை நமக்கு வழங்குகின்றன, இது நினைவூட்டுதூண்டுதலின் பொறியியலில் மட்டும் செய்ய முடியாத ஒன்று ஆகும். ஒரு நினைவூட்டு தூண்டுதலின் மாதிரியிடம் “make sure the math adds up,” எனச்சொல்ல முடியும், ஆனால் ஒரு பிந்தைய-நிபந்தனை உண்மையில் அதைச் சரிபார்த்து, அது இல்லாதபோது குறிப்பிட்ட கருத்தை வழங்குகிறது.
இந்தப் புதிய செயல்திட்டத்தைப் பரிசோதிப்பதில் வேடிக்கையாக இருக்கின்றது. தோரணியை(Pattern)நாமே முயற்சித்திடுவோம், இதற்கான நூலகம் github.com/strands-labs/ai-functions இல் கிடைக்கிறது.