🗃️ 一次性將大量的網頁做摘要，方便製作 LLM 外部知識庫 🧠
👉 https://www.coze.com/s/Zs8k6x4DJ/
正如其名，這個助手的主要功能是批次處理大量網頁，為每個網頁生成精簡而全面的摘要。它是我在設計「摘要索引與全文參考方法」時製作的輔助工具。
使用 Batch Webpage Summary Assistant 非常簡單。只需要輸入多行網頁 URL，它就會自動抓取這些網頁的內容，生成摘要，並返回包含 URL 和摘要的 json 輸出。在處理大量網頁資料的場景，這個工具能極大地簡化了摘要索引的知識庫建立過程。
本篇文章除了介紹助手之外，亦會說明如何使用它快速的建立外部網頁知識庫。
本篇文章透過「筆韻智匠 Quill Sage🖋️✨」和 Claude 3.5 Sonnet 聯合創作
嘿，各位開發者和 AI 愛好者們！今天我要聊聊 RAG (Retrieval-Augmented Generation) 技術。相信大家對這個名詞不陌生吧？ RAG 已經成為 AI 應用中不可或缺的一部分，特別是在需要大量精確資訊的場景中。
在開始深入探討之前，我想先邀請大家試試我開發的 C# AI Buddy。這是一個整合了 800 多頁 Microsoft Learn 文件的 C# AI 助手，不僅能回答你的 C# 相關問題，還能提供準確的文件參考連結。有興趣的讀者可以先體驗一下，看看它是如何運用我今天要討論的技術。本文後面會公開它的工作流程喔！
C# AI Buddy
👉 https://www.coze.com/s/Zs8k6Co9K/
回到正題，RAG 技術雖然強大，但在實際應用中也面臨著一些挑戰。首先是「全文索引」做法的問題。當我們直接對大量文本進行索引時，常常會發現檢索結果不夠精準。想像一下，你在海量的文件中查找特定資訊，卻總是找不到最相關的那一篇。找不到正確的參考資料，AI 自然無法做出正確的回答。
另一個棘手的問題是 Chunk 大小的限制。在處理長文本時，我們通常需要將其分割成小塊 (Chunks) 進行處理。但是，Chunk 的大小上限往往會限制我們保留完整上下文的能力。結果就是，我們可能會錯過重要的上下文資訊，導致 AI 的理解不準確或是腦補產生幻覺。
這些挑戰促使我思考：有沒有更好的方法來改善 RAG 技術，既能提高檢索的準確性，又能在有限的空間內保留更多有價值的資訊呢？
接下來，我們就來探討一下「摘要索引與全文參考」這個方法，看看它如何應對這些挑戰，為 RAG 技術帶來新的可能性。
最近從公司接下了一個輔導客戶導入容器化的案子，其中一項任務是幫他們新採購的伺服器安裝容器運行環境。
Dell 主機；系統 RHEL 8.8；無對外網路；安裝「Docker」。
為什麼強調「Docker」......我該不該跟他們說 RHEL 內建 Podman 啊😐
Podman 也沒什麼不好，就只是客戶會撞牆在權限跟權限跟權限而已......還是算了
出發前一天先寫驗收要的手冊，想說
「沒什麼難的，照 Docker 官方手冊裝一裝就完事了~~🥳」
結果真的踩中地雷，於是就有了這篇文章的誕生🤣
寫得很簡略，是給未來的我讀的筆記
看不懂不要問我，我懶得答
此筆記沒有任何「破解」要素
我只是說明如何用你手上的鑰匙把鎖打開，沒有鑰匙的人打不開鎖
在開始以前請確認:
- 你可以在網頁中播放影片
- 影片使用 shaka-packager 技術加密
- 你能取得 License Server 的 Clear Key Response 內容
每次只要遇到 Python 專案，我在運行前一定先看有沒有提供 Dockerfile。
Why?
你有沒有遇過安裝了 Python 2.7, 3.8, 3.9, 3.11，然後新程式只能跑在 3.10。
重點是還不一定能升級，裝好了 Python 3.11 不代表你可以跑 3.8, 3.9, 3.10
的程式！
Python Developer 裝這麼多版本不累嗎😅
我知道你會說 conda，玩 Python 的人不可能沒用過
Anaconda，它用來解決這惱人的依頼問題，讓你方便地換個程式就切換一套運行環境。
這發明很棒，真的，「先有需求」才有供給對吧😏
直到有一天 C 槽被各版本的 Python、各程式專屬的 environment
給佔滿
我最終決定把它們全都砍了，從此以後打死不在本機裝
Python
通通給我到容器🐋裡去吧！
不方便開發?
開發需求推薦 devcontainer
專案做好.devcontainer設定檔 & 一鍵建立 GitHub CodeSpaces
Python 開發體驗一級棒👍
......前提是你懂 Docker
說回今天的主題，Stable Diffusion WebUI 和 Kohya's GUI，這兩套程式都有前人做了容器化。
我過往看過 Dockerfile 後認為「有最佳化的餘地，但沒什麼大問題」並直接使用了一段時間。
前兩週比較有空閒，於是來貢獻貢獻所學，重寫了更好的 Dockerfile。
bmaltais/kohya_ss
已經 PR 回原專案，現在
master branch 上面的 Dockerfile
是我重寫的
AUTOMATIC1111/stable-diffusion-webui
不接受 Dockerfile，我是放在自己的 GitHub，並做了整套的 CI
在這篇文章中，我要分享在 Recorder.moe 專案中，如何從使用肥大的 azure-cli 轉變到使用簡潔的 REST API 來上傳影片到 Azure Blob Storage。你將看到我如何發現 azure-cli 的官方 docker image 體積過大，並且自己動手優化 Dockerfile，最後改變解決方案，成功將 image 降低到只有 36.4 MB。
這是一個關於優化 Dockerfile 和 Azure Blob Storage 上傳流程的實戰故事，希望能對你有所啟發。
對，標題和介紹是 GPT-4 寫的，下面才是正文😉
1/3 下午我收到了三封 email 來自 Cloudflare，警告我 Workers 的用量被耗盡。
每日十萬次在下午兩點被用完？我的用量沒這麼狂，肯定有事情發生了。
元旦假期做了一個新的專案 —— Simple Poll System 簡易投票系統
https://github.com/jim60105/simple-poll-system
我為什麼寫這個呢?
上週薬袋アルマ舉辦
Vtuber 紅白活動，前兩天的會限直播在和大家測試投票系統。當時發現現成的問卷服務都不合用，不是要很多錢就是不即時，而最後用了
Google Form。 雖然 Google Form 是當下最好的選擇，但它不夠客製化，像是直播當下的紅組被顯示為藍色，而白組被顯示為紅色、無法內嵌投票結果在活動網頁上等等。
我就在想，要以這個需求來規劃一個小專案的話我會使用什麼技術實現它。然後就當作練練手...
這是一個以概念驗證和學習為目的而做的專案，目標是建構一個低成本、高流量的即時投票系統。投票只是一種簡單的應用，你可以把它代換為任何使用網頁前後端和資料庫的應用場景。
