تصور کنید بعد از یک پیاده‌روی طولانی در جنگل، تمام پرندگانی که احتمالاً دیده‌اید در قالب یک یادداشت زیبا و تصویری آماده باشد، بدون اینکه حتی یک کلمه نوشته باشید. Birds.Quest که در ۱۲ اکتبر ۲۰۲۶ معرفی شد، یک پروژه متن‌باز است که دقیقاً همین کار را می‌کند: تبدیل مختصات خام GPS به ژورنال‌های توصیفی طبیعت. این سیستم از ترکیبی از مدل‌سازی زمین‌فضایی (Geospatial Modeling) و مدل‌های زبانی بزرگ استفاده می‌کند تا پیش‌بینی کند یک کوهنورد یا پیاده‌رو در یک مسیر خاص احتمالاً با کدام گونه‌های پرندگان مواجه شده است.
برای بسیاری از علاقه‌مندان به طبیعت، ثبت مشاهدات در اپلیکیشن‌هایی مثل eBird می‌تواند شبیه به تکالیف مدرسه باشد و در نهایت لذت حضور در فضای باز را کاهش دهد. توسعه‌دهنده این پروژه که خودش از دوربین‌های Bushnell ENGAGE 8x42 برای پرنده‌نگری استفاده می‌کند، متوجه شد که ورود دستی داده‌ها دقیقاً نقطه مقابل لذت بردن از «لمس طبیعت» (Touching Grass) است. این رویکرد یادآور تلاش‌های مشابه در پروژه WanderLog است که تبدیل یادداشت‌های صوتی به دفترچه طبیعت‌گردی را با معماری محلی ممکن ساخت. این پروژه با تغییر دیدگاه به وبلاگ — به جای اینکه آن را یک ادعای واقعی از مشاهده پرندگان بداند، آن را به عنوان منبعی برای الهام‌بخش شدن پیاده‌روی‌های آینده تعریف می‌کند — این اصطکاک را حل می‌کند. در واقع، بار مستندسازی از دوش انسان به یک کارگر خودکار هوش مصنوعی منتقل شده است.
خط لوله فنی
این سامانه با اپلیکیشن Traccar Client شروع می‌شود که داده‌های موقعیت را از طریق پروتکل HTTPS به یک سرور Traccar شخصی (Self-hosted) ارسال می‌کند. سپس یک پردازشگر ساعتی (Hourly Worker)، این داده‌ها را در یک خط لوله چهار مرحله‌ای تحلیل می‌کند:
- کشف (Discovery): پردازشگر با استفاده از یک کاربر دیتابیس با دسترسی فقط-خواندنی (Read-only)، جدول
tc_positionsرا بررسی می‌کند. سیستم سفرهای تمام‌شده را بر اساس شکاف‌های حرکتی یا توقف‌های ۱۰ دقیقه‌ای یا بیشتر شناسایی می‌کند. سفرهایی که کمتر از ۱۰ دقیقه باشند نادیده گرفته می‌شوند و سفرهایی که هنوز در جریان هستند هرگز پردازش نمی‌شوند. - نمونه‌برداری (Sampling): برای بهینه‌سازی پردازش، داده‌های خام کاهش می‌یابند (Thinning). در یک اجرای آزمایشی در دنیای واقعی روی مسیری به طول ۱۰.۴ کیلومتر، ۸۲ موقعیت ثبت شده به ۲۴ نقطه مسیر کاهش یافت که به طور متوسط هر ۳۰۰ متر یک نقطه را شامل می‌شد.
- پیش‌بینی (Prediction): مدل BirdNET GeoModel — که به صورت یک مدل ONNX FP16 از طریق
onnxruntime-nodeروی CPU اجرا می‌شود — طول و عرض جغرافیایی و هفته خاصی از سال را دریافت کرده و احتمال حضور گونه‌های مختلف را برمی‌گرداند. سیستم مسیر را نمونه‌برداری کرده و حداکثر احتمال (Maximum Probability) برای هر گونه را در نظر می‌گیرد تا تعیین کند آیا آن پرنده «در هر جای مسیر قابل مشاهده بوده است یا خیر». این تمرکز بر شناسایی گونه‌ها در محیط‌های طبیعی، مشابه رویکرد مدل BioCLIP در شناسایی گیاهان و جانوران به صورت کاملاً آفلاین است. - غنی‌سازی (Enrichment): سیستم برای ۲۰ گونه‌ای که بیشترین احتمال حضور را دارند، خلاصه‌ها و عکس‌های دارای مجوز را از API REST ویکی‌پدیا دریافت می‌کند. تصاویری که اطلاعات مجوز (License) ندارند نادیده گرفته می‌شوند و اعتبار عکس‌ها به صورت محلی ذخیره می‌گردند.
به نقل از گزارش dev.to، گنجاندن متغیر «هفته» در این مدل حیاتی است. سیستم تاریخ را به یک سال ۴۸ هفته‌ای نگاشت می‌کند (مثلاً ۱۰ و ۱۱ اکتبر هفته ۳۸ است). مسیری که در ماه ژوئن پیموده می‌شود، لیست گونه‌های متفاوتی نسبت به همان مسیر در اواسط اکتبر خواهد داشت؛ زیرا این مدل مهاجران پاییزی مانند «سار قهوه‌ای» (Brown Shrike) را در محاسبات خود لحاظ می‌کند.
نمونه پیش‌بینی در دنیای واقعی
در یک اجرای آزمایشی ۱۰.۴ کیلومتری در اوا لوڈ اکتبر، مدل GeoModel با اعمال آستانه (Threshold) ۰.۱۵ و سقف ۲۰ گونه برتر، احتمالات زیر را ثبت کرد:
- فاخته خالدار (Spilopelia chinensis): ۹۹.۷٪
- خیاط کوچک (Orthotomus sutorius): ۹۹.۴٪
- دروغ‌گوی سیاه (Dicrurus macrocercus): ۹۹.۳٪
- بلبل قرمز (Pycnonotus cafer): ۹۹.۳٪
- کینگ‌فیشر گلو سفید (Halcyon smyrnensis): ۹۹.۰٪
- کینگ‌فیشر معمولی (Alcedo atthis): ۹۹.۰٪
- کورمورانت کوچک (Microcarbo niger): ۹۸.۸٪
- حواصیل سفید کوچک (Egretta garzetta): ۹۸.۸٪
- کلاغ خانگی (Corvus splendens): ۹۸.۷٪
- ** پرستوی سیاه** (Hirundo rustica): ۹۸.۷٪
- سار منقار-روبن شرقی (Copsychus saularis): ۹۸.۶٪
- حواصیل برک هندی (Ardeola grayii): ۹۸.۵٪
- مینا معمولی (Acridotheres tristis): ۹۸.۱٪
- حواصیل گاو شرقی (Ardea coromanda): ۹۸.۱٪
- جای‌جای قرمز (Dendrocitta vagabunda): ۹۸.۰٪
- سار سیاه (Milvus migrans): ۹۸.۰٪
- بادپهلوی نخل آسیایی (Cypsiurus balasiensis): ۹۷.۹٪
- کبوتر صخره‌ای (Columba livia): ۹۷.۷٪
- ایورا معمولی (Aegithina tiphia): ۹۷.۶٪
- سار قهوه‌ای (Lanius cristatus): ۹۷.۳٪
حضور کینگ‌فیشرها، حواصیل‌ها و هرون‌ها به‌درستی نشان‌دهنده نزدیکی مسیر به منابع آبی بود و حضور پرستوی سیاه و سار قهوه‌ای، الگوهای مورد انتظار مهاجرت پاییزی را تأیید کرد.
معماری اولویت‌دار حریم خصوصی
یک شرط سخت‌گیرانه در Birds.Quest این است که داده‌های مکانی هرگز سرور محلی را ترک نکنند. توسعه‌دهنده فیلترهای دقیقی طراحی کرده تا هیچ مختصاتی یا نام مکان‌های خاص به پرامپت مدل زبانی (LLM) یا وبلاگ عمومی نرسد.
مکانیزم‌های حریم خصوصی:
- گرسنگی پرامپت (Prompt Starvation): مدل زبانی بزرگ فقط نام گونه‌ها، حداکثر سه جمله از ویکی‌پدیا برای هر پرنده و فصل سال (مثلاً «اواسط اکتبر، پاییز») را دریافت می‌کند.
- فیلتر ورودی: جملاتی از ویکی‌پدیا که به کشورهای خاص یا شهرهای مشخص اشاره می‌کنند، قبل از ارسال به پرامپت حذف می‌شوند.
- اعتبارسنجی خروجی: هر پاسخی از سوی LLM که حاوی مختصات، نام‌های نقشه یا URL باشد، به‌طور کامل دور ریخته می‌شود.
- کنترل در سطح کد: تصاویر و لینک‌ها توسط کد برنامه اضافه می‌شوند، نه توسط مدل؛ این کار از توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی را می‌گوید که وجود ندارد — و نشت لینک‌های مبتنی بر مکان جلوگیری می‌کند.
- سیستم جایگزین (Fallback): اگر مدل زبانی دچار Timeout شود یا بررسی‌های امنیتی را رد نکند، یک قالب ساده (Plain Template) پست را می‌نویسد تا هیچ ورودی‌ای از دست نرود.
نقش Gemma 4
این پروژه از Gemma 4 در دو ظرفیت مختلف برای ایجاد تعادل بین هزینه و کیفیت استفاده می‌کند. در طول توسعه محلی، توسعه‌دهنده از مدل Gemma 4 E2B از طریق Ollama برای تکرارهای سریع و آفلاین استفاده می‌کند. تولید یک پست برای ۲۰ گونه در محیط محلی حدود سه دقیقه زمان می‌برد. در محیط عملیاتی (Production)، سیستم برای دستیابی به نثر و کیفیت نوشتاری برتر، مدل Gemma 4 31B را از طریق DigitalOcean Serverless Inference فراخوانی می‌کند.
از آنجا که Gemma 4 یک مدل استدلالی (Reasoning Model) است — مدلی که قبل از پاسخ دادن، فرآیند تفکر را طی می‌کند — توسعه‌دهنده با مشکلی مواجه شد که در آن محدودیت‌های کوچک توکن منجر به تولید محتوای خالی و نمایش تنها فیلد استدلال (Reasoning field) می‌شد. برای حل این مشکل، کلاینت اکنون مقدار reasoning_effort: "none" را ارسال می‌کند تا اطمینان حاصل شود که پاسخ مستقیماً در فیلد محتوا قرار می‌گیرد. کلاینت عملیاتی از یک نقطه اتصال سازگار با OpenAI (https://inference.do-ai.run/v1/chat/completions) استفاده می‌کند و از طریق متغیرهای محیطی (LLM_PROVIDER=digitalocean یا ollama) بین ارائه‌دهندگان جابجا می‌شود.
ساخت با عامل‌های هوش مصنوعی
جالب اینجاست که کل این برنامه با استفاده از GitHub Copilot و در یک ساختار بسیار منظم ساخته شده است. توسعه‌دهنده در نقش معمار و بازبین باقی ماند، در حالی که کوپایلت تایپ کردن کدها را از طریق یک گردش کار چهار مرحله‌ای مدیریت کرد:
۱. مشخصات دستی: توسعه‌دهنده فایل specs/SPEC-01.md (۴۵ خط) را به صورت دستی نوشت تا هدف، قوانین امنیتی و استک فنی را تعریف کند. هیچ بخشی از این فایل توسط AI تولید نشد.
۲. برنامه‌ریزی: حالت /plan کوپایلت، فایل specs/PLAN-01.md را تولید کرد که قبل از نوشتن هر کدی بازبینی شد تا از انحراف عامل (Agent) جلوگیری شود.
۳. تفکیک وظایف: حالت Agent یک فایل specs/TODO-01.md ایجاد کرد که شامل یک ردیاب اجرای ۳۶ وظیفه‌ای بود. قوانین سخت‌گیرانه‌ای وضع شد: کار باید از بالا به پایین باشد، برای هر وظیفه یک Commit ثبت شود و تا زمان تأیید، هیچ کدی به مخزن Remote ارسال نشود. اگر وظیفه‌ای بیش از حد بزرگ بود، فایل TODO ویرایش و در یک Changelog ثبت می‌شد.
۴. پیاده‌سازی: با استفاده از Claude Sonnet 5.5 در حالت Agent، هوش مصنوعی چک‌لیست را اجرا کرد. این مدل شش مهارت سطح پروژه برای React/Next.js، TypeScript، امنیت وب و Drizzle/MySQL را نصب کرد (npx skills add -a github-copilot).
برای حفظ بهره‌وری، توسعه‌دهنده از git worktree استفاده کرد. این کار به کوپایلت اجازه داد تا برنامه را در یک دایرکتوری بسازد، در حالی که توسعه‌دهنده در دایرکتوری دیگر و روی یک شاخه (Branch) جداگانه، پیش‌نویس پروژه را می‌نوشت تا از تداخلات و نیاز به Stashing جلوگیری شود. این فرآیند با ۲۰۸ تست موفق و یک بیلد عملیاتی تمیز به پایان رسید، هرچند تقریباً تمام سهمیه ماهانه Copilot را مصرف کرد.
زیرساخت استقرار
محیط عملیاتی روی یک DigitalOcean Droplet واحد (با اوبونتو ۲۶.۰۴) و با استفاده از یک اسکریپت install.sh idempotent اجرا می‌شود. استک فنی شامل موارد زیر است:
- MariaDB: سه دیتابیس (
birdsquest،birdsquest_testوtraccar) با کاربران مشخص برای خواندن/نوشتن برنامه و دسترسی فقط-خواندنی Traccar ایجاد شده است. تنظیمات ازCHARACTER SET utf8mb4استفاده می‌کنند. - Caddy: به عنوان پروکسی معکوس عمل کرده و HTTPS خودکار را برای وبلاگ و نقطه اتصال Traccar فراهم می‌کند.
- Next.js 16: از App Router و TypeScript برای وبلاگ عمومی و بخش
/adminاستفاده می‌کند. بخش مدیریت دارای ورود با argon2، توکن‌های CSRF و یک CSP مبتنی بر Nonce است. - Drizzle: به عنوان ORM استفاده شده است. صف وظایف (Job Queue) به صورت یک جدول دیتابیس با استفاده از دستور
FOR UPDATE SKIP LOCKEDپیاده‌سازی شده است. - زیرساخت: UFW طوری پیکربندی شده که فقط پورت‌های ۲۲، ۸۰ و ۴۴۳ را باز کند. استقرار از طریق یک مخزن git bare با یک post-receive hook (
git push production main) انجام می‌شود.
این رویکرد «تک صورت‌حسابی» (Single Bill) قطعات متحرک را برای یک پروژه تفننی که قرار است سال‌ها اجرا شود، به حداقل می‌رساند. توسعه‌دهنده تأکید می‌کند که استفاده از مدل‌های با وزن‌های باز مانند Gemma تضمین می‌کند که «صدای» وبلاگ ثابت بماند، زیرا می‌توان ID مدل را پین کرد تا از تغییرات غیرمنتظره ناشی از بازآموزی‌های ارائه‌دهنده جلوگیری شود.
الزامات توسعه محلی
برای کسانی که می‌خواهند پروژه را به صورت محلی اجرا کنند، پیش‌نیازها شامل Node 22+، pnpm، MariaDB و Ollama با مدل gemma4:e2b است. مراحل نصب شامل کپی کردن .env.example به .env و ایجاد دیتابیس‌ها و کاربران لازم از طریق مدیریت MariaDB است. توسعه‌دهنده اشاره کرد که سایت پس از تکمیل تست‌ها روی سرور زنده فعال خواهد شد؛ تا آن زمان، دامنه به یک پروفایل DEV ریدایرکت می‌شود.
نوآوری باز و حریم خصوصی
این پروژه گواهی بر قدرت اجزای متن‌باز است. با استفاده از مدل باز BirdNET GeoModel و سرور باز Traccar، توسعه‌دهنده تضمین می‌کند که داده‌های مکانی فقط روی ماشینی استفاده می‌شوند که خودش کنترل می‌کند. تنها لیست نهایی گونه‌ها به نقطه اتصال استنتاج (Inference Endpoint) می‌رسد. این معماری باعث می‌شود قانون حریم خصوصی واقع‌بینانه باشد و به هر کسی اجازه دهد مخزن را Fork کرده و آن را به سرور Traccar خودش متصل کند.
این پروژه نشان‌دهنده تغییری به سمت «هوش مصنوعی نامرئی» است؛ جایی که فناوری جایگزین فعالیت (پرنده‌نگری) نمی‌شود، بلکه سربارهای اداری مرتبط با آن را حذف می‌کند. با ترکیب ردیابی GPS متن‌باز، مدل‌های زمین‌فضایی و مدل‌های زبانی کوچک (SLMs)، آرشیوی شخصی ایجاد می‌شود که کاربر را تشویق می‌کند دوباره به طبیعت بازگردد. این فلسفه خروج از محیط‌های بسته و تعامل با دنیای واقعی، در سیستم DuckWalk که از Gemma برای ترغیب توسعه‌دهندگان به حضور در فضای باز استفاده می‌کند نیز دیده می‌شود.
گام بعدی شما
- اگر به طبیعت‌گردی علاقه دارید، بررسی کنید که آیا داده‌های GPS شما می‌تواند برای شناسایی گونه‌های بومی منطقه شما به همین شکل به کار رود یا خیر.
- برای توسعه‌دهندگان، بررسی معماری «گرسنگی پرامپت» در این پروژه راهکاری عالی برای پیاده‌سازی حریم خصوصی در اپلیکیشن‌های AI است.
- امتحان کنید که چگونه ترکیب یک مدل کوچک محلی (مانند Gemma 4 E2B) و یک مدل بزرگ ابری می‌تواند هزینه استنتاج را کاهش دهد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو