🔵 عنوان مقاله
How Anthropic Built a Multi-Agent Research System (16 minute read)
🟢 خلاصه مقاله:
**
Anthropic یک سیستم پژوهشی چندعاملی ساخته که در پرسشهای پیچیده بیش از ۹۰٪ بهتر از روشهای تکعامل عمل میکند. این برتری از اکتشاف پویا، پرامپتهای دقیق و نقشمحور، و لایههای ارزیابیِ سختگیرانه بهدست میآید. در معماری سیستم، یک عامل راهبر چند زیرعاملِ موازی را هدایت میکند و یک راستیسنجِ ارجاعات، ادعاها را با منابع تطبیق میدهد تا خطاها و ادعاهای بیپشتوانه کاهش یابد. در مقابل، بهخاطر اجزای متعدد و مراحل تکراریِ راستیآزمایی، مصرف توکن و هزینهها حدود ۱۵ برابر میشود و پیچیدگی تولیدی و تأخیر نیز بالا میرود؛ بنابراین این رویکرد برای کارهای پژوهشی حساس و دشوار که دقت و قابلیت استناد مهمتر از سرعت و هزینه است مناسبتر است.
#MultiAgentSystems #Anthropic #AIResearch #LLM #PromptEngineering #Evaluation #Scalability #TokenCosts
🟣لینک مقاله:
https://blog.bytebytego.com/p/how-anthropic-built-a-multi-agent?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How Anthropic Built a Multi-Agent Research System (16 minute read)
🟢 خلاصه مقاله:
**
Anthropic یک سیستم پژوهشی چندعاملی ساخته که در پرسشهای پیچیده بیش از ۹۰٪ بهتر از روشهای تکعامل عمل میکند. این برتری از اکتشاف پویا، پرامپتهای دقیق و نقشمحور، و لایههای ارزیابیِ سختگیرانه بهدست میآید. در معماری سیستم، یک عامل راهبر چند زیرعاملِ موازی را هدایت میکند و یک راستیسنجِ ارجاعات، ادعاها را با منابع تطبیق میدهد تا خطاها و ادعاهای بیپشتوانه کاهش یابد. در مقابل، بهخاطر اجزای متعدد و مراحل تکراریِ راستیآزمایی، مصرف توکن و هزینهها حدود ۱۵ برابر میشود و پیچیدگی تولیدی و تأخیر نیز بالا میرود؛ بنابراین این رویکرد برای کارهای پژوهشی حساس و دشوار که دقت و قابلیت استناد مهمتر از سرعت و هزینه است مناسبتر است.
#MultiAgentSystems #Anthropic #AIResearch #LLM #PromptEngineering #Evaluation #Scalability #TokenCosts
🟣لینک مقاله:
https://blog.bytebytego.com/p/how-anthropic-built-a-multi-agent?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Bytebytego
How Anthropic Built a Multi-Agent Research System
In this article, we will understand the architecture of the multi-agent research system that Anthropic built.
🔵 عنوان مقاله
How to Get AI to Deliver Superior ROI, Faster (6 minute read)
🟢 خلاصه مقاله:
** این مقاله نشان میدهد کندی در ROIِ AI معمولاً از خودِ سازمان میآید: دادههای جزیرهای، QA ناکارآمد (مثل تولید garbage tokens و ارزیابیهای ناقص)، انتخاب مدلهای بیشازحد بزرگ و فرهنگی که «بزرگتر یعنی بهتر» را فضیلت میداند. راهحل، Lean AI است: از کوچکترین راهکار مؤثر شروع کنید، مدل متناسب با کار انتخاب کنید و با تکنیکهایی مانند fine‑tuning سبک، LoRA، distillation، quantization، RAG و caching هزینه/کیفیت را بهینه کنید و شاخصهایی مثل هزینه بهازای حل هر تیکت را بسنجید. از آغاز با CFO و ذینفعان روی KPIها، بودجه، ریسک و SLAها همراستا شوید و واحداقتصاد پروژه را قبل از کدنویسی مشخص کنید. QA را جدی بگیرید: ارزیابی چندلایه آفلاین/آنلاین، داده طلایی با rubric شفاف، تست رگرسیون خودکار، و enforce کردن schema برای خروجیهای ساختاریافته. گلوگاههای داده را با data contract، استانداردسازی schema و privacy‑by‑design پیشاپیش رفع کنید. از خود AI برای debugging استفاده کنید: خوشهبندی خطاها، تحلیل لاگ، تولید تست و پایش drift؛ حلقه بازخورد کاربر را به چرخه ارزیابی/آموزش وصل کنید. در اجرا، چرخههای کوتاه با آزمایشهای کوچک، A/B تست، red teaming، runbook و داشبورد هفتگی مشترک میان محصول/فنی/داده/مالی را پیاده کنید. جمعبندی: چابکی، تمرکز بر عملکرد و کیفیت داده، و همراستایی زودهنگام ذینفعان، ROI سریعتر و برتر میدهد—نه صرفاً رفتن سراغ بزرگترین مدل.
#AI #ROI #LeanAI #MLOps #DataQuality #LLM #AIEvaluation #ProductStrategy
🟣لینک مقاله:
https://www.datasciencecentral.com/how-to-get-ai-to-deliver-superior-roi-faster/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How to Get AI to Deliver Superior ROI, Faster (6 minute read)
🟢 خلاصه مقاله:
** این مقاله نشان میدهد کندی در ROIِ AI معمولاً از خودِ سازمان میآید: دادههای جزیرهای، QA ناکارآمد (مثل تولید garbage tokens و ارزیابیهای ناقص)، انتخاب مدلهای بیشازحد بزرگ و فرهنگی که «بزرگتر یعنی بهتر» را فضیلت میداند. راهحل، Lean AI است: از کوچکترین راهکار مؤثر شروع کنید، مدل متناسب با کار انتخاب کنید و با تکنیکهایی مانند fine‑tuning سبک، LoRA، distillation، quantization، RAG و caching هزینه/کیفیت را بهینه کنید و شاخصهایی مثل هزینه بهازای حل هر تیکت را بسنجید. از آغاز با CFO و ذینفعان روی KPIها، بودجه، ریسک و SLAها همراستا شوید و واحداقتصاد پروژه را قبل از کدنویسی مشخص کنید. QA را جدی بگیرید: ارزیابی چندلایه آفلاین/آنلاین، داده طلایی با rubric شفاف، تست رگرسیون خودکار، و enforce کردن schema برای خروجیهای ساختاریافته. گلوگاههای داده را با data contract، استانداردسازی schema و privacy‑by‑design پیشاپیش رفع کنید. از خود AI برای debugging استفاده کنید: خوشهبندی خطاها، تحلیل لاگ، تولید تست و پایش drift؛ حلقه بازخورد کاربر را به چرخه ارزیابی/آموزش وصل کنید. در اجرا، چرخههای کوتاه با آزمایشهای کوچک، A/B تست، red teaming، runbook و داشبورد هفتگی مشترک میان محصول/فنی/داده/مالی را پیاده کنید. جمعبندی: چابکی، تمرکز بر عملکرد و کیفیت داده، و همراستایی زودهنگام ذینفعان، ROI سریعتر و برتر میدهد—نه صرفاً رفتن سراغ بزرگترین مدل.
#AI #ROI #LeanAI #MLOps #DataQuality #LLM #AIEvaluation #ProductStrategy
🟣لینک مقاله:
https://www.datasciencecentral.com/how-to-get-ai-to-deliver-superior-roi-faster/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Data Science Central
How to Get AI to Deliver Superior ROI, Faster
LLM, SLM, TCO, RAG, Agents, BondingAI, xLLM, security, compliance, AI, LLM 2.0
🔵 عنوان مقاله
The Feature We Were Afraid to Talk About (7 minute read)
🟢 خلاصه مقاله:
dltHub با صراحت توضیح میدهد که اتکای کامل به LLM برای ساخت خودکار data scaffold از روی مستندات، در عمل برای محیطهای تولیدی قابل اعتماد نبود. نسخه اول، اسکَفولدها را مستقیم با LLM میساخت و در ظاهر عالی بود، اما خطاهای ظریف و «توهمات» باعث شکست پایپلاینها و اتلاف زمان دیباگ میشد. در v2 رویکرد برعکس شد: ابتدا با پارسرها و اعتبارسنجهای قطعی، حقایق قابل راستیآزمایی (مثل endpointها، schemaها، روشهای احراز هویت و قواعد pagination) استخراج و تثبیت میشوند؛ سپس LLM فقط برای ظرایف معنایی وارد میشود—برای رفع ابهامها، نامگذاری بهتر یا پیشنهاد تبدیلهای سبک—آن هم با ارجاع شفاف به منبع تا قابلیت رهگیری و اصلاح حفظ شود. نتیجه، کاهش خطا و افزایش قابلیت بازتولید و دیباگپذیری است؛ LLM ارزش افزوده میدهد اما موتور تصمیم قطعی نیست. درس کلیدی: در دادههای تولیدی، باید LLM را با ریلهای ایمنی، استخراج قطعی و اعتبارسنجی احاطه کرد، نه اینکه همه چیز را به آن سپرد.
#LLM #DataEngineering #MLOps #AI #ProductionReliability #DeterministicParsing #DataPipelines #dltHub
🟣لینک مقاله:
https://dlthub.com/blog/improving_generation_baseline?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The Feature We Were Afraid to Talk About (7 minute read)
🟢 خلاصه مقاله:
dltHub با صراحت توضیح میدهد که اتکای کامل به LLM برای ساخت خودکار data scaffold از روی مستندات، در عمل برای محیطهای تولیدی قابل اعتماد نبود. نسخه اول، اسکَفولدها را مستقیم با LLM میساخت و در ظاهر عالی بود، اما خطاهای ظریف و «توهمات» باعث شکست پایپلاینها و اتلاف زمان دیباگ میشد. در v2 رویکرد برعکس شد: ابتدا با پارسرها و اعتبارسنجهای قطعی، حقایق قابل راستیآزمایی (مثل endpointها، schemaها، روشهای احراز هویت و قواعد pagination) استخراج و تثبیت میشوند؛ سپس LLM فقط برای ظرایف معنایی وارد میشود—برای رفع ابهامها، نامگذاری بهتر یا پیشنهاد تبدیلهای سبک—آن هم با ارجاع شفاف به منبع تا قابلیت رهگیری و اصلاح حفظ شود. نتیجه، کاهش خطا و افزایش قابلیت بازتولید و دیباگپذیری است؛ LLM ارزش افزوده میدهد اما موتور تصمیم قطعی نیست. درس کلیدی: در دادههای تولیدی، باید LLM را با ریلهای ایمنی، استخراج قطعی و اعتبارسنجی احاطه کرد، نه اینکه همه چیز را به آن سپرد.
#LLM #DataEngineering #MLOps #AI #ProductionReliability #DeterministicParsing #DataPipelines #dltHub
🟣لینک مقاله:
https://dlthub.com/blog/improving_generation_baseline?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Dlthub
The feature we were afraid to talk about
This is the story of how we made our LLM generation workflow superior to starting from raw docs.
🔵 عنوان مقاله
Perplexity's Open-Source Tool to Run Trillion-Parameter Models Without Costly Upgrades (4 minute read)
🟢 خلاصه مقاله:
Perplexity AI با معرفی ابزار متنباز TransferEngine امکان اجرای مدلهای تریلیونپارامتری را روی سختافزارهای متنوع و موجود فراهم کرده است. این سیستم با تکیه بر RDMA ارتباط GPU-to-GPU را در محیطهای ترکیبی AWS و Nvidia بهینه میکند و با دستیابی به 400 Gbps روی ConnectX-7 و AWS EFA، نیاز به ارتقای گرانقیمت را برطرف میسازد و وابستگی به یک فروشنده را کاهش میدهد. TransferEngine برای بارهای کاری LLM طراحی شده و مسیریابی Mixture-of-Experts را کارآمد میکند؛ در نتیجه اجرای مدلهایی مانند DeepSeek V3 و Kimi K2 با تأخیر کم و مقیاسپذیر ممکن میشود. متنباز بودن آن نیز ادغام، توسعه و استفاده در پشتههای موجود را ساده میکند.
#OpenSource #LLM #RDMA #GPU #AWS #Nvidia #MixtureOfExperts #AIInfrastructure
🟣لینک مقاله:
https://www.infoworld.com/article/4085830/perplexitys-open-source-tool-to-run-trillion-parameter-models-without-costly-upgrades-2.html?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Perplexity's Open-Source Tool to Run Trillion-Parameter Models Without Costly Upgrades (4 minute read)
🟢 خلاصه مقاله:
Perplexity AI با معرفی ابزار متنباز TransferEngine امکان اجرای مدلهای تریلیونپارامتری را روی سختافزارهای متنوع و موجود فراهم کرده است. این سیستم با تکیه بر RDMA ارتباط GPU-to-GPU را در محیطهای ترکیبی AWS و Nvidia بهینه میکند و با دستیابی به 400 Gbps روی ConnectX-7 و AWS EFA، نیاز به ارتقای گرانقیمت را برطرف میسازد و وابستگی به یک فروشنده را کاهش میدهد. TransferEngine برای بارهای کاری LLM طراحی شده و مسیریابی Mixture-of-Experts را کارآمد میکند؛ در نتیجه اجرای مدلهایی مانند DeepSeek V3 و Kimi K2 با تأخیر کم و مقیاسپذیر ممکن میشود. متنباز بودن آن نیز ادغام، توسعه و استفاده در پشتههای موجود را ساده میکند.
#OpenSource #LLM #RDMA #GPU #AWS #Nvidia #MixtureOfExperts #AIInfrastructure
🟣لینک مقاله:
https://www.infoworld.com/article/4085830/perplexitys-open-source-tool-to-run-trillion-parameter-models-without-costly-upgrades-2.html?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
InfoWorld
Perplexity’s open-source tool to run trillion-parameter models without costly upgrades
TransferEngine enables GPU-to-GPU communication across AWS and Nvidia hardware, allowing trillion-parameter models to run on older systems.
🔵 عنوان مقاله
The Transactional Graph-Enhanced LLM: A Definitive Guide to Read/Write Chatbots for Relational Data (9 minute read)
🟢 خلاصه مقاله:
این راهنما چارچوبی عملی برای ساخت چتباتهای مبتنی بر LLM ارائه میکند که هم قابلیت خواندن و هم نوشتن روی پایگاههای داده رابطهای سازمانی را دارند، با این ایده که یک Knowledge Graph (KG) بهعنوان لایه میانی و معنایی عمل کند. سه الگوی اصلی معماری معرفی میشود: ۱) KG بهعنوان cache برای خواندن سریع و معنایی، در حالی که عملیات نوشتن در RDB انجام میشود؛ ۲) KG بهعنوان منبع حقیقت برای نمایش دانش دامنه و وضعیت جاری، با همگامسازی گزینشی با سیستمهای رابطهای؛ و ۳) رویکرد ترکیبی الهامگرفته از CQRS که در آن KG مسئول خواندن و لایه معنایی (برای تفسیر نیت، نگاشت موجودیتها و اعتبارسنجی پرسوجو) است و RDB مسئول نوشتن و تراکنشها میباشد.
در الگوی CQRS، KG به LLM کمک میکند تا درخواستهای طبیعی را به پرسوجوهای دقیق (مثلاً SQL) ترجمه و پیش از اجرا اعتبارسنجی کند؛ خواندنها از KG انجام میشود و نوشتنها با حفظ ویژگیهای ACID در RDB صورت میگیرد. برای ایمنی و انطباق، از کنترل دسترسی، اعتبارسنجی dry-run، بررسی طرحواره، پارامتریکسازی پرسوجو، راهکارهای idempotency و برنامههای rollback استفاده میشود. همگامسازی KG و RDB معمولاً مبتنی بر رویداد یا change-data-capture است و نسخهبندی/منشأ داده در KG امکان ممیزی و توضیحپذیری را فراهم میکند. انتخاب بین سه الگو به نسبت بار خواندن/نوشتن، نیازهای یکپارچگی و حکمرانی داده و وضعیت پلتفرمهای موجود بستگی دارد.
#KnowledgeGraph #LLM #CQRS #RelationalData #Chatbots #AIArchitecture #EnterpriseData #GraphAI
🟣لینک مقاله:
https://blog.gopenai.com/the-transactional-graph-enhanced-llm-a-definitive-guide-to-read-write-chatbots-for-relational-data-6e1b280cefee?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The Transactional Graph-Enhanced LLM: A Definitive Guide to Read/Write Chatbots for Relational Data (9 minute read)
🟢 خلاصه مقاله:
این راهنما چارچوبی عملی برای ساخت چتباتهای مبتنی بر LLM ارائه میکند که هم قابلیت خواندن و هم نوشتن روی پایگاههای داده رابطهای سازمانی را دارند، با این ایده که یک Knowledge Graph (KG) بهعنوان لایه میانی و معنایی عمل کند. سه الگوی اصلی معماری معرفی میشود: ۱) KG بهعنوان cache برای خواندن سریع و معنایی، در حالی که عملیات نوشتن در RDB انجام میشود؛ ۲) KG بهعنوان منبع حقیقت برای نمایش دانش دامنه و وضعیت جاری، با همگامسازی گزینشی با سیستمهای رابطهای؛ و ۳) رویکرد ترکیبی الهامگرفته از CQRS که در آن KG مسئول خواندن و لایه معنایی (برای تفسیر نیت، نگاشت موجودیتها و اعتبارسنجی پرسوجو) است و RDB مسئول نوشتن و تراکنشها میباشد.
در الگوی CQRS، KG به LLM کمک میکند تا درخواستهای طبیعی را به پرسوجوهای دقیق (مثلاً SQL) ترجمه و پیش از اجرا اعتبارسنجی کند؛ خواندنها از KG انجام میشود و نوشتنها با حفظ ویژگیهای ACID در RDB صورت میگیرد. برای ایمنی و انطباق، از کنترل دسترسی، اعتبارسنجی dry-run، بررسی طرحواره، پارامتریکسازی پرسوجو، راهکارهای idempotency و برنامههای rollback استفاده میشود. همگامسازی KG و RDB معمولاً مبتنی بر رویداد یا change-data-capture است و نسخهبندی/منشأ داده در KG امکان ممیزی و توضیحپذیری را فراهم میکند. انتخاب بین سه الگو به نسبت بار خواندن/نوشتن، نیازهای یکپارچگی و حکمرانی داده و وضعیت پلتفرمهای موجود بستگی دارد.
#KnowledgeGraph #LLM #CQRS #RelationalData #Chatbots #AIArchitecture #EnterpriseData #GraphAI
🟣لینک مقاله:
https://blog.gopenai.com/the-transactional-graph-enhanced-llm-a-definitive-guide-to-read-write-chatbots-for-relational-data-6e1b280cefee?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
The Transactional Graph-Enhanced LLM: A Definitive Guide to Read/Write Chatbots for Relational Data
for better viewing experience read here
🔵 عنوان مقاله
TOON (GitHub Repo)
🟢 خلاصه مقاله:
TOON یک جایگزین فشرده و خوانا برای JSON است که با حفظ همان دادهها، از قالب جدولی و تورفتگی استفاده میکند تا LLMها آن را راحتتر و دقیقتر پردازش کنند. این روش در آرایههای یکنواخت از اشیاء با تعریف یک بار کلیدها و نمایش ردیفهای مقدار، معمولاً ۳۰ تا ۶۰ درصد توکن کمتری نسبت به JSON مصرف میکند و خطاهای پرانتز/نقلقول را کاهش میدهد. TOON برای خروجیهای ساختیافته، تبادل داده در زنجیره ابزارهای هوش مصنوعی و مجموعهدادههای تکراری مناسب است و بدون از دستدادن معنا، بهطور قابل اعتماد به JSON رفتوبرگشت میشود.
#TOON #JSON #LLM #DataFormat #TokenEfficiency #PromptEngineering #Parsing #OpenSource
🟣لینک مقاله:
https://github.com/toon-format/toon?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
TOON (GitHub Repo)
🟢 خلاصه مقاله:
TOON یک جایگزین فشرده و خوانا برای JSON است که با حفظ همان دادهها، از قالب جدولی و تورفتگی استفاده میکند تا LLMها آن را راحتتر و دقیقتر پردازش کنند. این روش در آرایههای یکنواخت از اشیاء با تعریف یک بار کلیدها و نمایش ردیفهای مقدار، معمولاً ۳۰ تا ۶۰ درصد توکن کمتری نسبت به JSON مصرف میکند و خطاهای پرانتز/نقلقول را کاهش میدهد. TOON برای خروجیهای ساختیافته، تبادل داده در زنجیره ابزارهای هوش مصنوعی و مجموعهدادههای تکراری مناسب است و بدون از دستدادن معنا، بهطور قابل اعتماد به JSON رفتوبرگشت میشود.
#TOON #JSON #LLM #DataFormat #TokenEfficiency #PromptEngineering #Parsing #OpenSource
🟣لینک مقاله:
https://github.com/toon-format/toon?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - toon-format/toon: 🎒 Token-Oriented Object Notation (TOON) – compact, human-readable serialization of JSON data for LLM…
🎒 Token-Oriented Object Notation (TOON) – compact, human-readable serialization of JSON data for LLM prompts. TypeScript SDK, CLI, benchmarks. - toon-format/toon
🔵 عنوان مقاله
From Text to Token: How Tokenization Pipelines Work
🟢 خلاصه مقاله:
** این مطلب در دو بخش به نکات کاربردی میپردازد. در بخش اول، «From Text to Token: How Tokenization Pipelines Work» به قلم James Blackwood-Sewell توضیح میدهد که چگونه متن خام طی مراحلی مانند نرمالسازی، پیشتوکنیزهکردن و بهکارگیری الگوریتمهای زیرواژهای مثل BPE، WordPiece و Unigram به توکن تبدیل میشود. نکاتی مانند ساخت واژگان، استفاده از توکنهای ویژه (PAD، BOS/EOS، CLS/SEP)، مدیریت نویسههای ناشناخته، حفظ آفستها، و چالشهای چندزبانه و ایموجیها مطرح میشود. همچنین بر ملاحظات مهندسی مانند تکهتکهکردن متنهای بلند، اسلایدینگ ویندو، تفاوت نیازهای آموزش و استنتاج، و بهینهسازی عملکرد با ابزارهایی مانند Hugging Face Tokenizers و SentencePiece تأکید میشود؛ چرا که تعداد توکنها مستقیماً بر هزینه و تأخیر سامانههای LLM اثر میگذارد.
در بخش دوم، «Understanding and Setting Postgres JDBC Fetch Size» نوشته Shane Borden توضیح میدهد که رفتار پیشفرض Postgres JDBC ممکن است برای نتایج بزرگ حافظه را پر کند و چگونه با فعالکردن سرور-ساید کرسرها و تنظیم setFetchSize (یا defaultRowFetchSize) میتوان نتایج را بهصورت batched و استریمشده دریافت کرد. به ارتباط این تنظیم با autocommit، بازههای پیشنهادی برای اندازه batch، موازنه بین تعداد رفتوبرگشت شبکه و مصرف حافظه، و نکات عملی مانند بستن بهموقع ResultSet/Statement و هماهنگی با تنظیمات ORM (مثلاً hibernate.jdbc.fetch_size) پرداخته میشود. جمعبندی این است که کنار بهینهسازی fetch size، طراحی کوئری و ایندکس مناسب و پروفایلکردن حافظه و زمان، برای پایایی و کارایی ضروری است.
#Tokenization #NLP #Postgres #JDBC #PerformanceTuning #DataEngineering #LLM #Database
🟣لینک مقاله:
https://postgresweekly.com/link/175726/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
From Text to Token: How Tokenization Pipelines Work
🟢 خلاصه مقاله:
** این مطلب در دو بخش به نکات کاربردی میپردازد. در بخش اول، «From Text to Token: How Tokenization Pipelines Work» به قلم James Blackwood-Sewell توضیح میدهد که چگونه متن خام طی مراحلی مانند نرمالسازی، پیشتوکنیزهکردن و بهکارگیری الگوریتمهای زیرواژهای مثل BPE، WordPiece و Unigram به توکن تبدیل میشود. نکاتی مانند ساخت واژگان، استفاده از توکنهای ویژه (PAD، BOS/EOS، CLS/SEP)، مدیریت نویسههای ناشناخته، حفظ آفستها، و چالشهای چندزبانه و ایموجیها مطرح میشود. همچنین بر ملاحظات مهندسی مانند تکهتکهکردن متنهای بلند، اسلایدینگ ویندو، تفاوت نیازهای آموزش و استنتاج، و بهینهسازی عملکرد با ابزارهایی مانند Hugging Face Tokenizers و SentencePiece تأکید میشود؛ چرا که تعداد توکنها مستقیماً بر هزینه و تأخیر سامانههای LLM اثر میگذارد.
در بخش دوم، «Understanding and Setting Postgres JDBC Fetch Size» نوشته Shane Borden توضیح میدهد که رفتار پیشفرض Postgres JDBC ممکن است برای نتایج بزرگ حافظه را پر کند و چگونه با فعالکردن سرور-ساید کرسرها و تنظیم setFetchSize (یا defaultRowFetchSize) میتوان نتایج را بهصورت batched و استریمشده دریافت کرد. به ارتباط این تنظیم با autocommit، بازههای پیشنهادی برای اندازه batch، موازنه بین تعداد رفتوبرگشت شبکه و مصرف حافظه، و نکات عملی مانند بستن بهموقع ResultSet/Statement و هماهنگی با تنظیمات ORM (مثلاً hibernate.jdbc.fetch_size) پرداخته میشود. جمعبندی این است که کنار بهینهسازی fetch size، طراحی کوئری و ایندکس مناسب و پروفایلکردن حافظه و زمان، برای پایایی و کارایی ضروری است.
#Tokenization #NLP #Postgres #JDBC #PerformanceTuning #DataEngineering #LLM #Database
🟣لینک مقاله:
https://postgresweekly.com/link/175726/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Paradedb
From Text to Token: How Tokenization Pipelines Work
Understanding how search engines transform text into tokens through character filtering, tokenization, stemming, and stopword removal.