<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>OpenSearch Serverless on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/opensearch-serverless/</link><description>Recent content in OpenSearch Serverless 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/opensearch-serverless/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><item><title>AI System on Native AWS - Part 1 - Serverless RAG 智慧客服知識庫</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part1-serverless-rag-chatbot-zh/</link><pubDate>Sat, 18 Jul 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part1-serverless-rag-chatbot-zh/</guid><description>大部分人做企業內部問答機器人:租一台 GPU、裝 LangChain、自己接一個 Pinecone、再寫一堆膠水程式碼,三個月後發現光是「文件更新後要重新 embedding」這件事就沒人想維護。 AWS 原生的作法不一樣:文件丟進 S3,Bedrock Knowledge Bases 自動幫你切塊、嵌入、同步進向量庫;問答時呼叫一個 RetrieveAndGenerate API,連檢索帶生成、還附引用來源,一次搞定。 沒有一台伺服器需要你開機、沒有一個模型需要你自己 host,計費按呼叫次數走,資料永遠不離開你的 AWS 帳號。 這一系列會帶你走過五種「最常見、最能直接落地」的 AWS 原生 AI 系統;這篇 Part 1,我們從所有 AI 應用的起點——RAG 問答——開始。
關於這個系列 「在雲上做 AI」有兩條路。一條是把 AWS 當成一台大型的 Linux 機房:自己開 EC2、自己裝 vLLM、自己管 Kubernetes、自己接開源向量庫。另一條是用 AWS 原生的 managed AI 服務(Bedrock、SageMaker、Textract、Comprehend、Personalize…),把「模型 host、擴縮、容錯」全部外包給雲廠商,你只寫「把這些服務接起來」的黏合邏輯。
這個系列走的是第二條路。原因很簡單:對 90% 的團隊來說,自己 host 模型不是核心競爭力,而是負債。我們會用五篇,各自完整拆解一個最常見的 AWS 原生 AI 系統,每一篇都包含:情境與痛點 → 系統目的 → 系統設計與架構 → CDK(CloudFormation)實作 → 技術選型考量 → 成本 → 延伸與坑。
Part 1(本篇):Serverless RAG 智慧客服知識庫 —— Bedrock Knowledge Bases + OpenSearch Serverless Part 2:智慧文件處理(IDP)管線 —— Textract + Comprehend + Bedrock + Step Functions Part 3:即時個人化推薦系統 —— Kinesis + Feature Store + SageMaker Endpoint Part 4:自主 AI Agent 工具呼叫系統 —— Bedrock Agents + Lambda Action Groups + Guardrails Part 5:生產化 MLOps 與可觀測性 —— SageMaker 部署策略、模型呼叫日誌、成本治理、CDK CI/CD 全系列的基礎設施都用 AWS CDK(TypeScript) 描述,底層產出的就是 CloudFormation。為什麼是 CDK 不是手刻 CloudFormation YAML?</description></item></channel></rss>