BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//pretalx.coscup.org//coscup-2026//talk//JXZPYZ
BEGIN:VTIMEZONE
TZID:CST
BEGIN:STANDARD
DTSTART:20000101T000000
RRULE:FREQ=YEARLY;BYMONTH=1
TZNAME:CST
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-coscup-2026-JXZPYZ@pretalx.coscup.org
DTSTART;TZID=CST:20260808T111000
DTEND;TZID=CST:20260808T115500
DESCRIPTION:當大家談到 RAG（Retrieval-Augmented Generation），第
 一個想到的儲存層往往是 Pinecone、Qdrant、Milvus，或是 Post
 greSQL + pgvector。但是在絕大多數企業既有的 stack 裡，MySQL
  才是那個「明明就在那裡、卻幾乎沒有人在 RAG 選型討
 論中提到」的角色。\n    MySQL 9.0 已經正式加入 VECTOR 資
 料型別。那麼問題來了：在不另外搬一座資料庫的前提
 下，到底能不能用 MySQL 把一個可運作的 RAG 系統做出來
 ？做得起來、又能撐多久？\n    本場次以一個從零打造
 、完整開源的 demo 專案為主軸，帶聽眾一步步在 MySQL 9.x 
 上構建 RAG 系統：從 schema 設計、embedding 寫入、Top-K 相似
 度查詢，到串接 LLM 完成問答。途中會深入 VECTOR 型別的
 內部儲存方式、可用函式，以及目前最關鍵的限制——
 社群版尚未提供原生 ANN 索引。\n    接著，我們把同一份
 資料、同一組查詢搬到 PostgreSQL pgvector 上做對照組 benchma
 rk，誠實呈現兩者在 latency、recall、開發體驗、維運成本
 上的差距。最後提出一個務實的選型決策框架：什麼情
 境下「在 MySQL 上做 RAG」是合理的工程選擇，什麼情境下
 應該果斷換工具。\n    所有 demo 程式碼、SQL schema、benchma
 rk 腳本與投影片都會以 Apache-2.0 / CC BY-SA 授權公開於 GitHu
 b，現場聽眾可以即時在自己的環境重現。
DTSTAMP:20260601T185902Z
LOCATION:TR210
SUMMARY:從零打造一個 MySQL-based RAG 系統：VECTOR 型別實戰、工程取捨與 pgvector 對照 - Hank Tom
URL:https://pretalx.coscup.org/coscup-2026/talk/JXZPYZ/
END:VEVENT
END:VCALENDAR