<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Verified Permissions on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/verified-permissions/</link><description>Recent content in Verified Permissions on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Thu, 23 Jul 2026 09:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/verified-permissions/feed.xml" rel="self" type="application/rss+xml"/><item><title>AI System on Native AWS - Part 6 - 企業級多租戶 RAG 平台</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part6-enterprise-multi-tenant-rag-zh/</link><pubDate>Thu, 23 Jul 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part6-enterprise-multi-tenant-rag-zh/</guid><description>大部分 RAG 的 demo 只有一個租戶、一個使用者、一批文件,跑起來很漂亮。一放到企業就爆:A 公司的合約絕不能被 B 公司檢索到、行銷部的人不該問得出財務部的薪資表、而且老闆要知道這個月每個客戶到底燒了你多少 token。 單租戶 RAG 是玩具,多租戶 RAG 才是產品。難點不在「檢索」,而在「檢索之前,先確定這個人有權看到哪些東西」——而且要在毫秒級、要能撐幾百個租戶、還要能把成本拆得清清楚楚。 AWS 原生的解法:用 Verified Permissions(Cedar 政策引擎)在檢索前算出可見範圍、用 metadata filtering 把範圍壓進向量檢索、用語意快取把重複問題的成本歸零、用 tenant tag 把每一塊錢歸因到租戶。 這是進階篇的起點,也是 Part 1 的企業級進化:當 RAG 要賣給一百家公司時,系統長什麼樣。
關於進階篇(Part 6–10) 前五篇(Part 1–5)我們各自蓋了一個能跑的 AI 系統。但「能跑」跟「賣得出去、扛得住稽核、管得動成本」之間,還隔著一整套企業級的考量:多租戶隔離、模型客製與治理、即時風控、資安合規、平台化。進階篇這五篇,把前面的系統往「企業平台」推進:
Part 6(本篇):企業級多租戶 RAG 平台 —— 租戶隔離 + 文件級授權 + 語意快取 Part 7:基礎模型客製化與模型治理 —— Fine-tuning、蒸餾、Model Registry、評估關卡 Part 8:即時串流 ML 與詐欺偵測 —— Kinesis + Managed Flink + Neptune 圖偵測 Part 9:企業 AI 安全、合規與資料治理 —— PrivateLink、KMS、Macie、Lake Formation、SCP Part 10:企業 AI 平台工程 —— 多帳號落地區、LLM Gateway、Service Catalog、FinOps 一樣全程用 AWS CDK(TypeScript / CloudFormation) 描述。</description></item></channel></rss>