قديش بتقدر تصغّر صورة نص قبل ما نموذج الرؤية يبطل يقرأها؟
هاي كانت الفكرة اللي بختبرها. المفاجأة إن النموذج قدر يقرأ النص بعد تصغير الصورة أكثر بكثير مما توقعت. الخطأ كان بحساب التوفير: استخدمت تقديراً تقريبياً لعدد رموز الصورة، وتعاملت معه كأنه استهلاك فعلي سجّله الـ API.
تصحيح للنسخة الأولى: التجارب ما أثبتت خفض عدد الـ tokens إلى الثمن، ولا دعمت المقارنة مع DeepSeek-OCR. اللي بقدر أعرضه هون هو ملاحظات عن قراءة أمثلة قليلة؛ قياس التوفير بيحتاج تجربة مستقلة.
جرّب تبعت هالصورة مع الطلب «اقرأ النص واكتبه كما هو»:
النص الأصلي فيه 1,287 حرفاً. قدرة النموذج على استرجاع نص مفهوم من صورة بهالحجم لافتة، حتى قبل حساب عدد الرموز وكلفتها.
كيف بلّشت الحكاية
كنت بجرّب نماذج لغوية على التلخيص، وبدي أستخدم صوراً ونصوصاً بنفس الطلب. بلّشت أبعت لقطات شاشة، واشتغلت أحسن مما توقعت.
بعدين صغّرتها. وبعدين كمان. وGemini ضل يسترجع نصاً أنا شخصياً ما بستمتع بقراءته بهالحجم. فطلع السؤال: ممكن صورة صغيرة تحمل فقرة طويلة بكلفة أقل من إرسال الفقرة كنص؟
فكرت بتدريب إضافي على نصوص منخفضة الدقة. بس ظل في اعتراض واضح: عند أي حدّ النموذج ببطل يقرأ وبيبدأ يخمّن؟ من غير جواب عن الدقة، تركت الفكرة على الرف.
لما ظهر DeepSeek-OCR، رجعت تحمست. الورقة بتدرس ضغط السياق بصرياً بنموذج مخصص، وبتعطي الفكرة أساساً بحثياً واضحاً. لكن اختبار الوثائق بهالنظام مختلف عن تجربتي على بضع لقطات شاشة؛ نجاح نسخها ما بعني إني أعدت إنتاج نتائج الورقة.
شو بيّنت التجارب الأولية؟
التجارب الأصلية كانت باستخدام Gemini 2.5 Flash عبر OpenRouter في أكتوبر 2025. هاي درجات النسخ اللي سجّلتها النسخة الأولى:
| حجم الخط والمقياس الرأسي | الدقة المذكورة وقتها |
|---|---|
| 8px، وY = 1.0 | 91.1% |
| 8px، وY = 0.9 | 87.8% |
| 8px، وY = 0.8 | 99.4% |
| 8px، وY = 0.7 | 55.0% |
| 8px، وY = 0.6 | 99.5% |
Y = 0.6 يعني نحتفظ بـ60% من ارتفاع النص بعد رسمه، ونترك العرض زي ما هو. الإعداد الواعد كان خط Verdana بحجم 8px مع هالضغط الرأسي.
هاي ملاحظات استكشافية، مش اختبار دقة موثّق. النسخة الأولى ما حدّدت معادلة التقييم، ولا نشرت كل نص أصلي مع ناتجه الكامل، ولا عرضت محاولات متكررة. بمثال المراجعة ذكرت خطأ واحداً: 500K صارت 500k. لو هذا فعلاً الخطأ الوحيد ضمن 1,287 حرفاً، دقة الأحرف بتكون حوالي 99.92%، مش 99.5%. النسبة ووصف الخطأ لازم يتراجعوا على الناتج الأصلي.
التفاوت بين الإعدادات بيستحق التوقف عنده: ليش فشل Y = 0.7 ونجح Y = 0.6؟ ممكن السبب إعادة تحجيم الصورة، أو تجهيزها داخل النموذج، أو اختلاف المخرجات بين المحاولات. التجربة ما فصلت هالعوامل، فما بنقدر نعتبر 0.6 إعداداً مثالياً للنصوص كلها.
قابلية القراءة مش حساب الفاتورة
الحساب الأصلي استعمل:
estimated tokens = width × height / 750
استخدمت هالتقدير كأنه قاعدة مشتركة بين Claude وGemini، من غير ما أثبت إنه مناسب لحساب Gemini. وكان في خطأ بالقسمة نفسها: 800 × 30 / 750 = 32، مش 40. وبكل الأحوال، ولا رقم منهما بيثبت الاستخدام اللي حسبته الخدمة فعلياً.
توثيق Google لحساب الرموز بوضح كيف تُحسب الصور، وبوفّر أدوات لعدّ رموز الطلب وقراءة معلومات الاستخدام بالاستجابة. ما بكفي نعرف أبعاد الصورة حتى نطبّق عليها تقدير نموذج ثاني. وإذا استخدمنا وسيطاً للطلب، لازم نسجّل المزوّد واسم النموذج الدقيق وإعداداته والاستخدام الفعلي مع كل محاولة.
المقارنة العادلة بتنطلق من نفس المهمة، مرة بنص عادي ومرة بصورة. بنحسب كلفة الطلب الكامل والناتج، وأي خطوة إضافية لنسخ النص، والمحاولات المعادة للوصول لنفس مستوى الجودة. خفض رموز المدخل بنسبة معينة ما بعني خفض الفاتورة كلها بنفس النسبة.
ممكن نلاقي توفيراً. وممكن الصورة تطلع أغلى. النتائج اللي فوق ما بتحسم.
كيف بنجهّز الصورة؟
بنرسم النص، وبنلتقط صورة للعنصر اللي بيحتويه، ثم بنقلّل ارتفاع الصورة. تصوير نافذة المتصفح كلها بيضيف مساحات فاضية ما إلها فائدة. وبنستخدم escape لتمثيل رموز HTML داخل النص، حتى يظهر الكود المكتوب كما هو بدل ما يفسّره المتصفح كجزء من الصفحة.
from html import escape
from io import BytesIO
from pathlib import Path
from PIL import Image
from playwright.async_api import async_playwright
async def render_compressed_text(text: str, output_path: str, y_scale=0.6):
if not 0 < y_scale <= 1:
raise ValueError("y_scale must be in (0, 1]")
html = f"""
<html><body style="margin:0;background:white">
<div id="text" style="width:800px;color:black;font-family:Verdana,sans-serif;
font-size:8px;line-height:8px;white-space:pre-wrap;
overflow-wrap:anywhere">{escape(text)}</div>
</body></html>
"""
async with async_playwright() as p:
browser = await p.chromium.launch()
try:
page = await browser.new_page(
viewport={"width": 800, "height": 600}, device_scale_factor=1
)
await page.set_content(html)
await page.evaluate("document.fonts.ready")
png = await page.locator("#text").screenshot()
finally:
await browser.close()
with Image.open(BytesIO(png)) as source:
height = max(1, round(source.height * y_scale))
compressed = source.resize((source.width, height), Image.Resampling.LANCZOS)
compressed.save(Path(output_path))
return compressed.size
الكود بجهّز الصورة، وما بيشغّل تجربة القراءة على النموذج. إذا بدك تستخدم Verdana تحديداً، لازم يكون الخط مثبتاً؛ غير هيك المتصفح رح يختار خطاً بديلاً. سجّل الخط المستخدم فعلياً والأبعاد النهائية للصورة مع كل محاولة.
شو ما زبط؟
شبكات البتات. تحويل الأحرف إلى بتات ورسمها كبكسلات ما أعطى قراءة مفيدة بهالمحاولات. كثافة التمثيل ما بتفيد إذا النموذج مش قادر يفكّه.
مورس. الملاحظة الأصلية عرضت تقديراً من 192 مقابل 321 token، ثم وصفت مورس بأنه بيستخدم «أكثر». الأرقام ما بتدعم هالوصف، فالمقارنة بتحتاج إعادة قياس لعدد الرموز ودقة فك الترميز.
فصل قنوات RGB. توزيع نصوص مختلفة على قنوات الألوان ما نجح بالمحاولات المذكورة. ما عندنا توفير مقاس ننسبه لهالطريقة.
العربية. إعدادات الرسم اللي جربناها ما سمحت باسترجاع النص العربي بثبات. اتصال الحروف وتشابه أشكالها ودور النقاط والتشكيل كلها تفاصيل بتتأثر بالتصغير. هاد بيخلينا نختبر العربية بإعدادات خاصة، من غير ما نستنتج إن الضغط البصري ما بنفع معها.
المقارنة القديمة ذكرت إن إعداد Claude 4.5 احتاج خطاً أكبر من Gemini 2.5. لكن من غير تحديد النماذج بدقة، واستخدام نفس نصوص الاختبار، وتكرار المحاولات وقياس الاستهلاك، ما بنقدر نحول هالملاحظة لادعاء إن «Gemini أفضل بأربع مرات». أصغر خط نجح النموذج بقراءته مش مقياساً شاملاً لقدرته البصرية.
التجربة اللي بتستاهل نعملها
نجهّز مجموعة اختبار ما استعملناها لاختيار الإعدادات: نثر، وأرقام، وكود، وجداول، ونصوص عربية. نثبّت إعدادات الرسم قبل الاختبار. ونحفظ كل نص وصورة وناتج وطلب واسم نموذج وسجل استخدام.
للنسخ، نقيس معدل خطأ الأحرف:
حيث عدد الاستبدالات، و المحذوفات، و الإضافات، و عدد أحرف النص الأصلي. ونوضح كيف تعاملنا مع الفراغات وحالة الأحرف. كمان نفحص التفاصيل الحساسة لحالها: ضياع إشارة سالب ممكن يكون أهم من فقرة كاملة من أخطاء الترقيم.
إذا كان هدفنا التلخيص أو الإجابة عن أسئلة، لازم نقيّم الأداء بهالمهمة نفسها. نسخ فقرة بنجاح ما بضمن فهم وثيقة مضغوطة أو الاستدلال عليها. وبنكرر المحاولات حتى ما تتحول نتيجة محظوظة لعنوان كبير.
بعدها نرسم جودة المهمة مقابل الكلفة الكاملة المقاسة. هاي المقارنة اللي كان لازم العنوان الأصلي يستند إلها.
ليش بعدها الفكرة بتعجبني؟
الرموز النصية واحدة من طرق تمثيل المعلومات. تحويل النص لصورة بيطرح موازنة مختلفة بين التفاصيل وحجم السياق. DeepSeek-OCR بيقدّم تجربة بحثية بهالاتجاه، والنماذج الجاهزة بتسمح نختبر جانباً صغيراً منه.
اتجاه بحب أستكشفه هو VET-RAG: استخدام نص ممثّل بصرياً ضمن استرجاع الوثائق وتوليد الإجابات. بنسترجع الصفحات المناسبة، وبنستخدم الصورة لما تساعد بالحفاظ على التنسيق أو تقليل كلفة المعالجة. لكن لسه بدنا نظاماً يختار الوثائق ذات الصلة، وضغطاً ما بيضيّع المعلومة اللي بنحتاجها للإجابة.
السؤال اللي لسه بشدّني: قديش من المعلومات المفيدة بقدر النموذج يسترجع مقابل الكلفة الحسابية؟ الصورة الصغيرة سبب وجيه للتجربة؛ حساب الاستخدام وتقرير الأخطاء هما اللي رح يخلونا نحكم على فائدتها.
مادة اختبار إضافية
هاي صورة لنص مكتوب بأسلوب أخبار الحوسبة الكمومية. هو مادة اختبار، مش خبراً موثّقاً:
الملاحظة الأصلية سجّلت 1,442 حرفاً ودقة نسخ 99.6%، وذكرت فروقاً بالترقيم وبين «for» و«to». التحقق من النسبة بيحتاج النص الأصلي والناتج كاملين، مثل المثال الأول. وتقدير التوفير السابق غير معتمد لنفس الخلل بحساب الرموز.
مقالات ذات صلة
لما صار التفكير كهرباء — الجزء الأول: السؤال
قبل تاريخ الكمبيوتر في حلم أقدم: أن نكتب العقل نفسه. ثلاثة اصطدامات بين ذلك الحلم والآلة الحديثة — من سوسير وword2vec، إلى فيتغنشتاين والهلوسة، وهيوم والتعميم.
استقلالية الـ Agent — الجزء التاني: أبعد من الخوارزميات
كيف نترك للـ agents مجالاً أوسع لتطوير الشروحات التفاعلية، وجودتها ما بتنحسم بصحة الكود وحدها؟ عن تنظيم البحث، وتراكم الخبرة، والفرق بين تقييم التصميم وقياس التعلّم.
برومبت الحب تبع ديفيش الأخطبوط
ديفيش بيدير كرفان لحم أخطبوط مشبوه داخل المحاكاة. عميل متخفّي، بثمان مجسّات وثمان مصالح جانبية. قصة عن الحب والذكاء الاصطناعي والضرايب.