بانکی — جستجوی اسناد داخلی
جستجوی معنایی روی بخشنامهها، آییننامهها و گزارشهای اعتباری برای کارشناسان شعب و ستاد، با ACL مبتنی بر سطح دسترسی.
موتور جستجوی برداری بومیجستجوی برداری و معنایی برای RAG
Vector Search Engine — موتور جستجوی برداری برای RAG و جستجوی معنایی فارسی
GITA Vector یک پایگاه برداری بومی است که با مدلهای Embedding فارسی fine-tune شده، Hybrid Search و Cross-Encoder Reranking، دقت Retrieval پروژههای RAG شما را به سطح Production میرساند.
Recall@10: ۹۲٪ روی corpus فارسیتأخیر کوئری P99: ۱۸ میلیثانیهمقیاس میلیاردی با HNSW + IVF-PQ
جستجوی برداری و معنایی برای RAG
Vector
Authentication
Authorization
Lifecycle
Integration
انتخاب تیمهای Data و AI در سازمانهای پیشرو
۲ بانک خصوصی برای دستیار اسناد۳ سازمان دولتی برای جستجوی قوانین۴ پلتفرم eCommerce برای جستجوی معنایی۲ مرکز درمانی برای دانش پزشکی
+۲٫۸ میلیاردبردار ایندکسشده روی پلتفرم در محیط Production
مسیر ارزشآفرینی
ما نه فقط دردهای شما را میفهمیم — برای رسیدن به آنچه که سازمان شما باید باشد، نقشه میسازیم.
GITA Vector یک موتور جستجوی برداری بومی است که از روز اول برای زبان فارسی و سناریوهای RAG سازمانی طراحی شده. تیم Search ما در فاز Discovery، corpus سازمان شما را تحلیل میکند، مدل Embedding مناسب را انتخاب یا fine-tune میکند و معماری ایندکس را متناسب با حجم داده، الگوی کوئری و الزامات تأخیر طراحی میکند.
Before
وضعیت رایج امروز
- 01
LLM پاسخهای نامرتبط میدهد چون chunkهای اشتباه برداشته میشود
هزینه پنهان: افت اعتماد کاربر و افزایش هزینه توکن LLM
- 02
Elasticsearch فقط lexical match میکند و synonym فارسی را نمیفهمد
هزینه پنهان: Recall پایین در کوئریهای محاورهای و طولانی
- 03
ایندکسگذاری چند میلیون سند روی CPU روزها طول میکشد
هزینه پنهان: تأخیر در Time-to-Market و هزینه زیرساخت
- 04
Pinecone و Qdrant Cloud گزینه هستند ولی داده باید بیرون نرود
هزینه پنهان: ریسک انطباق و عدم امکان استقرار در محیط حاکمیتی
After
با Vector
- 01
مدلهای BGE-fa و multilingual-e5 fine-tune شده
قبلاً: Embedding انگلیسی روی متن فارسی
- 02
Hybrid Search دقیق: BM25 + Dense + RRF
قبلاً: جستجوی صرفاً lexical با BM25
- 03
Cross-Encoder Reranking با دقت +۲۳٪
قبلاً: Top-K بدون reranking و پر از نویز
- 04
Normalizer فارسی توکار قبل از embedding
قبلاً: نیمفاصله و ی/ک عربی نتایج را خراب میکند
معماری راهکار
معماری GITA Vector چگونه کار میکند — جریان داده زنده
در قلب پلتفرم، یک Vector Engine توزیعشده با sharding افقی و replication قرار دارد. Query Router درخواستها را به shardهای مرتبط میفرستد، Hybrid Searcher نتایج Dense (HNSW) و Sparse (BM25) را با Reciprocal Rank Fusion ترکیب میکند و در نهایت Cross-Encoder Reranker روی Top-N نتایج، رتبهبندی نهایی را انجام میدهد. Embedding Service جدا و GPU-accelerated است و Collectionها بهصورت Multi-Tenant کاملاً ایزوله مدیریت میشوند.
جریان داده
ورودیها
Clients & Identities
هسته احراز
Gateway · Auth · Policy · Token
لایه داده
Identity Store · HSM · Directory
ممیزی و تلهمتری
Audit Pipeline · Kafka
اپلیکیشنها
Apps & Cloud
درخواست احراز هویت
ارزیابی سیاست
صدور توکن
گزارش ممیزی
همگامسازی داده
روی برچسبهای بالا کلیک کنید تا فقط یک نوع جریان داده فعال شود — یا روی هر نود حرکت کنید برای نمایش پررنگتر.
قابلیتهای محصول
قابلیتهایی که Retrieval فارسی را Production-ready میکنند
10 ماژول تخصصی یکپارچه و قابل توسعه — برای انتخاب هر قابلیت، روی آن کلیک کنید.
هسته مدل
Persian-Tuned Embeddings
مدلهای Embedding بومی برای فارسی — BGE-fa، ParsBERT و multilingual-e5 fine-tune شده.
ما سه خانواده مدل را بهصورت managed ارائه میدهیم: BGE-fa برای دقت بالا در دامنه عمومی، ParsBERT برای متون رسمی و حقوقی، و multilingual-e5 برای سناریوهای دوزبانه فارسی-انگلیسی. هر مدل روی corpus بزرگ فارسی fine-tune شده و امکان fine-tune اختصاصی روی داده مشتری نیز فراهم است.
نکات کلیدی
- ابعاد ۷۶۸ و ۱۰۲۴ بسته به مدل
- Fine-tune اختصاصی روی corpus مشتری
- Quantization به int8 برای ۴ برابر صرفهجویی حافظه
- Batching هوشمند برای throughput بالا
برای شماRecall@10 معادل ۹۲٪ روی benchmark داخلی فارسی
موارد استفاده صنعتی
راهکار متناسب با صنعت و سناریوی شما
دولتی — قوانین و مقررات
ایندکس کامل قوانین، آییننامهها و آرای وحدت رویه با reranking دقیق برای کارشناسان حقوقی سازمانهای دولتی.
درمان — دانش پزشکی
جستجوی معنایی روی Guidelineهای بالینی، مقالات و پروتکلهای درمانی برای دستیار پزشک، با حفظ Data Residency داخل کشور.
حقوقی — Case Law
موتور جستجوی پروندهها و آرا برای دفاتر حقوقی و دادگستری با امکان فیلتر بر اساس مرجع، سال و موضوع.
دانشگاهی و پژوهشی
ایندکس پایاننامهها، مقالات و منابع کتابخانهای برای دستیار پژوهش با reranking معنایی فارسی-انگلیسی.
eCommerce — جستجوی معنایی محصول
جستجوی محصول بر اساس توصیف محاورهای کاربر، با ترکیب metadata (قیمت، برند، موجودی) و embedding تصویر و متن.
پشتیبانی — پایگاه دانش
دستیار پشتیبانی مبتنی بر RAG روی تیکتهای قبلی، مستندات محصول و FAQها برای کاهش زمان پاسخ کارشناسان.
رسانه و خبر
ایندکس آرشیو خبری چندساله با جستجوی معنایی، کشف موضوعات مرتبط و توصیه محتوای مشابه به مخاطب.
یکپارچهسازی
با اکوسیستم Data و AI شما یکپارچه میشود
+۴۰ ادغام آماده برای pipelineهای داده و RAG
Connector یا SDK خاصی نیاز دارید؟ درخواست توسعه سفارشیفرآیند پیادهسازی
از Corpus خام تا RAG عملیاتی در ۴ فاز
نقشه راه شفاف از اولین تماس تا عملیات دائمی — هر مرحله با خروجی قابل اندازهگیری.
PHASE 01
تحلیل Corpus و انتخاب مدل
۱ تا ۲ هفته
تحلیل ساختار و حجم corpus، انتخاب مدل Embedding مناسب، طراحی استراتژی chunking و تعریف معیارهای ارزیابی Retrieval.
سند Retrieval Design + Eval Benchmark
PHASE 02
Pilot Ingestion و Tuning
۲ تا ۴ هفته
ایندکسگذاری نمونه ۱۰٪ از corpus روی GPU، اجرای benchmark، tuning پارامترهای HNSW و وزن Hybrid، fine-tune reranker در صورت نیاز.
Recall@10 و MRR هدف، گزارش tuning
PHASE 03
Production Indexing و RAG
۳ تا ۶ هفته
ایندکس کامل corpus، اتصال به GITA LLM Service، راهاندازی pipeline ingestion پیوسته، تنظیم Hot/Cold Tiering.
RAG عملیاتی با SLA تأخیر و دقت
PHASE 04
عملیات و بهینهسازی پیوسته
دائمی
مانیتورینگ کیفیت Retrieval، بازآموزی دورهای embedding روی query log، گسترش Collectionها و پشتیبانی ۲۴/۷.
بهبود ماهانه دقت و گزارش SLA
PHASE 01۱ تا ۲ هفته
تحلیل Corpus و انتخاب مدل
تحلیل ساختار و حجم corpus، انتخاب مدل Embedding مناسب، طراحی استراتژی chunking و تعریف معیارهای ارزیابی Retrieval.
سند Retrieval Design + Eval Benchmark
PHASE 02۲ تا ۴ هفته
Pilot Ingestion و Tuning
ایندکسگذاری نمونه ۱۰٪ از corpus روی GPU، اجرای benchmark، tuning پارامترهای HNSW و وزن Hybrid، fine-tune reranker در صورت نیاز.
Recall@10 و MRR هدف، گزارش tuning
PHASE 03۳ تا ۶ هفته
Production Indexing و RAG
ایندکس کامل corpus، اتصال به GITA LLM Service، راهاندازی pipeline ingestion پیوسته، تنظیم Hot/Cold Tiering.
RAG عملیاتی با SLA تأخیر و دقت
PHASE 04دائمی
عملیات و بهینهسازی پیوسته
مانیتورینگ کیفیت Retrieval، بازآموزی دورهای embedding روی query log، گسترش Collectionها و پشتیبانی ۲۴/۷.
بهبود ماهانه دقت و گزارش SLA
سوالات متداول فنی
سوالاتی که تیم فنی شما احتمالاً میپرسد
آیا میتوانم مدل Embedding اختصاصی خودم را بیاورم؟+
بله، GITA Vector با هر مدل سازگار با API استاندارد embedding کار میکند. میتوانید مدل خود را روی Embedding Service ما deploy کنید یا از endpoint خارجی استفاده کنید. همچنین میتوانیم مدل پایه را روی corpus شما fine-tune کنیم.
تفاوت Hybrid Search شما با Elasticsearch + Vector Plugin چیست؟+
Elasticsearch با plugin برداری، Dense و BM25 را جداگانه اجرا میکند ولی ترکیب نتایج معمولاً ساده است. ما RRF با وزن قابل تنظیم در زمان کوئری، Cross-Encoder Reranking یکپارچه و tokenizer فارسی اختصاصی داریم که در benchmark داخلی، nDCG@10 را ۱۸٪ بالاتر میبرد.
حداکثر ابعاد بردار و تعداد بردار چقدر است؟+
ابعاد بردار تا ۴۰۹۶ پشتیبانی میشود (مناسب برای مدلهای بزرگ). تعداد بردار در هر Collection محدودیت سختی ندارد و در محیط Production ما Collectionهایی با بیش از ۲ میلیارد بردار با P99 معادل ۴۸ میلیثانیه اجرا میشوند.
آیا برای پیادهسازی RAG حتماً باید از GITA LLM Service استفاده کنیم؟+
خیر. GITA Vector کاملاً مستقل است و با هر LLM (OpenAI، Azure OpenAI، Anthropic، LLM داخلی) کار میکند. اما اگر از GITA LLM Service استفاده کنید، ادغام نزدیکتر، caching یکپارچه و گزارشهای ترکیبی دریافت میکنید.
نرمالسازی فارسی دقیقاً چه کاری انجام میدهد؟+
Pipeline ما ي و ك عربی را به ی و ک فارسی تبدیل میکند، نیمفاصله و ZWNJ را نرمال میسازد، اعراب اختیاری را حذف میکند، اعداد فارسی/عربی/انگلیسی را یکسان میکند و کاراکترهای کنترلی نامرئی را پاک میکند. این مرحله قبل از BM25 tokenization و قبل از embedding انجام میشود.
Multi-Tenant چگونه پیادهسازی میشود؟ آیا دادهها واقعاً ایزوله هستند؟+
هر Collection کلید رمزنگاری مستقل، فضای ذخیرهسازی جدا و RBAC اختصاصی دارد. کوئریها نمیتوانند از مرز Collection عبور کنند و حتی در سطح shard، metadata هر tenant tag میشود. برای الزامات سختگیرانه، حالت dedicated node نیز قابل ارائه است.
GPU الزامی است یا روی CPU هم کار میکند؟+
GPU برای embedding و reranking در حجم بالا توصیه میشود ولی الزامی نیست. روی CPU، throughput پایینتر است (تخمین ۵ تا ۱۰ برابر) ولی برای Collectionهای کوچکتر یا حالتهای آفلاین کاملاً قابل قبول است. خود ایندکس HNSW در زمان query روی CPU بسیار سریع است.
Hot/Cold Tiering چگونه روی تأخیر کوئری اثر میگذارد؟+
بردارهای داغ در RAM/NVMe در حد چند میلیثانیه پاسخ میدهند. کوئری روی shard سرد با pre-warm هوشمند، حدود ۳۰ تا ۴۵ میلیثانیه تأخیر افزوده دارد. الگوریتم Promotion ما بر اساس access pattern، بردارهای داغ را به صورت خودکار به tier بالاتر منتقل میکند.
آیا استقرار On-Premise و Air-Gapped پشتیبانی میشود؟+
بله، تمام مولفهها روی Kubernetes یا VM قابل اجرا هستند و هیچ تماس خارجی برقرار نمیکنند. مدلهای Embedding و Reranker بهصورت آفلاین deliver میشوند و بهروزرسانی از طریق mirror داخلی انجام میشود.
نحوه قیمتگذاری بر اساس چیست؟+
قیمتگذاری بر اساس تعداد بردار ایندکسشده، QPS و منابع محاسباتی (CPU/GPU) است. برای استقرار On-Prem، مدل licensing سالانه با تعداد node داریم. در فاز Discovery، تخمین دقیق هزینه متناسب با حجم corpus و الگوی کوئری شما ارائه میشود.
تماس مستقیم با تیم فنی
یک جلسه فنی با تیم Search رزرو کنید
۳۰ دقیقه با مهندس ارشد Search ما صحبت کنید. corpus نمونه شما را روی محیط دمو ایندکس میکنیم و Recall واقعی را نشان میدهیم. رایگان، بدون پرزنتیشن فروش.
فرم درخواست جلسه
مرحله ۱ از ۲