- ai 10
- rag 8
- python 7
- llm 7
- automation 6
- claude-code 5
- pipeline 4
- evaluation 4
- performance 3
- mqtt 3
- iot 3
- retrieval 2
- qdrant 2
- observability 2
- graph-rag 2
- embedding 2
- devops 2
- architecture 2
- agent-swarm 2
-
一行 /handoff：把 E2E 跑完、截圖、組 HTML、draft email 一路串到 reviewer 信箱
Claude Code skill 怎麼把 E2E 測試、截圖、HTML 報告、Microsoft Graph draft email 五個步驟封裝成一個 slash command；進階版 /walkthrough skill 再加 edge-tts + ffmpeg 直接生出帶字幕的導覽影片。重點不在工具，在「把異質 toolchain 攤平成一個動詞」這個 pattern。
-
DGX Spark + Ray Serve + vLLM：拿 6.7× TTFT、4.2× decode 的 tuning playbook
兩台 NVIDIA DGX Spark (GB10) 撐 30+ agent 串流，Ray Serve LLM 強制一機一模型反而促成簡潔架構；Tier-1 engine_kwargs 拿 6.7× TTFT、2.76× throughput @ c=16，Tier-2 dense→MoE 拿 4.2× decode speedup。
-
Hybrid RAG vs LLM-Wiki：把 Karpathy 的概念拉去做 13 題 A/B 評測
Karpathy 在 2026 年初提出的 LLM Wiki — 讓 LLM 把 raw sources 預先合成成可累積的 markdown 知識庫 — 是個吸引人的概念。把它跟 Hybrid RAG (BM25 + dense + RRF) 在同一個 60 篇知識庫、13 題 A/B 上對照後，硬數字是 accuracy 13/13 vs 12/13、tokens ×9.3、p50 latency ×2.5、LLM calls 2 vs 4。Wiki 的 single failure 不是輸幾個百分點，是跨 tenant 資料污染：把另一個 tenant 的 policy 高 confidence 答給使用者。這篇講三個 failure mode，並提醒在全面採用 LLM-Wiki 之前，先把現有 Hybrid 該有的 reranker / contextual retrieval / tenant filter 補齊。
-
LLM 多任務輸出：把 temporal date-range 解析合併進 intent classifier
Regex 寫死處理「最近 / 下次 / 上週」效果不佳，額外開一次 LLM call 又抬高 latency 與 token 成本；正解是把 date-range 解析與 vagueness 標註合併進既有的 intent classifier output schema — 同一次 LLM call 同時產出 intent label 與 date_range，零增量 round-trip。
-
從 BM25 到 Corrective RAG：一篇 Text + Table benchmark 的精讀筆記
arXiv:2604.01733 在 T²-RAGBench 23,088 筆財務 QA 上 benchmark 九種檢索策略。本文精讀重點：為什麼 Hybrid + Rerank R@5=0.816 領先 Hybrid RRF 0.695、為什麼 BM25 在金融文件上贏過 dense embedding、以及 CRAG 為何意外輸給單純 hybrid fusion。