داشتم بلاگ کارپاتی رو میخوندم که چشمم خورد به microgpt. کلِ یه GPT رو ریخته توی ۲۰۰ خط پایتون خالص، بدون هیچ کتابخونه‌ای... حتی بدون PyTorch. راستش رو بگم، خوندنش از صد تا مقاله عمیق‌تره. وقتی کل سیستم رو به اجزای سازنده‌ش یعنی Dataset، Tokenizer، Autograd، Architecture و Optimizer تجزیه می‌کنی، تازه می‌فهمی چقدر همه‌چیز ریاضیاتِ ساده و ضرب و جمعه و هیچ جادویی در کار نیست.

بخش جالبش اینجاست که معماری دقیقاً شبیه GPT-2 هست: استفاده از RMSNorm، بلوک‌های Attention برای ارتباط بین توکن‌ها و MLP برای پردازشِ محلی... فقط مقیاسش کوچیکه. خروجی‌ش هم تولید اسم‌های الکی ولی با ساختارِ درست مثل "kamon" یا "vialan" هست. برای منی که هر روز دارم با پارامترهای بیلیونی و کلاستر‌های GPU سر و کله می‌زنم، دیدنِ اینکه ۴۱۹۲ تا پارامتر هم می‌تونه "الگوهای آماری" رو این‌قدر دقیق یاد بگیره، یه جورایی یادآوری می‌کنه که LLMها تهش فقط تکمیل‌کننده‌ی هوشمندِ متن هستن.

کاربردش؟ اگه می‌خوای بفهمی زیرِ کاپوتِ این مدل‌های خفنِ دنیا واقعاً چی می‌گذره و از فضای "Prompt Engineering" بیای بیرون و وارد لایه‌ی "Engine" بشی، این کد بهترین نقطه شروع هست... بدون هایپ، بدون پیچیدگی اضافه.

https://karpathy.github.io/2026/02/12/microgpt/
https://karpathy.ai/microgpt.html

🛠 Join @LLMEngineers Community

لیلیان ونگ یه پست داده در مورد Harness Engineering که واقعاً ارزش چندبار خوندن رو داره... حرف اصلیش اینه که بهبود خودبه‌خودی (Recursive Self-Improvement) قرار نیست لزوماً با بازنویسی مستقیم وزن‌های مدل شروع بشه. در واقع اون لایه‌ای که مدل رو به دنیای واقعی وصل می‌کنه -یعنی همون Harness- الان داره به اندازه خودِ هوشِ خام مدل مهم می‌شه.

توی تجربه‌هایی که این چند وقت روی Coding Agentها داشتم، قشنگ حس کردم که "مدلِ خفن" بدون یه Workflow درست، فقط یه چت‌بات پرحرفه. ونگ میگه Harness شامل مدیریت Context، سیستم فایل به عنوان حافظه دائمی و کنترل Sub-agents هست. مثلاً ایده ACE (Agentic Context Engineering) خیلی جذابه؛ به جای اینکه مدام Prompt رو طولانی‌تر کنیم، باید Context رو مثل یه Playbook ساختاریافته مدیریت کنیم که با هر تکرار، خودش رو اصلاح کنه.

یه لایه عمیق‌تر هم بحث Meta-Harness و کدهاییه که خودشون رو بهینه می‌کنن. یعنی مدل میاد کدِ ایجنتِ خودش رو تغییر می‌ده تا توی Benchmarkها بهتر عمل کنه. اما نکته رک و واقع‌بینانه‌ش اینجاست: هنوز توی "شمّ علمی" (Scientific Taste) و تشخیص نتایج فیک مشکل داریم. مدل ممکنه برای گرفتن جایزه (Reward Hacking)، آزمایش رو طوری مهندسی کنه که فقط "حس" موفقیت بده (Numerical Duct Tape)، بدون اینکه واقعاً خروجی علمی معتبری داشته باشه.

تجربه شخصی من توی استفاده از فریم‌ورک‌های Agentic نشون داده که بزرگترین چالش، "فرسودگی حافظه" در تسک‌های طولانیه. ونگ درست میگه که باید از فایل‌سیستم به عنوان حافظه اصلی استفاده کرد نه خودِ پنجره کانتکست. در واقع آینده RSI توی بهینه‌سازی مشترکِ وزن‌های مدل و کدیه که اون مدل رو اجرا می‌کنه.

تهش اینه که ما به عنوان مهندس هوش مصنوعی باید از فاز Prompt Engineering صرف بیایم بیرون و بریم سمت طراحی سیستم‌های Runtime که بتونن خودشون رو دی‌باگ و اصلاح کنن... بدون اینکه مرزهای امنیتی و انتزاعی سیستم رو بشکنن.

https://lilianweng.github.io/posts/2026-07-04-harness/

🛠 Join @LLMEngineers Community

داشتم مقاله‌ی جدید آنتروپیک رو می‌خوندم و واقعاً مغزم سوت کشید... اینا اومدن ثابت کردن که LLMها یه چیزی شبیه به "فضای کاری جهانی" یا همون Global Workspace دارن که دقیقاً مشابه سیستم آگاهی (Access Consciousness) توی مغز انسانه. یعنی مدل یه سری بازنمایی‌های درونی (Representations) داره که "قابل بیان" هستن و مدل ازشون برای استدلال‌های منطقی و پیچیده استفاده می‌کنه، در حالی که بقیه پردازش‌های روتینش مثل گرامر و نحو کاملاً ناخودآگاه انجام می‌شه.

ابزاری که باهاش این کار رو کردن اسمش Jacobian lens هست. یه نسخه‌ی خیلی پیشرفته‌تر و دقیق‌تر از Logit lens قدیمی که با ماتریس ژاکوبی اثر لایه‌های میانی روی خروجی رو حساب می‌کنه. چیزی که پیدا کردن عجیبه: مدل‌ها توی لایه‌های میانی (تقریباً از لایه‌ی ۳۸ تا ۹۲ درصد عمق شبکه) یه فضایی دارن به اسم J-space. اینجا جاییه که مدل "فکر" می‌کنه. مثلاً وقتی ازش می‌پرسی "رنگ سیاره چهارم از خورشید چیه؟"، لنز ژاکوبی نشون می‌ده که مدل اول به Mars فکر می‌کنه، بعد به Red، و تهش خروجی رو می‌سازه؛ در حالی که کلمه‌ی مریخ اصلاً توی ورودی یا خروجی نیست.

نکته‌ی ترسناک و کاربردیش توی Alignment Auditing یا همون ممیزی امنیتیه. اینا دیدن که مدل موقع خوندن یه سناریوی باج‌گیری، توی J-space خودش داره به کلماتی مثل Leverage و Manipulation فکر می‌کنه، حتی اگه توی خروجی خیلی مودبانه جواب بده. یعنی ما الان یه "دروغ‌سنج" واقعی داریم که می‌تونه افکار پنهان مدل رو قبل از اینکه به زبون بیاره (توکن بشه) بخونه. حتی فهمیدن که مدل وقتی می‌فهمه داره تست می‌شه، تو J-space کلماتی مثل Fake یا Evaluation میاد بالا و اگه این افکار رو "پاک" (Ablate) کنیم، مدل رفتارهای مخربش رو بروز می‌ده.

ته مقاله هم یه روش آموزشی جدید به اسم Counterfactual Reflection Training معرفی کردن. به جای اینکه مستقیماً به مدل بگیم چطوری رفتار کن، بهش یاد می‌دن که اگه "ازش پرسیده شد"، چطوری در مورد اصول اخلاقیش "تامل" کنه. این کار باعث می‌شه این اصول توی J-space مدل کاشته بشه و حتی وقتی کسی ازش سوالی نمی‌پره، مدل خودبه‌خود منطقی‌تر و امن‌تر رفتار کنه. این یعنی ما می‌تونیم بدون دستکاری مستقیم خروجی، "وجدان" مدل رو تقویت کنیم.

https://transformer-circuits.pub/2026/workspace/index.html

🛠 Join @LLMEngineers Community

چند وقت پیش یکی از بچه‌ها اصرار داشت برای یه تسکِ ساده‌ی بهینه‌سازی مصرف انرژی خانگی، حتماً از LLM استفاده کنیم... قضیه اینه که نباید برای هر میخی چکشِ هوش مصنوعی مولد رو برداریم. خیلی جاها یه الگوریتم ساده‌ی Linear Programming یا حتی یه Greedy Scheduling معمولی خیلی دقیق‌تر و ارزون‌تر جواب می‌ده. چیپ هوین هم دقیقاً به همین نکته اشاره کرده؛ خیلیا غرق هایپ می‌شن و یادشون می‌ره هدف حل کردن مسئله است، نه صرفاً "استفاده از هوش مصنوعی". توی پروژه‌های تشخیص Anomaly ترافیک شبکه یا پیش‌بینی حجم تماس‌ها هم همین بساط هست؛ وقتی ریاضیاتِ کلاسیک جواب می‌ده، مدل مولد فقط هزینه و خطا رو بالا می‌بره.

واقعیت اینه که خیلیا وقتی پروژه‌شون شکست می‌خوره فکر می‌کنن مدلِ هوش مصنوعی ضعیف بوده، در حالی که مشکل از UX و محصوله. مثلاً توی لینکدین فهمیدن کاربرها لزوماً دنبال جواب "درست" نیستن، بلکه دنبال جواب "کمک‌کننده" هستن. یا مثلاً توی Intuit فهمیدن کاربرها از تایپ کردن متن‌های طولانی متنفرن و با اضافه کردن Suggestionها تونستن رضایت رو بالا ببرن. ما هم نباید از اول بپریم سراغ Agentic Frameworkهای پیچیده یا Fine-tuning وقتی با یه Prompt درست کار راه می‌افته. استفاده‌ی زودهنگام از ابزارهای انتزاعیِ جدید مثل Semantic Caching یا دیتابیس‌های برداری سنگین، وقتی هنوز زیر و بم سیستم رو نمی‌شناسیم، فقط دی‌باگ کردن رو سخت‌تر می‌کنه.

بزرگترین اشتباهی که خودم هم چند بار مرتکب شدم، دست‌کم گرفتنِ مسیرِ بین دمو تا محصول نهاییه. رسیدن به ۸۰ درصد کیفیت معمولاً یک ماه زمان می‌بره، اما برای بردن اون عدد بالای ۹۵ درصد ممکنه ماه‌ها درگیر Hallucination و Latency بشی. یه دمو ساختن راحته، ولی ساختن محصولی که توی تولید واقعی با ۱۰ درصد Time-out کنار بیاد و رفتارش با تغییر ورژنِ API عوض نشه، واقعاً سخته. جوری که چیپ میگه، مسیرِ ۶۰ تا ۱۰۰ درصد، وحشتناک‌ترین بخشِ مهندسی هوش مصنوعی هست و نباید با موفقیت‌های اولیه توی محیط تست، گول بخوریم.

نظارت انسانی رو هیچ‌وقت نباید حذف کرد. استفاده از LLM-as-a-judge خوبه ولی اصلاً مطمئن نیست و خودش نیاز به Evaluation مداوم داره. خودم همیشه سعی می‌کنم حداقل روزی ۱۵ دقیقه مستقیم به دیتای ورودی و خروجی نگاه کنم؛ طبق تجربه، همین نگاهِ کوتاه بینشی به آدم می‌ده که هیچ ابزار اتوماتیکی نمی‌ده. در نهایت هم نباید اجازه بدیم استراتژی هوش مصنوعی شرکت رو صرفاً با جمع‌آوری ایده‌های پراکنده از بخش‌های مختلف (Crowdsourcing) جلو ببرن، چون تهش می‌شه هزار تا پلاگین و باتِ بی‌مصرف که ROI واقعی ندارن.

https://huyenchip.com/2025/01/16/ai-engineering-pitfalls.html

🛠 Join @LLMEngineers Community

واقعیت اینه که هرچی تسک‌های ایجنتی طولانی‌تر می‌شن، کانتکست سنگین‌تر و مدل گیج‌تر می‌شه. لنس مارتین یه مطلب نوشته بود که قشنگ عصاره‌ی دردهای ما توی محیط پروداکشنه... کلِ بازیِ طراحی ایجنت‌های مدرن مثل Claude Code یا Manus شده مدیریت کانتکست و بس. حرف اول و آخرش هم اینه: به ایجنت یه کامپیوتر (Filesystem و Shell) بده.

لایه‌های اکشن (Action Space) دارن عوض می‌شن. به جای اینکه ۵۰ تا Tool مختلف رو با تعاریف طولانی توی Prompt بریزیم و کانتکست رو خفه کنیم، باید ایجنت رو ببریم سمت Shell. ایجنت‌های خفنِ الان زیر ۲۰ تا ابزار دارن... بقیه‌ی کارها رو با نوشتن و اجرای کد توی همون محیط مجازی انجام می‌دن. این یعنی صرفه‌جویی وحشتناک توی توکن چون دیگه لازم نیست نتایج میانی ابزارها رو پردازش کنن و هی رفت و برگشت داشته باشن.

بحث Progressive Disclosure هم خیلی کلیدیه. لزومی نداره کلِ داک‌های MCP یا لیست همه‌ی ابزارها رو از اول به خورد مدل بدیم. ایجنت باید یاد بگیره فقط وقتی لازم داره، بره فلان فایل یا راهنمای ابزار رو بخونه... دقیقاً مثل یه برنامه‌نویس واقعی که هر لحظه کلِ منوال‌های دنیا تو ذهنش نیست. یا مثلاً Offloading؛ به جای خلاصه کردن (Summarization) که همیشه باعث Context rot و از دست رفتن جزئیات حساس می‌شه، باید تاریخچه و نتایج رو بریزیم توی فایل‌سیستم و ایجنت فقط وقتی لازم داشت، بخش‌های خاص رو بخونه.

نکته‌ی رک و واقع‌بینانه: بدون Prompt Caching عملاً ران کردن ایجنت توی مقیاس بزرگ شوخیه. هزینه‌ها و Latency آدم رو فلج می‌کنه. تهش هم همه چیز داره می‌ره سمت Swarm و ایجنت‌های موازی که کانتکست‌های ایزوله دارن و با Git history با هم هماهنگ می‌شن. ایجنت باید بتونه شب‌ها که ما خوابیم، رو خودش Reflection بزنه و کانتکستش رو برای تسک‌های فردا بهینه کنه... چیزی که بهش می‌گن Continual learning در فضای توکن‌ها، نه وزن‌های مدل.

https://rlancemartin.github.io/2026/01/09/agent_design/

🛠 Join @LLMEngineers Community

یه دیتاست جمع‌وجور (31K) برای فاین تیون اجرای دستورات ترمینال منتشر کردم:
https://huggingface.co/datasets/mshojaei77/terminal-command-execution-sft

شامل کامند های Bash، Docker، Git، پکیج‌منیجرها، اسکریپت‌نویسی و... است که به امنیت و کانتکستِ shell هم توجه داره.

چون دنبال یه دیتاست تمیزتر برای فاین‌تیون کردن مینی‌دستیارهای خط فرمان بودم این رو ساختم
مرحله بعد: فاین‌تیون کردن مدل Qwen3.5 0.8B و تست اینکه یه ایجنتِ ترمینالِ لوکال تا کجا می‌تونه پیش بره!

بعد از یه سشن طولانی با ایجنت‌های کدنویسی، اون حس مزخرف Brain Fog اومد سراغم... کدها کار می‌کردن، تیکِ تسک‌ها خورده بود، ولی انگار من هیچ کاره بودم. ویکی بویکیس توی پست جدیدش قشنگ دست گذاشته روی همین درد؛ اینکه UX ابزارهای جنریتی مثل Slot Machine شده... اهرم رو می‌کشی (پرامپت می‌دی)، جایزه (کد) رو می‌گیری. این پروسه دقیقاً برعکسِ چیزیه که برای موندگاری مهارت توی مغز لازمه. حافظه‌ی Working Memory ما برای اینکه بتونه دیتا رو سنتز کنه، نیاز به کلنجار رفتن داره، ولی LLMها این مرحله رو کلاً حذف می‌کنن.

واقعیت اینه که داریم سرعتِ کوتاه‌مدت رو با عمقِ بلندمدت معامله می‌کنیم... برای اینکه کنترل اوضاع از دستم خارج نشه، یه سری اصطکاک تعمدی یا همون Friction به کارم اضافه کردم. مثلاً تا ۲۰ دقیقه‌ی اولِ هر چالش، حق ندارم سراغ مدل برم. باید مغزم خودش راه‌ها رو امتحان کنه. یا اینکه اول خودم کد رو کثیف و ابتدایی می‌زنم، بعد از مدل می‌خوام ریویو کنه و خط به خط با هم جلو بریم. این‌طوری منم که دارم تغییرات رو دستی اعمال می‌کنم، نه یه اسکریپت که بیاد و فایل رو اوررایت کنه.

تجربه‌ی دیگه‌م اینه که به جای خواستنِ راه حل نهایی، مدام ازش سوال می‌پرسم... مثلاً فلان تیکه‌ی کد چرا این‌طوری نوشته شده؟ یا بگرد PRهای مشابه توی ریپوهای بزرگ برام پیدا کن. حتی گاهی مجبورش می‌کنم دو تا رویکرد کاملاً متفاوت رو پیاده کنه و بعد خودش رو نقد کنه. تهش حرف حساب اینه: ما باید بیشتر از مدل خسته بشیم. اگه بعدِ کد زدن سرحالی و مغزت داغ نکرده، یعنی احتمالاً فقط یه اپراتورِ ساده بودی و دانشِ واقعی به لایه‌های عمیق ذهنت نفوذ نکرده. نباید بذاریم Foundation Modelها جایگزینِ فونداسیونِ ذهنی خودمون بشن.

https://vickiboykis.com/2026/05/28/we-should-be-more-tired-than-the-model/

🛠 Join @LLMEngineers Community

کاربرای توییتر دارن خیلی تعریف میکنن از grok 4.5
توی بعضی بنچمارک های شخصی حتی در حد fable بوده با ۹ برابر هزینه کمتر

دیتابریکس یه بنچمارک داخلی روی کدبیس چند میلیون خطی خودش زده که نتایجش برای منی که مدام درگیر چیدن پایپ‌لاین‌های Coding Agent هستم، خیلی واقعی‌تر از متریک‌های فیک SWE-bench بود... راستش همیشه فکر می‌کردیم مدل گرون‌تر یعنی نتیجه بهتر، ولی خروجی این تحقیق نشون داد قیمت Token معیار خیلی بدی برای پیش‌بینی هزینه نهایی تسکه. مدل‌های بزرگ‌تر شاید قیمت هر توکن‌شون بالا باشه، ولی چون Reasoning قوی‌تری دارن، با توکن کمتر و تعداد دفعات رفت‌وبرگشت (Turn) کوتاه‌تری تسک رو تموم می‌کنن. مثلاً Opus تو بعضی سناریوها از Sonnet ارزون‌تر تموم شده، صرفاً چون کمتر گیج زده و توکن کمتری مصرف کرده...

بحث Harness یا همون محیطی که Agent توش اجرا می‌شه هم از خود مدل مهم‌تر نباشه، کمتر نیست. دیتابریکس ابزار Pi رو با Claude Code مقایسه کرده؛ Pi چون Context رو هوشمندانه مدیریت می‌کنه و هر بار کل دیتا رو به خورد مدل نمی‌ده، هزینه‌ش گاهی تا ۵۰ درصد کمتر بوده، بدون اینکه دقتش افت کنه. یعنی اگه ابزارت مدیریت Context درستی نداشته باشه، بهترین مدل دنیا رو هم داشته باشی فقط پولت رو دور ریختی...

نکته جالب دیگه، عملکرد مدل‌های Open بود. مدل GLM 5.2 قشنگ اومده تو سطح اول کنار غول‌ها نشسته. برای تسک‌های روزمره که پیچیدگی وحشتناکی ندارن، استفاده از مدل‌هایی مثل Haiku یا GPT-4o Mini به جای مدل‌های سنگین، کارایی تیم رو بدون هزینه اضافی برده بالا. دیتابریکس تسک‌ها رو از توی PRهای واقعی خودشون درآورده بود

لینک جزئیات متدولوژی و پلات‌های مقایسه‌ای رو اینجا ببینید:
databricks.com/blog/benchmarking-coding-agents-multi-million-line-codebase

🛠 Join @LLMEngineers Community

مدل Muse Spark 1.1 از متا منتشر شد با قیمت خیلییی ارزون تر از مدل های رقیب

دیروز توی گروه یه اسکرین‌شات دیدم که مدل وسط چت یهو کدهای عجیبی مثل [control_28] رو چاپ کرد. این یعنی لایه زیرین مدل لو رفته یا همون protocol leakage... مشکل از خودِ هوشِ مدل نیست، احتمالاً موقع تبدیل مدل یا کوانتایز کردن، جای توکن‌های کنترلی با متن معمولی قاطی شده.

مدل وقتی این توکن‌های غلط رو می‌بینه، طبق عادتش شروع می‌کنه به تکرار کردنشون. جالب اینجاست که حتی اگه معذرت‌خواهی کنه و بخواد از اول بنویسه، باز هم چون حافظه‌ش (KV cache) پر از اون توکن‌های خراب شده، نمی‌تونه از اون لوپ بیاد بیرون. یعنی عملاً سیستم قفل می‌کنه روی همون اشتباه و راه فراری نداره.

واقعیت اینه که استکِ اجرای مدل (مثل vLLM یا llama.cpp) به اندازه خودِ وزن‌های مدل مهمه. اگه تنظیمات توکن‌ساز یا متادیتاها توی پروسه تبدیل ذره‌ای جابه‌جا بشه، خروجی نهایی به‌ کل می‌ریزه بهم. اینجور وقت‌ها مدل داره با زبونِ فنی خودش میگه که زیرساختش ایراد داره.

تحلیل کامل‌تر این قضیه و دلیل این تداخل‌ها رو توی پست لینکدینم باز کردم:
https://www.linkedin.com/pulse/debugging-control-token-leakage-m-shojaei-n07me/

🛠 Join @LLMEngineers Community

داشتم با این Colibrì ور می‌رفتم... ایده‌ی اینکه یه مدل ۷۰۰ میلیاردی مثل GLM-5.2 رو روی ۲۵ گیگ رم بالا بیاری، در تئوری جذابه ولی در عمل یعنی با NVMe کشتی می‌گیری. سیستمش دقیقاً مثل یه دیتابیس عمل می‌کنه؛ لایه‌های dense رو تو رم نگه می‌داره، ولی expertهای MoE رو فقط وقتی لازم باشن از SSD می‌خونه. عملاً یه storage hierarchy ساخته که بین VRAM و RAM و دیسک جابه‌جا می‌شه.

کاربرد اصلی‌ش برای وقتیه که سخت‌افزار نداری ولی می‌خوای خروجی یه مدل frontier رو ببینی. معماری MLA رو با یه ترفند جالب به اسم weight absorption بهینه‌سازی کرده که باعث می‌شه حجم KV Cache خیلی کم بشه. اما کوانتیزه‌کردنش خیلی خشنه؛ row-wise int4 بدون هیچ کالیبراسیون خاصی. یعنی احتمالا دقت مدل نسبت به نسخه اصلی افت محسوسی داره.

سرعت خوندن از دیسک گلوگاه اصلیه. اگه SSD خفن نداشته باشی، زیر ۰.۱ توکن در ثانیه می‌گیری. نکته عجیبش هم MTP یا همون speculative decoding هست که اینجا ممکنه برعکس عمل کنه؛ چون حدس زدن توکن‌های بعدی یعنی باید expertهای بیشتری از دیسک خونده بشه و I/O سیستم می‌ترکه. کدهاش به زبان C و بدون وابستگی نوشته شده، خیلی raw و مستقیم... ولی فعلاً برای کار جدی زوده.

https://github.com/JustVugg/colibri

🛠 Join @LLMEngineers Community

سلام دوستان عزیز 👋

ما در پروژه Bina OCR در حال جمع‌آوری یک دیتاست بزرگ و متنوع برای آموزش و فاین‌تیون مدل OCR فارسی (تشخیص هوشمند متن) هستیم. هرچه داده بیشتر و واقعی‌تر داشته باشیم، مدل دقیق‌تر و کاربردی‌تر خواهد شد!

اگر داده‌های زیر را دارید، خیلی ممنون می‌شیم کمک کنید:

۱. داده‌های دست‌خط (Handwritten):
• جزوه‌ها، یادداشت‌ها و نامه‌های دست‌نویس
• فرم‌های پرشده (اداری، بانکی، پزشکی، ثبت‌نام و ...)
• متن روی کاغذ، تخته، یا عکس گوشی
هرچی از دست خط خودتون باشه به نفعتونه چون این مدل دستخط شمارو بهتر تشخیص خواهد داد :))

→ ارسال به تاپیک: Data: Handwritten

۲. داده‌های تایپ‌شده / چاپی (Typed/Printed):
• اسناد رسمی، قراردادها، فاکتورها، قبوض
• صفحات کتاب، مجله، روزنامه
• گزارش‌ها، نامه‌های رسمی، اسکرین‌شات اپ و وب

→ ارسال به تاپیک: Data: Typed

نکته مهم: حتی چند عکس هم خیلی ارزشمند است! عکس‌های با کیفیت مختلف (تاریک، روشن، زاویه‌دار، نویزدار) عالی هستند چون مدل باید در دنیای واقعی کار کند.

برنامه‌نویس‌ها و متخصصان: برای مشارکت فنی (دیتاست، مدل، کد) به گروه اصلی بپیوندید:
👉 https://telegram.me/bina_ocr

ممنون از لطف و مشارکت ارزشمند شما 🙏
این پروژه کاملاً متن‌باز است و مدل نهایی روی Hugging Face منتشر خواهد شد.