مینا حسابدار یک فروشگاه لوازم خانگی در اصفهان است. هر روز حدود چهل رسید کاغذی روی میزش جمع میشود: فاکتور فروش، رسید باربری، قبض تعمیرکار. یک سال است که عکسها را تکتک در چت هوش مصنوعی میگذارد و میپرسد «مبلغ و تاریخ این را بنویس». جوابها معمولاً درستاند، اما کار همچنان دستی است: باز کردن، آپلود، کپی، چسباندن، و دوباره از اول. مینا حالا میخواهد همین کار را خودکار کند و به دیوار میخورد؛ چون نمیداند عکس، وقتی از مسیر برنامهنویسی میرود، چه شکلی باید داشته باشد.
این دقیقاً همان جایی است که کوکبوک رسمی آنتروپیک شروع میکند. تصویر برای مدل، یک «پیوست» جداگانه نیست؛ یک بلوک از محتوای همان پیام کاربر است — درست کنار متن، در همان آرایه. وقتی این یک جمله را بفهمید، بقیهٔ ماجرا — چند عکس فرستادن، ترتیب عکس و متن، هزینه و محدودیتها — همه از دل همان ساختار بیرون میآید. در این درس همان مسیر را از صفر میرویم.
لیست مطالب
آنچه در این درس یاد میگیرید
- ساختار بلوک محتوا و اینکه چرا تصویر و متن در یک آرایهٔ واحد کنار هم مینشینند.
- سه راه رساندن عکس به مدل: کدگذاری فایل محلی، نشانی اینترنتی، و بارگذاری یکبار برای همیشه.
- قاعدهٔ ترتیب: چرا تصویر باید پیش از پرسش بیاید، نه بعد از آن.
- فرستادن چند تصویر در یک درخواست و ترفند برچسبگذاری برای اینکه مدل قاطی نکند.
- حسابوکتاب هزینه: تصویر چند توکن است و چرا تغییر اندازه پیش از ارسال، هم پول و هم دقت را نگه میدارد.
- محدودیتهای واقعی؛ کارهایی که مدل روی تصویر انجام نمیدهد و نباید انتظارش را داشت.
- یک پرامپت فارسی آمادهٔ کپی برای استخراج داده از رسید و فاکتور.
ساختار پیام؛ تصویر یک بلوک است، نه یک پیوست
در تجربهٔ چتِ روزمره، عکس را با گیره «ضمیمه» میکنید و انگار چیزی جدا از متن است. در سطح رابط برنامهنویسی چنین چیزی وجود ندارد. هر پیام کاربر یک فهرست از بلوکهاست و هر بلوک یک نوع دارد: یا text است یا image. بلوک تصویر خودش یک منبع دارد که میگوید داده از کجا میآید و از چه نوعی است.
سادهترین حالت، یک عکس روی دیسک شماست. آن را به رشتهٔ کدگذاریشده تبدیل میکنید و در همان آرایه، پیش از پرسش، میگذارید:
import base64
from anthropic import Anthropic
client = Anthropic()
MODEL_NAME = "claude-opus-4-1"
with open("receipt.jpeg", "rb") as image_file:
binary_data = image_file.read()
base64_string = base64.b64encode(binary_data).decode("utf-8")
message_list = [
{
"role": "user",
"content": [
{
"type": "image",
"source": {
"type": "base64",
"media_type": "image/jpeg",
"data": base64_string,
},
},
{"type": "text", "text": "مبلغ کل و تاریخ این رسید را بنویس."},
],
}
]
response = client.messages.create(model=MODEL_NAME, max_tokens=2048, messages=message_list)
print(response.content[0].text)
سه نکته در همین قطعهٔ کوتاه پنهان است. اول اینکه media_type باید با فرمت واقعی فایل بخواند؛ اگر فایل png است و شما image/jpeg بنویسید، درخواست رد میشود. چهار فرمت پذیرفته میشود: جیپگ، پیانجی، وبپی و گیف — و از گیف متحرک فقط فریم اول دیده میشود. دوم اینکه data باید رشتهٔ متنی باشد، نه بایت خام؛ فراموشکردن decode رایجترین خطای این مرحله است. سوم اینکه ترتیب اقلام آرایه معنادار است و همینجا به قاعدهٔ بعدی میرسیم.
سه راه رساندن تصویر
راه دوم، وقتی عکس روی وب است، این است که آن را دانلود و کدگذاری کنید؛ همان الگوی بالا با یک درخواست شبکه در ابتدا. اما نسخههای تازهتر رابط برنامهنویسی مسیر کوتاهتری هم دارند: منبع از نوع نشانی، که خود سرویس فایل را میگیرد و شما اصلاً درگیر کدگذاری نمیشوید:
{
"type": "image",
"source": {"type": "url", "url": "https://example.com/invoice.jpg"},
}
راه سوم برای کسی مثل مینا مهمتر است. اگر قرار باشد دربارهٔ یک تصویر چند بار گفتوگو شود — یک بار مبلغ، یک بار نام فروشنده، یک بار اقلام — کدگذاری دوباره و دوبارهٔ همان فایل هم پهنای باند میخورد و هم درخواست را سنگین میکند. راهحل، بارگذاری یکبارهٔ فایل و ارجاع به شناسهٔ آن در پیامهای بعدی است؛ منبع از نوع فایل، با کلید شناسه. برای خطوط پردازشی که روی صدها سند کار میکنند، همین یک تغییر تفاوت محسوسی در سرعت میسازد.
قاعدهٔ ترتیب؛ اول تصویر، بعد پرسش
توصیهٔ صریح مستندات این است: تصویر را پیش از متن بگذارید. دلیلش به شیوهٔ خواندن مدل برمیگردد؛ وقتی پرسش پس از تصویر میآید، مدل هنگام پردازش پرسش، تصویر را در زمینهٔ خود دارد و میتواند توجهش را روی همان بخشهای مرتبط متمرکز کند. ترتیب برعکس هم کار میکند، ولی بهطور سیستماتیک کمی ضعیفتر جواب میدهد. این از آن قاعدههایی است که هزینهٔ رعایتش صفر است و بهتر است از همان اولین اسکریپت رعایتش کنید.
این همان منطقی است که در درس بهترین تمرینهای پرامپتنویسی کلود هم دیدیم: هر چیزی که مدل برای فهم دستور لازم دارد، باید پیش از دستور آمده باشد، نه بعد از آن.
چند تصویر در یک درخواست
وقتی بیش از یک عکس میفرستید، مشکل تازهای پیدا میشود: مدل باید بداند شما دربارهٔ کدامیک حرف میزنید. راهحل رسمی، فاصلهانداختن بلوکهای متنی کوتاه میان تصویرهاست تا هرکدام اسم و شماره بگیرند:
{
"role": "user",
"content": [
{"type": "text", "text": "تصویر ۱ — فاکتور فروردین:"},
{"type": "image", "source": {"...": "..."}},
{"type": "text", "text": "تصویر ۲ — فاکتور اردیبهشت:"},
{"type": "image", "source": {"...": "..."}},
{"type": "text", "text": "تفاوت مبالغ این دو فاکتور را در یک جدول بنویس."},
],
}
بدون این برچسبها، پاسخها بهسرعت مبهم میشوند («در تصویر اول… یا شاید دومی…»). با برچسب، میتوانید در پرسش هم مستقیم به «تصویر ۲» ارجاع دهید و خروجی ساختاریافته بگیرید. سقف تعداد هم دستودلبازانه است: در رابط برنامهنویسی دهها تصویر در یک درخواست ممکن است، در حالی که در محیط چت وب سقف بیست تصویر در هر پیام است.
میخواهید سه عکس از سه صفحهٔ یک قرارداد را در یک درخواست بفرستید و بپرسید کدام صفحه بند جریمهٔ تأخیر را دارد. کدام چیدمان با توصیهٔ رسمی میخواند؟
هزینه و اندازه؛ چیزی که پیش از ارسال باید بدانید
تصویر برای مدل به تکههای کوچک بیستوهشت در بیستوهشت پیکسل شکسته میشود و هر تکه یک توکن بصری است. یعنی تعداد توکنها تقریباً برابر است با حاصلضرب سقفِ عرض تقسیم بر بیستوهشت در سقفِ ارتفاع تقسیم بر بیستوهشت. یک عکس هزار در هزار پیکسل حدود هزار و سیصد توکن میشود — تقریباً به اندازهٔ دو صفحه متن.
اینجا یک تصور غلط رایج را باید کنار گذاشت: فرستادن عکس با کیفیت بالاتر لزوماً جواب بهتری نمیدهد. تصویرهای بزرگتر از سقف مجاز، خودکار کوچک میشوند و شما فقط هزینهٔ ارسال داده را پرداختهاید. سقفهای عملی اینهاست: حداکثر حجم ده مگابایت، حداکثر ابعاد هشت هزار در هشت هزار پیکسل، و برای مدلهای استاندارد بزرگترین ضلع مفید حدود هزار و پانصد پیکسل (مدلهای نسل جدید سقف بالاتری دارند). عکس گوشی مینا معمولاً چهار هزار پیکسل عرض دارد؛ اگر خودش پیش از ارسال آن را به هزار و پانصد پیکسل برساند، هم حجم درخواست چند برابر کم میشود و هم میتواند کیفیت فشردهسازی را خودش کنترل کند — و همین کنترل، برای متنهای ریز رسید، از کوچکسازی خودکار بهتر جواب میدهد.
نکتهٔ آخر همین بند مهم است: فشردهسازی شدید جیپگ، اولین چیزی که خراب میکند لبهٔ حروف است. اگر کارتان خواندن متن از عکس است، سختگیری روی کیفیت فشردهسازی بیش از سختگیری روی ابعاد جواب میدهد.
کاری که مدل با تصویر نمیکند
هر ابزاری با شناختن مرزهایش قابل اعتماد میشود. مدل، افراد داخل عکس را نامگذاری و شناسایی نمیکند. روی تصویرهای خیلی کوچک — زیر حدود دویست پیکسل — قابل اتکا نیست. مختصات دقیق و پیکسلی نمیدهد و تخمینهایش تقریبی است؛ پس برای کاربردهایی که به موقعیت دقیق نیاز دارند، نباید جای ابزار بینایی تخصصی بنشیند. شمردن تعداد زیادی شیء ریز در یک قاب هم از نقاط ضعف شناختهشده است. و تفسیر تصویربرداری پزشکی پیچیده مثل سیتیاسکن و امآرآی صراحتاً خارج از کاربردهای توصیهشده است.
پرامپت آمادهٔ کپی برای رسید و فاکتور
حالا همهچیز را برای مینا جمع کنیم. تصویر پیش از متن، خروجی برچسبدار، و اجازهٔ صریح گفتن «ذکر نشده» تا مدل جای خالی را با حدس پر نکند:
تو یک حسابدار دقیقی که از تصویر رسید، داده استخراج میکند.
از روی تصویر بالا فقط این اقلام را بنویس، هرکدام در یک خط:
نام فروشنده:
شماره فاکتور:
تاریخ:
مبلغ کل:
مبلغ مالیات:
روش پرداخت:
قواعد:
- اگر قلمی در تصویر خوانا نیست یا اصلاً نیامده، بنویس «ذکر نشده».
- عدد را همانطور که در تصویر آمده بنویس؛ واحد را تغییر نده.
- هیچ توضیح اضافهای ننویس و بدون مقدمه شروع کن.
همین ساختار، هستهٔ یک خط لولهٔ خودکار است: پوشهای از عکسها، یک حلقه، و خروجی برچسبدار که مستقیم به فایل صفحهگسترده میرود. اگر میخواهید یک قدم جلوتر بروید و این را به یک دستیار خودکار تبدیل کنید، دورهٔ ساخت ایجنت هوش مصنوعی همین حلقه را با ابزار و حافظه کامل میکند. و اگر خروجیهای استخراجشده باید بعداً جمعبندی شوند، درس خلاصهسازی هدایتشده ادامهٔ طبیعی همین مسیر است.
این تمرین ویژهٔ اعضاست
برای دیدن این بخش باید عضو ویژه (VIP) باشی. با شمارهٔ موبایلت وارد شو تا ۱۴ روز دسترسی رایگان فعال شود.
🎁 ورود / ثبتنام و شروع ۱۴ روز رایگانجمعبندی
پنج چیز را با خودتان ببرید: تصویر یک بلوک در آرایهٔ محتواست نه یک پیوست جداگانه؛ نوع رسانه باید با فایل واقعی بخواند؛ تصویر پیش از پرسش میآید؛ چند تصویر بدون برچسب یعنی پاسخ مبهم؛ و بزرگتر همیشه بهتر نیست، چون تصویرِ فراتر از سقف فقط هزینهاش را میپردازید. مینای اول این درس با همین پنج نکته میتواند فردا صبح بهجای چهل بار آپلود دستی، یک اسکریپت دهخطی اجرا کند و بعدازظهر را صرف کاری کند که هیچ مدلی جایش را نمیگیرد: تطبیق همین اعداد با دفتر فروش.
و چرا این تکنیک کهنه نمیشود؟ چون آنچه یاد گرفتیم به هیچ مدل خاصی گره نخورده است. نام مدلها عوض میشود، سقف رزولوشن بالا میرود و شاید روزی تغییر اندازهٔ دستی لازم نباشد؛ اما ایدهٔ بنیادی سرِ جایش میماند: تصویر و متن، دو نوع از یک جنساند و در یک آرایهٔ واحد کنار هم مینشینند، و ترتیب و برچسبگذاری آنها همانقدر بخشی از پرامپتنویسی است که انتخاب واژهها. هر مدل چندوجهی تازهای که بیاید، همین ساختار را با نام دیگری بازتولید میکند. یادگیری میانبر ندارد؛ اما ابزار دارد.
منبع این درس، مستندات رسمی آنتروپیک است؛ ما آن را برای فارسیزبانها درس کردهایم.
