<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Gradio on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/gradio/</link><description>Recent content in Gradio on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Mon, 17 Aug 2026 09:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/gradio/feed.xml" rel="self" type="application/rss+xml"/><item><title>Hugging Face 實戰（二）：用模型、跑 App、推送自己的模型</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/hugging-face-part2-use-and-push-models-zh/</link><pubDate>Fri, 14 Aug 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/hugging-face-part2-use-and-push-models-zh/</guid><description>大多數人挑模型的方式是看 Trending 第一名，然後 from_pretrained 下去。 正確答案是：先確定 VRAM 上限與授權條款，再從那個交集裡挑排行最高的。 大多數人把 pipeline 包進 Flask 就當作上線了。 正確答案是：那個架構在第 5 個並發請求就會開始排隊，而你需要的是 continuous batching。
上一篇我們把環境架好、跑出第一個結果。這一篇處理三件實際工作：挑對模型、把它變成別人能用的服務、把自己訓練的成果推回 Hub。
一、選模型：從兩百萬個 repo 中挑對那一個 1.1 四道篩選器，順序不能顛倒 2,000,000+ 個模型 │ ▼ ┌──────────────────────────────────────────────┐ │ 篩選 1：任務類型（pipeline_tag） │ → 剩約 5% │ text-generation / embeddings / ASR / … │ └──────────────┬───────────────────────────────┘ ▼ ┌──────────────────────────────────────────────┐ │ 篩選 2：VRAM 是否放得下（硬限制） │ → 剩約 1% │ 參數量 × dtype bytes × 1.2 ≤ 你的 VRAM │ └──────────────┬───────────────────────────────┘ ▼ ┌──────────────────────────────────────────────┐ │ 篩選 3：授權是否允許你的用途（法務限制） │ → 剩約 0.</description></item><item><title>Hugging Face 實戰（五）：端到端實戰 — 打造一個完整的 RAG 客服系統</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/hugging-face-part5-e2e-llm-app-zh/</link><pubDate>Mon, 17 Aug 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/hugging-face-part5-e2e-llm-app-zh/</guid><description>大多數 RAG 教學給你的是 30 行的 demo：切分、嵌入、檢索、丟給 LLM。 正確答案是：那 30 行在真實資料上的正確率大約 55%，而讓它變成 88% 的東西全在那 30 行之外。 這一篇不講概念，直接把一個能上線的系統從頭寫完——包含所有讓它「真的能用」的細節。
這是系列最後一篇。 我們把前四篇的東西組裝成一個完整專案：用 Hugging Face 的模型與工具，做一個繁中的產品客服問答系統。
一、要建的系統 1.1 需求 功能需求 ├─ 回答關於產品文件的問題，並附上引用來源 ├─ 文件外的問題要明確拒答，不能編造 ├─ 支援多輪對話（能理解「那它呢？」這種指代） └─ 串流回應 非功能需求 ├─ P95 首 token 時間 &amp;lt; 800 ms ├─ 支援 30 並發 ├─ 文件更新後 10 分鐘內生效 ├─ 每次回答可追溯（問題、檢索到的片段、生成結果、耗時） └─ 資料不出自己的機房 最後一項排除了所有外部 API，所以整套都用開源模型自架——這正是 Hugging Face 生態的主場。
1.2 完整架構 ┌──────────────────────────────────────────────────────────────────────┐ │ 離線索引管線 │ │ │ │ ┌────────┐ ┌──────────┐ ┌──────────┐ ┌────────────────────┐ │ │ │ 文件源 │──▶│ 解析 │──▶│ 切分 │──▶│ 嵌入 bge-m3 │ │ │ │ md/pdf │ │ 去雜訊 │ │ 語意邊界 │ │ 1024 維 │ │ │ └────────┘ └──────────┘ └──────────┘ └─────────┬──────────┘ │ │ ▼ │ │ ┌──────────────────────────────────┐ │ │ │ FAISS 索引 + BM25 索引 + 中繼資料 │ │ │ └──────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────────┘ │ ════════════════════════════════════════╪══════════════════════════════ ▼ ┌──────────────────────────────────────────────────────────────────────┐ │ 線上查詢管線 │ │ │ │ 使用者提問 │ │ │ │ │ ▼ │ │ ┌──────────────┐ 多輪時把「那它呢」改寫成完整問題 │ │ │ 問題改寫 │ │ │ └──────┬───────┘ │ │ ▼ │ │ ┌─────────────────────────────┐ │ │ │ 混合檢索 │ │ │ │ ┌───────────┐ ┌──────────┐ │ 向量抓語意、BM25 抓精確字串 │ │ │ │ 向量 top20│ │ BM25 top20│ │ RRF 融合 │ │ │ └─────┬─────┘ └────┬─────┘ │ │ │ │ └─────┬──────┘ │ │ │ └──────────────┼──────────────┘ │ │ ▼ │ │ ┌──────────────────────────┐ 把 40 個候選精排成 5 個 │ │ │ Reranker (bge-reranker) │ 這一步通常帶來 +12–20pt 的正確率 │ │ └──────────┬───────────────┘ │ │ ▼ │ │ ┌──────────────────────────┐ 相關度不足 → 直接拒答，不進 LLM │ │ │ 相關度閘門 │ │ │ └──────────┬───────────────┘ │ │ ▼ │ │ ┌──────────────────────────┐ │ │ │ Prompt 組裝（含引用編號） │ │ │ └──────────┬───────────────┘ │ │ ▼ │ │ ┌──────────────────────────┐ │ │ │ vLLM 生成（串流） │ │ │ └──────────┬───────────────┘ │ │ ▼ │ │ ┌──────────────────────────┐ │ │ │ 引用驗證 + 記錄追蹤 │ │ │ └──────────────────────────┘ │ └──────────────────────────────────────────────────────────────────────┘ 1.</description></item></channel></rss>