Solon AI خط لوله‌های RAG را به اکوسیستم جاوا آورد

تصور کنید برنامه‌نویسی هستید که باید پاسخ‌های مدل زبانی را به مستندات داخلی شرکت متصل کند، اما مجبور است برای این کار، کل زیرساخت جاوا را رها کرده و به سراغ اسکریپت‌های پایتون برود. این گسست فنی، حالا با معرفی ماژول Solon AI در فریم‌ورک Solon به پایان رسیده است. بسیاری از مدل‌های زبانی بزرگ (LLM) — چون فقط آنچه را که در زمان آموزش دیده‌اند می‌شناسند — وقتی با داده‌های خصوصی، یادداشت‌های انتشار هفته گذشته یا تاریخچه پشتیبانی مشتریان مواجه می‌شوند، یا از پاسخ دادن شانه خالی می‌کنند و یا دچار توهم (Hallucination) می‌شوند؛ یعنی با اطمینان کامل، چیزی را می‌گویند که وجود ندارد. برای حل این مشکل، توسعه‌دهندگان جاوا اکنون می‌توانند بدون تغییر زبان، خط لوله‌های RAG آماده برای محیط عملیاتی بسازند. طبق یک راهنمای فنی، این فریم‌ورک فرآیند مبنی‌سازی (Grounding) مدل‌ها را از طریق یک معماری پنج‌گانه، ترکیب‌پذیر و ساده شده مدیریت می‌کند.

بسیاری از آموزش‌های RAG بر روی پشته‌های پایتون-محور تمرکز دارند و مهندسان جاوا را مجبور می‌کنند تا بین کتابخانه‌های پراکنده جابه‌جا شوند یا اسکریپت‌های پایتون را در لایه‌های دیگر Wrap کنند. این شکاف در محیط‌های سازمانی که جاوا زبان اصلی زیرساخت‌های بک‌اند است، اصطکاک زیادی ایجاد می‌کند. با ارائه یک پیاده‌سازی بومی در جاوا، Solon AI به تیم‌ها اجازه می‌دهد منطق هوش مصنوعی خود را در اکوسیستم Type-safe موجود نگه دارند. هر API در این فریم‌ورک به‌گونه‌ای طراحی شده که واقعی و در برابر سورس‌کد solon-ai قابل تایید باشد تا از نام متدهای توهمی که اغلب در آموزش‌های تولید شده توسط AI دیده می‌شود، جلوگیری شود.

به نقل از مستندات Solon AI، یک خط لوله در این سیستم از پنج جزء اصلی تشکیل شده است:

• EmbeddingModel: تبدیل متن خام به بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که می‌گوید این کلمه «همسایه‌ی» چه کلمات دیگری است. این بخش از ارائه‌دهندگانی چون Ollama، OpenAI، DashScope و Gemini پشتیبانی می‌کند.
• Document: یک شیء داده شامل محتوا، یک Map<String, Object> برای متاداده‌ها، یک امتیاز گذرا (که هنگام جست‌وجو پر می‌شود) و یک آرایه float[] برای Embedding.
• DocumentSplitter: ابزاری برای تکه‌بندی (Chunking) متون طولانی به قطعات قابل مدیریت تا با پنجره متنی (Context Window) مدل سازگار شوند.
• Repository: لایه‌ی ذخیره‌سازی بردارها که از طریق رابط RepositoryStorable جست‌وجوهای شباهت را پشتیبانی می‌کند.
• ChatModel: مدل زبانی نهایی (LLM) که پاسخ نهایی را بر اساس بستر بازیابی‌شده تولید می‌کند.

گردش‌کار این سیستم از یک مسیر خطی سخت‌گیرانه پیروی می‌کند: ابتدا متن تکه‌بندی می‌شود، سپس تکه‌ها به بردار تبدیل شده و در نهایت ذخیره می‌شوند. در زمان پرسش، سیستم سوال را به بردار تبدیل کرده، در مخزن جست‌وجو می‌کند، پرامپت را تقویت (Augment) کرده و پاسخ را تولید می‌نماید.

توسعه‌دهندگان می‌توانند با استفاده از وابستگی تجمیعی solon-ai (نسخه ۳.۵.۱) کار را آغاز کنند که هسته اصلی را به همراه Dialectهای OpenAI, Ollama, DashScope, Gemini و Anthropic فراخوانی می‌کند. برای توسعه محلی، این فریم‌ورک با Ollama ادغام شده است تا کاربران بتوانند مدل‌هایی مثل qwen2.5 برای گفتگو و bge-m3 برای تولید بردارها را بدون نیاز به کلیدهای API اجرا کنند.

یکی از ویژگی‌های متمایز، SplitterPipeline است که اجازه می‌دهد منطق تکه‌بندی را با استفاده از متد .next() زنجیروار کنید. برای مثال، کاربر می‌تواند ابتدا متن را بر اساس خطوط خالی با استفاده از RegexTextSplitter (که به‌طور پیش‌فرض روی \n\n تنظیم شده) جدا کند و سپس هر تکه را با استفاده از TokenSizeTextSplitter (که توسط CL100K_BASE در jtokkit پشتیبانی می‌شود) به ۵۰۰ توکن محدود کند.

مدیریت ذخیره‌سازی از طریق رابط RepositoryStorable انجام می‌شود. متد save() به‌طور خودکار دسته‌بندی داده‌ها (Batching) را بر اساس تنظیمات EmbeddingModel.batchSize() مدیریت می‌کند، به این معنی که برنامه‌نویس هرگز مجبور نیست آرایه‌های برداری را به‌صورت دستی مدیریت کند. این API همچنین متدهای asyncSave()، deleteById(String) و existsById(String) را برای مدیریت کامل چرخه حیات داده‌ها فراهم می‌کند. برای نمونه‌های اولیه، InMemoryRepository کافی است، اما فریم‌ورک طیف گسترده‌ای از ذخیره‌سازهای عملیاتی را پشتیبانی می‌کند.

بازیابی داده‌ها توسط کلاس QueryCondition کنترل می‌شود. هنگام جست‌وجو، توسعه‌دهندگان می‌توانند چندین پارامتر را برای پالایش نتایج زنجیر کنند:

• limit(int): تعیین می‌کند چه تعداد تکه بازگردانده شود (پیش‌فرض ۴ است).
• similarityThreshold(double): حداقل امتیاز برای نگه داشتن یک سند را تعیین می‌کند (پیش‌فرض ۰.۴ است).
• filterExpression(String): یک فیلتر متاداده را با استفاده از زبان SnEL اعمال می‌کند.

افزودن بستر (Augmentation) به دو صورت رخ می‌دهد. روش اصلی ChatMessage.ofUserAugment(question, context) است که پرسش را در قالبی شامل سوال، زمان فعلی و مراجع می‌پیچد. در روش جایگزین، Repository یک متد تک‌خطی به نام repository.promptAugment(question) ارائه می‌دهد که جست‌وجو و تقویت پرامپت را در یک فراخوانی ترکیب می‌کند.

بر اساس بررسی منابع متعدد، Solon AI اکوسیستم وسیعی از پایگاه‌های‌داده برداری را از طریق ماژول‌های مجزای Maven پشتیبانی می‌کند. این لیست شامل Redis (solon-ai-repo-redis)، Milvus، Qdrant، pgvector، Elasticsearch، OpenSearch، Chroma، Weaviate، MySQL و MariaDB است. از آنجا که رابط Repository در همه این ذخیره‌سازها یکسان است، جایگزینی یک مخزن موقت با یک مخزن دائمی مثل Redis، هیچ تغییری در کد بازیابی یا تولید پاسخ ایجاد نمی‌کند. برای مثال، یک RedisRepository از طریق یک Builder مقداردهی می‌شود که EmbeddingModel و یک کلاینت Jedis را دریافت کرده و یک indexName برای اسناد مشخص می‌کند. این انتزاع از وابستگی شدید به یک فروشنده (Vendor Lock-in) در سطح اپلیکیشن جلوگیری می‌کند.

برای مدیریت داده‌های پیچیده، فریم‌ورک لودرهای متنوعی را شامل می‌شود. در حالی که TextLoader در هسته اصلی، فایل‌ها، URIها، URLها و آرایه‌های بایتی را مدیریت می‌کند، ماژول‌های مجزا لودرهای تخصصی‌تری ارائه می‌دهند: MarkdownLoader، PdfLoader، HtmlSimpleLoader، WordLoader، ExcelLoader و PptLoader. هر لودر یک List<Document> برمی‌گرداند و تضمین می‌کند که داده‌ها مستقیماً وارد جریان «تکه‌بندی $\rightarrow$ ذخیره» شوند. این فرآیند آماده‌سازی داده‌ها برای RAG، یادآور تلاش‌های شرکت IBM در عرضه ابزار Docling برای پاک‌سازی PDFهای پیچیده است تا داده‌های ساختاریافته‌تری به مدل‌ها برسد.

بازیابی با استفاده از SnEL (زبان بیان Solon) باز هم دقیق‌تر می‌شود. متد filterExpression به توسعه‌دهندگان اجازه می‌دهد شباهت برداری را با فیلترهای متاداده ساختاریافته ترکیب کنند. برای مثال، یک پرسش را می‌توان به اسنادی محدود کرد که category == 'framework' AND year >= 2024 باشند. در پشت صحنه، SnEL.parse این رشته را به یک درخت بیان قابل انتقال تبدیل می‌کند و سپس ذخیره‌ساز برداری آن را به نحو فیلتر بومی خود بازنویسی می‌کند.

فراتر از بازیابی استاتیک، Solon AI از RAG عامل‌محور (Agentic RAG) از طریق RepositoryTool پشتیبانی می‌کند. با بسته‌بندی یک مخزن به عنوان یک ابزار قابل فراخوانی با @ToolMapping("repository_query")، یک ChatModel (مانند gpt-4o-mini) می‌تواند به‌طور خودکار تصمیم بگیرد که چه زمانی در طول یک گفتگوی چندمرحله‌ای نیاز به جست‌وجو در پایگاه‌داده دارد، به جای اینکه برای هر پرامپت داده‌ها را بازیابی کند. این رویکرد بهینه‌سازی جریان‌های کاری AI، مشابه تلاش‌های فریم‌ورک Imp برای آوردن برنامه‌نویسی خودبهینه‌ساز به Elixir است که هدف هر دو، کاهش اصطکاک در پیاده‌سازی منطق‌های پیچیده AI در زبان‌های برنامه‌نویسی مختلف است.

این تغییر به سمت یک فریم‌ورک یکپارچه AI در جاوا، «مالیات زبانی» (Language Tax) را که توسعه‌دهندگان سازمانی می‌پرداختند، کاهش می‌دهد. با انتزاع ذخیره‌ساز برداری و فرآیند Embedding، Solon AI با RAG به عنوان یک الگوی استاندارد مهندسی نرم‌افزار برخورد می‌کند، نه یک آزمایش علوم داده. مدل ذهنی به یک خط لوله ساده تبدیل شده است: تکه‌بندی $\rightarrow$ تبدیل به بردار $\rightarrow$ ذخیره، و سپس تبدیل به بردار $\rightarrow$ جست‌وجو $\rightarrow$ تقویت $\rightarrow$ تولید.

برای اکوسیستم جاوا، این بدان معناست که ادغام AI از حاشیه پشته به هسته آن منتقل می‌شود. توانایی استفاده از یک زبان بیان واحد (SnEL) برای هدف قرار دادن چندین پایگاه‌داده برداری مختلف، یک پیروزی بزرگ برای قابلیت نگهداری و مقیاس‌پذیری است. این امر اجازه می‌دهد یک پروژه با InMemoryRepository شروع شود تا جریان کار اثبات گردد و سپس بدون بازنویسی کد، به pgvector یا Redis مقیاس یابد.

توسعه‌دهندگان اکنون باید ارزیابی کنند که آیا Wrapperهای AI مبتنی بر پایتون آن‌ها باعث ایجاد تأخیر (Latency) یا پیچیدگی در استقرار شده است یا خیر. در واقع، تأخیرهای ناشی از معماری‌های فعلی تولید متن یکی از چالش‌های کلیدی است که انتقال به فریم‌ورک‌های بومی می‌تواند بخشی از آن را حل کند. انتقال این خط لوله‌ها به یک فریم‌ورک بومی جاوا می‌تواند فرآیند CI/CD را برای اپلیکیشن‌های مبتنی بر LLM به‌شدت ساده کند. برای شروع، توسعه‌دهندگان می‌توانند سورس‌کد را در github.com/opensolon/solon-ai بررسی کرده یا به solon.noear.org مراجعه کنند.

گام بعدی شما

• اگر زیرساخت جاوا دارید، وابستگی solon-ai نسخه ۳.۵.۱ را برای تست اولیه در پروژه اضافه کنید.
• برای کاهش هزینه‌ها، مدل‌های qwen2.5 و bge-m3 را از طریق Ollama به‌صورت محلی اجرا کنید.
• ساختار SplitterPipeline را برای بهینه‌سازی تکه‌بندی اسناد تخصصی خود پیاده‌سازی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.