منابع دانش

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

انواع منبع

نوع	کاربرد	چه چیزی دریافت می‌شود
url	یک صفحه خاص	اسکن + استخراج محتوای اصلی + تکه‌تکه کردن + جستجوی هوشمند
sitemap	یک سایت کامل به‌یکباره	خواندن نقشه سایت، گسترش به یک CrawlPageJob به ازای هر آدرس
feed	وبلاگ‌های RSS / Atom	مشابه نقشه سایت اما ورودی‌های <item> را می‌خواند
text	سوالات متداول، قطعه‌کدها، هر چیزی که می‌توانید بچسبانید	رد شدن از اسکن، تکه‌تکه کردن + جستجوی هوشمند مستقیم
notion	صفحات یا پایگاه‌های داده نوتین	OAuth به نوتین، دریافت از طریق API، هر صفحه را به‌عنوان یک سند در نظر بگیرید
google_doc	گوگل داکس (Workspace)	OAuth، دریافت از طریق API درایو، دریافت به‌عنوان یک سند
google_sheet	برگه‌های گوگل شیت	OAuth، دریافت هر ردیف غیرخالی، یک بدنه سند با نشانگرهای Row N: …
sql	MySQL / PostgreSQL راه‌دور	SELECT فقط خواندنی PDO مستقیم؛ یک بدنه سند با نشانگرهای Row N: …. اعتبارنامه‌ها AES-256-GCM در حالت استراحت.
file	آپلودهای PDF / DOCX / XLSX	تجزیه از طریق Cloudflare toMarkdown (سطح رایگان)، تکه‌تکه + جستجوی هوشمند
woocommerce_products	فروشگاه‌های WP / ووکامرس	همگام‌سازی توسط افزونه همراه وردپرس
auto	صفحاتی که بازدیدکنندگان روی آنها فرود می‌آیند	صف‌بندی خودکار توسط AutoIndexPageVisit از /v1/widget/init

منبع پایگاه داده SQL (MySQL + PostgreSQL)

یک پایگاه داده MySQL یا PostgreSQL فقط خواندنی را مستقیماً به‌عنوان یک منبع دانش متصل کنید. هر ردیف غیرخالی که SELECT شما برمی‌گرداند، بخشی از داده‌های آموزشی دستیار فروش می‌شود، با ارجاعاتی که هوش مصنوعی می‌تواند به‌عنوان مراجع Row N استفاده کند.

مراحل راه‌اندازی:

1. /app/agents/{id}/sources را باز کنید، به افزودن پایگاه داده SQL بروید.
2. درایور را انتخاب کنید (MySQL یا PostgreSQL) — پورت به‌طور خودکار روی 3306 یا 5432 پر می‌شود.
3. میزبان، نام پایگاه داده، نام کاربری، رمز عبور را وارد کنید.
4. یک کوئری SELECT بچسبانید — هر ردیف که برگرداند، بخشی از پایگاه دانش دستیار فروش می‌شود.
5. نگاشت ستون اختیاری: یک title_column (به‌عنوان برچسب ردیف استفاده می‌شود) و یک body_column (به‌عنوان محتوای ردیف استفاده می‌شود) انتخاب کنید. در صورت حذف، هر ستون به‌صورت جفت‌های colname: value الحاق می‌شود.
6. روی اتصال و همگام‌سازی کلیک کنید. اولین SyncSqlSourceJob در صف crawl اجرا می‌شود، ردیف‌ها را پردازش کرده و منبع را به indexed تغییر می‌دهد.

قوانین سخت اعمال‌شده بر هر کوئری:

• محافظ SSRF. میزبان از UrlSafetyGuard::assertSafe() عبور می‌کند — همان لیست مجاز که خزنده استفاده می‌کند. 127.0.0.1، محدوده‌های RFC1918، لینک-محلی 169.254.0.0/16 (IP فراداده AWS) و هر نامی که به IP خصوصی حل شود، همه رد می‌شوند. منبع با پیام "میزبان SQL ناامن: از اسکن میزبان داخلی / لوپ‌بک / لینک-محلی خودداری کنید." به failed تغییر می‌کند.
• فقط SELECT. کوئری باید با SELECT شروع شود (بدون در نظر گرفتن حروف بزرگ و کوچک). کوئری‌های چندجمله‌ای (حاوی ;) رد می‌شوند. کلمات کلیدی INSERT، UPDATE، DELETE، DROP، ALTER، TRUNCATE، GRANT، REVOKE، CREATE، REPLACE، CALL، EXEC، EXECUTE، MERGE، LOAD مسدود هستند.
• تراکنش فقط خواندنی. اتصال‌دهنده کوئری را در START TRANSACTION READ ONLY (MySQL) / BEGIN TRANSACTION READ ONLY (PostgreSQL) می‌پیچد، بنابراین حتی یک رشته کوئری مجاز نیز نمی‌تواند وضعیت را تغییر دهد.
• سقف ۵,۰۰۰ ردیف در هر همگام‌سازی. از حافظه پردازشگر و جدول Document در برابر کوئری‌های سرکش محافظت می‌کند. اگر جدول بزرگی دارید که نمی‌خواهید به‌طور کامل پردازش شود، SELECT خود را با یک LIMIT محدود کنید.
• زمان اتصال ۱۰ ثانیه. میزبان‌هایی که قابل دسترسی نیستند، سریعاً شکست می‌خورند — خریداران خطا را در همانجا می‌بینند.

اعتبارنامه‌ها در حالت استراحت:

میزبان، پورت، نام پایگاه داده، نام کاربری و رمز عبور در sources.credentials_encrypted (ستون متن) ذخیره می‌شوند و از طریق تبدیل encrypted:array لاراول — AES-256-GCM با APP_KEY نصب — رمزگذاری می‌شوند. بخش‌های غیرحساس (درایور، کوئری، نگاشت‌های ستون عنوان/بدنه، برچسب اختیاری) در ستون JSON معمولی config قرار دارند.

خواندن ستون خام فقط متن رمز تولید می‌کند؛ متن ساده فقط در حافظه پردازشگر در طول اجرای همگام‌سازی قابل مشاهده است و هرگز ثبت نمی‌شود. چرخش APP_KEY از خریداران می‌خواهد که رمز عبور را دوباره وارد کنند (رفتار استاندارد لاراول — مشاهده کنید امنیت).

چه چیزی پردازش می‌شود:

هر ردیف به یک خط برچسب‌دار در یک بدنه سند تبدیل می‌شود. زمانی که title_column = "title" و body_column = "body" را تنظیم کنید، یک ردیف با { title: "Welcome", body: "Hello world" } به این صورت نمایش داده می‌شود:

Welcome: Hello world

بدون ستون بدنه، به یک پیوستن کلید/مقدار از هر ستون غیرتهی بازمی‌گردد:

Row 1 — id: 42, name: ACME Corp, plan: Pro, last_seen: 2026-05-13

سپس بدنه سند از طریق همان مسیر IndexDocumentJob که سایر منابع استفاده می‌کنند، تکه‌تکه شده و به بردار تبدیل می‌شود، بنابراین ردیف‌های SQL در بازیابی مانند صفحات اسکن‌شده یا متن چسبانده‌شده ظاهر می‌شوند.

همگام‌سازی مجدد امروز: به‌صورت دستی از طریق اقدام بازخوانی منبع. همگام‌سازی خودکار دوره‌ای هنوز زمان‌بندی نشده است — مشابه نوتین / گوگل داکس / گوگل شیت. اگر کرون می‌خواهید، یک کارت ثبت کنید.

درایورهایی که هنوز ارائه نشده‌اند: MSSQL و Oracle. هر دو به افزونه‌های PHP (pdo_sqlsrv / oci8) نیاز دارند که به‌طور پیش‌فرض ارائه نمی‌شوند و در همه میزبان‌های CodeCanyon جهانی نیستند. اگر به آنها نیاز دارید، یک درخواست قابلیت باز کنید.

افزودن منبع

/app/agents/{id}/sources را باز کنید. مودال افزودن منبع همه انواع را در یک فرم مدیریت می‌کند. در پشت صحنه:

1. اعتبارسنجی. آدرس‌ها باید http/https باشند. میزبان‌های خصوصی (10.x، 192.168.x، 127.x، ::1) برای جلوگیری از SSRF مسدود می‌شوند.
2. ایجاد ردیف منبع با status = pending.
3. ارسال یک وظیفه — CrawlSourceJob برای url/sitemap/feed؛ IngestNotionPageJob/IngestGoogleDocJob برای منابع متصل؛ IndexTextSourceJob برای متن چسبانده‌شده.
4. وظیفه در صف crawl اجرا می‌شود، محتوا را دریافت می‌کند، ردیف‌های Document را ایجاد می‌کند، سپس IndexDocumentJob را در صف index ارسال می‌کند.
5. وضعیت تغییر می‌کند از pending → crawling → done (یا failed با پیام خطایی که می‌توانید در رابط کاربری بخوانید).

"پردازش خودکار کامل نشد" — تشخیص صفحات ناموفق

یک صفحه می‌تواند در نمای دانش با ۰ تکه و یک نشان نارنجی "پردازش خودکار کامل نشد" قرار گیرد. ردیف گسترش‌یافته اکنون خطای واقعی از sources.error را در صورت وجود، به علاوه خزنده استفاده‌شده و زمان‌مهر آخرین دریافت را نشان می‌دهد. بیشتر شکست‌ها به یکی از این موارد مربوط می‌شوند:

• فقط جاوااسکریپت / صفحات SPA بدون بازگشت SSR — Cloudflare Browser Rendering JS را اجرا می‌کند، اما اگر برنامه کاملاً در سمت کلاینت هیدراته شود و متن قابل استخراجی ارائه نکند، استخراج‌کننده زیر کف ۲۰۰ کاراکتر را برمی‌گرداند و منبع به‌عنوان ناموفق علامت‌گذاری می‌شود.
• چالش ربات / محافظت Cloudflare — HTML دریافت‌شده صفحه چالش است، نه محتوای واقعی. از طریق اکتشافی detectBlocker() تشخیص داده می‌شود.
• دیوار ورود — سایت نیاز به احراز هویت دارد؛ ما اسکن احراز هویت‌شده اجرا نمی‌کنیم.
• 404 نرم — بسیاری از سایت‌ها زمانی که آدرس اشتباه تایپ می‌شود، یک صفحه "یافت نشد" با کد ۲۰۰-OK برمی‌گردانند. looksLike404() این موارد را رد می‌کند.
• پردازشگر صف عقب است — ردیف سند ایجاد شده است اما IndexDocumentJob هنوز اجرا نشده است. یک دقیقه صبر کنید و بازخوانی کنید؛ اگر ادامه داشت، سلامت صف را بررسی کنید.

روی یک ردیف ناموفق روی پردازش مجدد کلیک کنید تا همان مسیر را دوباره امتحان کنید (اسکن مجدد آدرس + پردازش مجدد، یا تجزیه مجدد فایل برای آپلودها). شکست‌های مداوم معمولاً به این معنی است که خود آدرس قابل اسکن نیست — صفحه دیگری را در همان سایت امتحان کنید، یا محتوا را به‌صورت فایل آپلود کنید.

تغییر مدل‌های جستجوی هوشمند

شاخص Vectorize کلودفلر با ابعاد دقیق مدل جستجوی هوشمندی که در زمان ایجاد اولیه فعال بود، تأمین می‌شود. تغییر CLOUDFLARE_EMBED_MODEL از یک مدل ۷۶۸ بعدی (bge-base-en-v1.5) به یک مدل ۱۰۲۴ بعدی (bge-m3، bge-large-en-v1.5) یا برعکس، باعث می‌شود هر IndexDocumentJob با خطای زیر از کار بیفتد:

Cloudflare 40012: invalid vector for id="...", expected 768 dimensions, and got 1024 dimensions

Pitchbar اکنون این را قبل از ارسال upsert تشخیص می‌دهد، یک خطای عملی نمایش می‌دهد و یک دستور بازیابی ارائه می‌کند. نقشه شناخته‌شده مدل→بعد (به‌طور خودکار اعمال می‌شود زمانی که محیط VECTOR_DIM تنظیم نشده باشد):

مدل	بعد
@cf/baai/bge-small-en-v1.5	384
@cf/baai/bge-base-en-v1.5 (پیش‌فرض)	768
@cf/baai/bge-large-en-v1.5	1024
@cf/baai/bge-m3	1024
text-embedding-3-small	1536
text-embedding-3-large	3072
text-embedding-ada-002	1536

بازیابی: شاخص موجود را حذف کنید، با بعد جدید دوباره ایجاد کنید و IndexDocumentJob را برای هر سند دوباره ارسال کنید:

php artisan vector:rebuild-index           # تعاملی — قبل از ادامه می‌پرسد
php artisan vector:rebuild-index --force   # برای خودکارسازی / CI
php artisan vector:rebuild-index --dim=1024  # لغو بعد حل‌شده

دستور هر منبع را به pending بازنشانی می‌کند، هر ردیف Chunk را حذف می‌کند، شاخص Vectorize را حذف می‌کند، آن را با بعد هدف دوباره ایجاد می‌کند و یک وظیفه پردازش مجدد به ازای هر سند در صف index قرار می‌دهد. اسناد پشتیبان‌فایل از متن ذخیره‌شده روی دیسک دوباره پردازش می‌شوند. اسناد فقط آدرس نیاز به کلیک دستی پردازش مجدد دارند (که CrawlPageJob را برای دریافت مجدد فعال می‌کند).

کشف خودکار

در صفحه منابع، دکمه کشف یک دامنه را گرفته و بدون نیاز به لیست کردن آنها، صفحات قابل اسکن را بررسی می‌کند. ما:

• robots.txt را برای اعلان‌های نقشه سایت می‌خوانیم.
• در صورت وجود، مستقیماً یک نقشه سایت را بررسی می‌کنیم.
• مجموعه کوچکی از مسیرهای رایج را امتحان می‌کنیم: /about، /pricing، /features، /products، /faq، /docs، /help، /support، /contact.
• یک لیست قابل علامت‌گذاری برمی‌گردانیم. مواردی را که می‌خواهید دریافت کنید علامت بزنید، روی افزودن انتخاب‌شده کلیک کنید.

گسترش نقشه سایت

افزودن یک منبع از نوع sitemap یک CrawlPageJob به ازای هر آدرس در نقشه سایت، با تأخیر کوچک در هر صفحه ارسال می‌کند تا بارگذاری کامل صفحات با کلودفلر در صورت افزایش ناگهانی، محدودیت نرخ ندهد. کشف‌کننده (SitemapDiscoverer) سه شکل ورودی را مدیریت می‌کند:

• ریشه دامنه (https://example.com) — /sitemap.xml + /sitemap_index.xml را بررسی می‌کند.
• آدرس مستقیم نقشه سایت (https://example.com/sitemap.xml یا https://example.com/products/sitemap.xml) — به‌صورت کامل دریافت می‌شود. قبلاً کشف‌کننده یک /sitemap.xml دوم در اینجا اضافه می‌کرد و درخواست را با خطای ۴۰۴ مواجه می‌کرد.
• شاخص نقشه سایت (XML <sitemapindex> که بسیاری از سیستم‌های مدیریت محتوا — وردپرس، شاپیفای، وب‌فلو — به‌طور پیش‌فرض منتشر می‌کنند) — یک سطح به هر نقشه سایت فرزند بازگشت کرده و آدرس‌های صفحه را جمع‌آوری می‌کند.

خروجی حذف تکراری می‌شود (بنابراین یک آدرس که در دو نقشه سایت فرزند لیست شده است، یک بار پردازش می‌شود) و به services.crawl.max_pages_per_source محدود می‌شود (پیش‌فرض ۵۰۰، از طریق CRAWL_MAX_PAGES_PER_SOURCE قابل لغو است). سقف قبلاً ۲۵ بود — یک خریدار که یک نقشه سایت ۱۰۰ آدرسی اضافه می‌کرد، ۷۵ صفحه را بی‌صدا از دست می‌داد — پیش‌فرض جدید به اندازه کافی برای بیشتر سایت‌های بازاریابی / مستندات سخاوتمندانه است. کاتالوگ‌های بسیار بزرگ باید به‌هرحال نقشه سایت را براساس بخش تقسیم کنند.

راهبردهای خزنده

خزنده توسط ارائه‌دهنده هدایت می‌شود. به ترتیب اولویت:

1. بارگذاری کامل صفحات با کلودفلر — ترجیح داده می‌شود. اجرای کامل جاوااسکریپت، سریع، بدون خطر SSRF زیرا خروجی در کلودفلر است. زمانی استفاده می‌شود که CLOUDFLARE_ACCOUNT_ID + CLOUDFLARE_API_TOKEN تنظیم شده باشند.
2. Browserless — بازگشت زمانی که BROWSERLESS_TOKEN تنظیم شده باشد. همان رفتار هدلس-کروم در یک فروشنده متفاوت.
3. HTTP ساده — آخرین راه حل برای سایت‌های نمایش داده شده توسط سرور. بدون اجرای JS. رایگان.

پس از دریافت HTML، ReadabilityExtractor ناوبری، فوتر، تبلیغات و غیره را حذف کرده و بدنه مقاله را باقی می‌گذارد. صفحات زیر ۲۰۰ کاراکتر یا تشخیص‌داده‌شده به‌عنوان ۴۰۴ حذف می‌شوند.

تجزیه آپلود فایل

آپلود مستقیم فایل (منابع ← آپلود فایل‌ها) ابتدا به‌صورت محلی تجزیه می‌شوند، سپس به همان مسیر تکه‌تکه + جستجوی هوشمند که صفحات اسکن‌شده استفاده می‌کنند، تحویل داده می‌شوند. تجزیه‌کننده براساس پسوند فایل انتخاب می‌شود:

پسوند	تجزیه‌کننده	فراخوانی شبکه؟
.pdf، .docx، .doc، .xlsx، .xls، .odt، .ods	Cloudflare Workers AI toMarkdown در صورت پیکربندی اعتبارنامه‌های CF؛ در غیر این صورت Smalot\PdfParser / PhpOffice\PhpWord	بله — یک درخواست multipart POST به ازای هر فایل به /ai/tomarkdown (رایگان، ۰ نورون)
.csv	League\Csv — یک بخش به ازای هر ردیف با فرمت col: value | col: value منتشر می‌کند	خیر
.md، .markdown، .txt	متن ساده، تقسیم براساس تیترهای H1/H2	خیر

مسیر Cloudflare برای فرمت‌های باینری آفیس ترجیح داده می‌شود زیرا Smalot و PhpWord در اسناد دنیای واقعی غیرقابل اعتماد هستند: PDFهای صادر شده از Word که متن بدنه را در یک جریان محتوای بزرگ قرار می‌دهند، PDFهای اسکن شده با یک لایه متنی نازک و فایل‌های DOCX با جداول تو در تو یا فریم‌های متنی، همه تمایل به استخراج ضعیفی دارند. toMarkdown Workers AI مارک‌داون ساختاریافته (تیترها، لیست‌ها، جداول حفظ شده) را برمی‌گرداند که تکه‌تکه‌کننده را بسیار بهتر تغذیه می‌کند.

قیمت‌گذاری: toMarkdown برای همه فرمت‌های بالا رایگان است. فقط تبدیل تصویر به مارک‌داون نورون‌های Workers AI را مصرف می‌کند (ما تصاویر ارسال نمی‌کنیم). زمانی که اعتبارنامه‌های Cloudflare وجود نداشته باشد (مشتریان BYOK OpenAI، نصب‌های تازه)، یا زمانی که فراخوانی Cloudflare شکست می‌خورد، تجزیه‌کننده‌های PHP درون‌پردازشی کار را به دست می‌گیرند تا آپلودهای PDF / DOCX / CSV / TXT / MD هرگز بی‌صدا شکست نخورند.

آپلود صفحات گسترده (.xlsx, .xls, .ods, .odt) به Cloudflare Workers AI نیاز دارند. هیچ بازگشت محلی وجود ندارد. زمانی که این فرمت‌ها در یک فضای کاری بدون CLOUDFLARE_ACCOUNT_ID + CLOUDFLARE_API_TOKEN آپلود می‌شوند، ردیف منبع با status=failed ایجاد می‌شود و برچسب خطا شامل یک راهنمای عملی است: "فرمت‌های صفحه گسترده / OpenDocument به Cloudflare Workers AI نیاز دارند." مدیرانی که نیاز به دریافت Excel در یک نصب BYOK-OpenAI دارند، باید به CSV صادر کنند (تجزیه‌کننده محلی League\Csv آن فرمت را بدون وابستگی خارجی مدیریت می‌کند).

هر تجزیه‌کننده‌ای که اجرا شود، متن حاصل در storage/app/private/uploads/{source_id}/segment-N.txt ذخیره می‌شود. این فایلی است که دکمه پردازش مجدد می‌خواند — برای پردازش مجدد نیازی به آپلود مجدد فایل اصلی ندارید.

تکه‌تکه کردن و جستجوی هوشمند

متن استخراج‌کننده به Chunker می‌رود، یک تقسیم‌کننده بازگشتی که مرزهای معنایی را ترجیح می‌دهد:

1. تقسیم براساس تیترهای مارک‌داون، سپس خطوط خالی (پاراگراف‌ها).
2. بسته‌بندی پاراگراف‌ها تا اندازه هدف (~۲۰۰۰ کاراکتر / ~۵۰۰ توکن).
3. اگر یک پاراگراف بیش از حد بزرگ است، به مرزهای جمله بازگردید.
4. پنجره کاراکتر به‌عنوان آخرین راه حل مطلق.
5. یک همپوشانی کوچک بین تکه‌ها اضافه کنید تا حقایق بین تکه‌ها قابل پیوند باشند.

هر تکه به‌صورت دسته‌ای (پیش‌فرض ۱۰۰ تکه در هر فراخوانی) به بردار تبدیل شده و در ذخیره‌ساز جستجوی هوشمند با فراداده: agent_id، document_id، chunk_id، url، workspace_id، source_id، lang ذخیره می‌شود.

سیاست تلاش مجدد اسکن

هر CrawlPageJob تا ۳ بار با فاصله‌های [30s, 90s, 180s] تلاش مجدد می‌کند. مسیر تلاش مجدد براساس کلاس شکست تقسیم می‌شود:

• محدودیت نرخ (HTTP 429، "too many requests" بالادستی) — با تأخیر ۶۰ ثانیه جدید به صف بازگردانده می‌شود بدون مصرف یک جایگاه تلاش مجدد. هر صفحه گسترش‌یافته در همان فضای کاری معمولاً به همان موج ۴۲۹ برخورد می‌کند؛ انتظار مشترک مفید است.
• شکست دائمی (حل DNS curl / رد اتصال، HTTP 400 / 401 / 403 / 404 / 410 / 451، آدرس بدفرم) — از طریق fail() مسیر کوتاه می‌شود تا ردیف منبع دلیل واقعی را بلافاصله دریافت کند به جای اینکه پشت دو تلاش مجدد دیگر که قطعاً شکست می‌خورند، باقی بماند.
• موقتی (5xx، نوسان شبکه) — تلاش مجدد معمولی با فاصله.
• زمان‌بندی هر وظیفه — ۹۰ ثانیه. failOnTimeout=true به این معنی است که SIGTERM پردازشگر همچنان منبع را با یک خطای قابل خواندن برای مشتری به failed تغییر می‌دهد.

پیام‌های خطای رو به خریدار در لیست منابع از طریق SourceErrorPresenter پالایش می‌شوند — پاکت‌های JSON خام بالادستی (بدنه‌های ۴۰۱ Cloudflare، ردیابی‌های پشته Browserless) به خطوط دوستانه مانند "ما نتوانستیم به این صفحه دسترسی پیدا کنیم" یا "سرویس اسکن در حال حاضر شلوغ است — ما به‌طور خودکار دوباره تلاش خواهیم کرد." بازنویسی می‌شوند. اپراتورها همچنان پیام خام کامل را در نمایش جزئیات می‌بینند.

پردازش مجدد و پیش‌نمایش

از لیست منابع، هر ردیف دارای:

• پردازش مجدد — مسیر اسکن + تکه‌تکه + جستجوی هوشمند را دوباره اجرا می‌کند. برای فایل‌های آپلود شده، پردازش مجدد متن بخش ذخیره‌شده را در storage/app/private/uploads/{source_id}/segment-N.txt می‌خواند — نیازی به آپلود مجدد فایل اصلی نیست. اگر فایل ذخیره‌شده وجود نداشته باشد (آپلودهای قبل از رفع یا پاک شدن دیسک)، رابط کاربری یک راهنمای "آپلود مجدد" نمایش می‌دهد.
• پیش‌نمایش — اسناد استخراج‌شده و نمونه‌ای از تکه‌ها را نشان می‌دهد تا بتوانید استخراج بد را تشخیص دهید (مثلاً نوار ناوبری که متن را آلوده کرده است).
• حذف — منبع، اسناد، تکه‌ها و نقاط جستجوی هوشمند مربوطه را حذف می‌کند.

نوتین و گوگل داکس

هر دو از OAuth استفاده می‌کنند. یک بار از /app/integrations اتصال برقرار کنید؛ توکن در حالت استراحت رمزگذاری می‌شود. پس از اتصال، مودال منبع به شما امکان می‌دهد صفحات یا اسناد را مستقیماً انتخاب کنید.

همگام‌سازی مجدد به‌صورت دستی است (به ازای هر منبع دکمه پردازش مجدد) — ما به‌صورت زمان‌بندی‌شده از نوتین / درایو شما نظرسنجی نمی‌کنیم. اگر صفحه نوتین را تغییر دادید، روی پردازش مجدد آن منبع کلیک کنید.

"دستیار فروش من درباره فایلی که تازه آپلود کردم چیزی نمی‌داند"

Cloudflare Vectorize در پرس‌وجوهای فیلتر شده براساس فراداده، سازگاری نهایی دارد — حتی پس از اینکه upsert کد ۲۰۰-OK برگرداند، یک پرس‌وجوی فیلتر شده با agent_id در برابر آن بردار معمولاً برای ۳۰ تا ۶۰ ثانیه اول ۰ نتیجه برمی‌گرداند در حالی که شاخص فراداده در مناطق لبه پخش می‌شود.

نتیجه عملی: یک فایل تازه آپلود شده بلافاصله به‌عنوان status=indexed در صفحه منابع نشان داده می‌شود، اما دستیار فروش تا زمانی که پنجره پخش بسته نشود، نمی‌تواند به سوالات درباره آن پاسخ دهد. بنر موفقیت آپلود، مدیر را در این مورد یادآوری می‌کند. اگر دستیار فروش هنوز پس از یک دقیقه تکه‌های مربوطه را برنگرداند، پیش‌نمایش منبع را باز کنید تا تأیید کنید متن استخراج‌شده خالی نیست — این یک مشکل سمت تجزیه‌کننده است، نه یک مشکل سمت جستجوی هوشمند.

همین نکته برای اولین آپلود پس از ایجاد یک شاخص Vectorize کلودفلر برای اولین بار نیز صدق می‌کند — خود شاخص حدود ۲ دقیقه تأخیر تأمین قبل از اینکه هر پرس‌وجویی نتایج را برگرداند، حتی پرس‌وجوهای فیلتر نشده، دارد.

ذخیره‌سازی و نگهداری

• Postgres — منابع، اسناد، تکه‌ها (متن + فراداده).
• ذخیره‌ساز جستجوی هوشمند — جستجوهای هوشمند. Cloudflare Vectorize در صورت پیکربندی، در غیر این صورت Qdrant.
• R2 / ذخیره‌سازی اشیاء — مصنوعات اصلی (PDFها، تصاویر) در صورت آپلود.

حذف یک منبع آبشاری می‌شود: اسناد، تکه‌ها و نقاط جستجوی هوشمند همه در یک تراکنش حذف می‌شوند. هیچ حذف نرمی در منابع وجود ندارد.