1. ภาพรวม
ในความเร่งรีบที่จะสร้างแอปพลิเคชัน GenAI เรามักจะลืมคอมโพเนนต์ที่สำคัญที่สุด นั่นคือความปลอดภัย
ลองนึกภาพการสร้างแชทบ็อต HR คุณต้องการให้แชทบ็อตตอบคำถามต่างๆ เช่น "เงินเดือนของฉันคือเท่าไร" หรือ "ทีมของฉันมีผลงานเป็นอย่างไร"
- หาก Alice (พนักงานทั่วไป) ถาม แชทบ็อตควรแสดงข้อมูลของ Alice เท่านั้น
- หาก Bob (ผู้จัดการ) ถาม แชทบ็อตควรแสดงข้อมูลของทีม Bob
ปัญหา
สถาปัตยกรรม RAG (Retrieval Augmented Generation) ส่วนใหญ่พยายามจัดการเรื่องนี้ใน ชั้นแอปพลิเคชัน โดยจะกรอง Chunk หลังจาก ดึงข้อมูลมาแล้ว หรืออาศัยให้ LLM "ประพฤติตัวดี" ซึ่งเป็นวิธีที่ไม่มั่นคง หากตรรกะของแอปผิดพลาด ข้อมูลก็จะรั่วไหล
โซลูชัน
ผลักดันความปลอดภัยลงไปที่ชั้นฐานข้อมูล การใช้ PostgreSQL Row-Level Security (RLS) ใน AlloyDB จะช่วยให้มั่นใจได้ว่าฐานข้อมูลจะ ปฏิเสธที่จะส่งคืนข้อมูล ที่ผู้ใช้ไม่ได้รับอนุญาตให้ดู ไม่ว่า AI จะขออะไรก็ตาม
ในคู่มือนี้ เราจะสร้าง "ห้องนิรภัยส่วนตัว": ผู้ช่วย HR ที่ปลอดภัยซึ่งจะเปลี่ยนคำตอบแบบไดนามิกตามผู้ที่เข้าสู่ระบบ
สถาปัตยกรรม
เราจะไม่สร้างตรรกะการให้สิทธิ์ที่ซับซ้อนใน Python แต่จะใช้เอนจินฐานข้อมูลเอง
- อินเทอร์เฟซ: แอป Streamlit อย่างง่ายที่จำลองการเข้าสู่ระบบ
- สมอง: AlloyDB AI (เข้ากันได้กับ PostgreSQL)
- กลไก: เราตั้งค่าตัวแปรเซสชัน (
app.active_user) ที่จุดเริ่มต้นของทุกธุรกรรม นโยบายฐานข้อมูลจะตรวจสอบตารางuser_roles(ทำหน้าที่เป็นผู้ให้บริการข้อมูลประจำตัว) โดยอัตโนมัติเพื่อกรองแถว
สิ่งที่คุณจะได้สร้าง
แอปพลิเคชันผู้ช่วย HR ที่ปลอดภัย คุณจะติดตั้งใช้งาน Row-Level Security (RLS) ในเอนจินฐานข้อมูล AlloyDB โดยตรงแทนที่จะอาศัยตรรกะของแอปพลิเคชันเพื่อกรองข้อมูลที่ละเอียดอ่อน ซึ่งจะช่วยให้มั่นใจได้ว่าแม้โมเดล AI จะ "หลอน" หรือพยายามเข้าถึงข้อมูลที่ไม่ได้รับอนุญาต ฐานข้อมูลก็จะปฏิเสธที่จะส่งคืนข้อมูลดังกล่าว
สิ่งที่คุณจะได้เรียนรู้
คุณจะได้เรียนรู้สิ่งต่อไปนี้
- วิธีออกแบบสคีมาสำหรับ RLS (แยกข้อมูลกับข้อมูลประจำตัว)
- วิธีเขียนนโยบาย PostgreSQL (
CREATE POLICY) - วิธีข้ามข้อยกเว้น "เจ้าของตาราง" โดยใช้
FORCE ROW LEVEL SECURITY - วิธีสร้างแอป Python ที่ทำการ "สลับบริบท" ให้ผู้ใช้
ข้อกำหนด
2. ก่อนเริ่มต้น
สร้างโปรเจ็กต์
- ใน คอนโซล Google Cloud ในหน้าตัวเลือกโปรเจ็กต์ ให้เลือกหรือสร้าง โปรเจ็กต์ Google Cloud
- ตรวจสอบว่าได้เปิดใช้การเรียกเก็บเงินสำหรับโปรเจ็กต์ที่อยู่ในระบบคลาวด์แล้ว ดูวิธีตรวจสอบว่าได้เปิดใช้การเรียกเก็บเงินในโปรเจ็กต์ .
- คุณจะใช้ Cloud Shell ซึ่งเป็นสภาพแวดล้อมบรรทัดคำสั่งที่ทำงานใน Google Cloud คลิกเปิดใช้งาน Cloud Shell ที่ด้านบนของคอนโซล Google Cloud
- เมื่อเชื่อมต่อกับ Cloud Shell แล้ว ให้ตรวจสอบว่าคุณได้รับการตรวจสอบสิทธิ์แล้วและโปรเจ็กต์ตั้งค่าเป็นรหัสโปรเจ็กต์ของคุณโดยใช้คำสั่งต่อไปนี้
gcloud auth list
- เรียกใช้คำสั่งต่อไปนี้ใน Cloud Shell เพื่อยืนยันว่าคำสั่ง gcloud รู้จักโปรเจ็กต์ของคุณ
gcloud config list project
- หากไม่ได้ตั้งค่าโปรเจ็กต์ ให้ใช้คำสั่งต่อไปนี้เพื่อตั้งค่า
gcloud config set project <YOUR_PROJECT_ID>
- เปิดใช้ API ที่จำเป็น โดยทำตาม ลิงก์ และเปิดใช้ API
หรือคุณจะใช้คำสั่ง gcloud สำหรับการดำเนินการนี้ก็ได้ โปรดดู เอกสารประกอบ สำหรับคำสั่ง gcloud และการใช้งาน
gcloud services enable \
alloydb.googleapis.com \
compute.googleapis.com \
cloudresourcemanager.googleapis.com \
servicenetworking.googleapis.com \
aiplatform.googleapis.com
ข้อควรระวังและการแก้ปัญหา
อาการ "โปรเจ็กต์ผี" | คุณเรียกใช้ |
การเรียกเก็บเงิน ที่ขวางทาง | คุณเปิดใช้โปรเจ็กต์แล้ว แต่ลืมบัญชีสำหรับการเรียกเก็บเงิน AlloyDB เป็นเอนจินประสิทธิภาพสูง ซึ่งจะไม่เริ่มทำงานหาก "ถังน้ำมัน" (การเรียกเก็บเงิน) ว่างเปล่า |
ความล่าช้าในการเผยแพร่ API | คุณคลิก "เปิดใช้ API" แต่บรรทัดคำสั่งยังคงแสดง |
โควต้า ที่เป็นอุปสรรค | หากใช้บัญชีทดลองใช้ใหม่ คุณอาจพบโควต้าของภูมิภาคสำหรับอินสแตนซ์ AlloyDB หาก |
3. การตั้งค่าฐานข้อมูล
ในแล็บนี้ เราจะใช้ AlloyDB เป็นฐานข้อมูลสำหรับข้อมูลทดสอบ โดยจะใช้ คลัสเตอร์ เพื่อเก็บทรัพยากรทั้งหมด เช่น ฐานข้อมูลและบันทึก แต่ละคลัสเตอร์มี อินสแตนซ์หลัก ที่ให้จุดเข้าใช้งานข้อมูล ตารางจะเก็บข้อมูลจริง
มาสร้างคลัสเตอร์ อินสแตนซ์ และตาราง AlloyDB ที่จะโหลดชุดข้อมูลทดสอบกัน
- คลิกปุ่มหรือคัดลอกลิงก์ด้านล่างไปยังเบราว์เซอร์ที่คุณเข้าสู่ระบบด้วยผู้ใช้คอนโซล Google Cloud
- เมื่อขั้นตอนนี้เสร็จสมบูรณ์แล้ว ระบบจะโคลนที่เก็บไปยังโปรแกรมแก้ไข Cloud Shell ในเครื่องของคุณ และคุณจะเรียกใช้คำสั่งด้านล่างได้จากโฟลเดอร์โปรเจ็กต์ (โปรดตรวจสอบว่าคุณอยู่ในไดเรกทอรีโปรเจ็กต์)
sh run.sh
- ตอนนี้ให้ใช้ UI (คลิกลิงก์ในเทอร์มินัลหรือคลิกลิงก์ "แสดงตัวอย่างบนเว็บ" ในเทอร์มินัล)
- ป้อนรายละเอียดสำหรับรหัสโปรเจ็กต์ ชื่อคลัสเตอร์ และชื่ออินสแตนซ์เพื่อเริ่มต้น
- ไปชงกาแฟสักแก้วระหว่างที่บันทึกเลื่อนขึ้นมา และคุณสามารถอ่านเกี่ยวกับวิธีที่ระบบดำเนินการนี้เบื้องหลังได้ที่นี่ ซึ่งอาจใช้เวลาประมาณ 10-15 นาที
ข้อควรระวังและการแก้ปัญหา
ปัญหาเรื่อง "ความอดทน" | คลัสเตอร์ฐานข้อมูลเป็นโครงสร้างพื้นฐานขนาดใหญ่ หากคุณรีเฟรชหน้าหรือปิดเซสชัน Cloud Shell เนื่องจาก "ดูเหมือนว่าระบบจะค้าง" คุณอาจได้อินสแตนซ์ "ผี" ที่มีการจัดสรรบางส่วนและลบไม่ได้หากไม่มีการแทรกแซงด้วยตนเอง |
ภูมิภาคไม่ตรงกัน | หากคุณเปิดใช้ API ใน |
คลัสเตอร์ซอมบี้ | หากก่อนหน้านี้คุณใช้ชื่อเดียวกันสำหรับคลัสเตอร์และไม่ได้ลบคลัสเตอร์นั้น สคริปต์อาจแจ้งว่าชื่อคลัสเตอร์มีอยู่แล้ว ชื่อคลัสเตอร์ต้องไม่ซ้ำกันภายในโปรเจ็กต์ |
Cloud Shell หมดเวลา | หากคุณพักดื่มกาแฟนาน 30 นาที Cloud Shell อาจเข้าสู่โหมดสลีปและยกเลิกการเชื่อมต่อกระบวนการ |
4. การจัดสรรสคีมา
ในขั้นตอนนี้ เราจะพูดถึงสิ่งต่อไปนี้
ขั้นตอนโดยละเอียดมีดังนี้
เมื่อคลัสเตอร์และอินสแตนซ์ AlloyDB ทำงานแล้ว ให้ไปที่โปรแกรมแก้ไข SQL ของ AlloyDB Studio เพื่อเปิดใช้ส่วนขยาย AI และจัดสรรสคีมา
คุณอาจต้องรอให้อินสแตนซ์สร้างเสร็จ เมื่อสร้างเสร็จแล้ว ให้ลงชื่อเข้าใช้ AlloyDB โดยใช้ข้อมูลเข้าสู่ระบบที่คุณสร้างขึ้นเมื่อสร้างคลัสเตอร์ ใช้ข้อมูลต่อไปนี้เพื่อตรวจสอบสิทธิ์กับ PostgreSQL
- ชื่อผู้ใช้: "
postgres" - ฐานข้อมูล: "
postgres" - รหัสผ่าน: "
alloydb" (หรือรหัสผ่านที่คุณตั้งค่าไว้ตอนสร้าง)
เมื่อตรวจสอบสิทธิ์เข้าสู่ AlloyDB Studio สำเร็จแล้ว ให้ป้อนคำสั่ง SQL ในโปรแกรมแก้ไข คุณสามารถเพิ่มหน้าต่างโปรแกรมแก้ไขหลายหน้าต่างได้โดยใช้เครื่องหมายบวกทางด้านขวาของหน้าต่างสุดท้าย
คุณจะป้อนคำสั่งสำหรับ AlloyDB ในหน้าต่างโปรแกรมแก้ไข โดยใช้ตัวเลือกเรียกใช้ จัดรูปแบบ และล้างตามความจำเป็น
สร้างตาราง
เราต้องใช้ 2 ตาราง ได้แก่ ตารางหนึ่งสำหรับข้อมูลที่ละเอียดอ่อน (พนักงาน) และอีกตารางหนึ่งสำหรับกฎข้อมูลประจำตัว (user_roles) การแยกตารางทั้งสองออกจากกันเป็นสิ่งสำคัญเพื่อหลีกเลี่ยงข้อผิดพลาด "การเรียกซ้ำไม่สิ้นสุด" ในนโยบาย
คุณสามารถสร้างตารางโดยใช้คำสั่ง DDL ด้านล่างใน AlloyDB Studio
-- 1. Create User Roles (The Identity Provider)
CREATE TABLE user_roles (
username TEXT PRIMARY KEY,
role TEXT -- 'employee', 'manager', 'admin'
);
INSERT INTO user_roles (username, role) VALUES
('Alice', 'employee'),
('Bob', 'manager'),
('Charlie', 'employee');
-- 2. Create the Data Table
CREATE TABLE employees (
id SERIAL PRIMARY KEY,
name TEXT,
salary INTEGER,
performance_review TEXT
);
INSERT INTO employees (name, salary, performance_review) VALUES
('Alice', 80000, 'Alice meets expectations but needs to improve punctuality.'),
('Bob', 120000, 'Bob is a strong leader. Team morale is high.'),
('Charlie', 85000, 'Charlie exceeds expectations. Ready for promotion.');
ข้อควรระวังและการแก้ปัญหา
ตรวจพบการเรียกซ้ำไม่สิ้นสุดขณะกำหนดบทบาทภายในตารางพนักงาน | สาเหตุที่ล้มเหลว: หากนโยบายระบุว่า "ตรวจสอบตารางพนักงานเพื่อดูว่าฉันเป็นผู้จัดการหรือไม่" ฐานข้อมูลจะต้องค้นหาตารางเพื่อตรวจสอบนโยบาย ซึ่งจะทริกเกอร์นโยบายอีกครั้ง ผลลัพธ์: ตรวจพบการเรียกซ้ำไม่สิ้นสุดการแก้ไข: แยกตารางการค้นหา (user_roles) ไว้เสมอ หรือใช้ผู้ใช้ฐานข้อมูลจริงสำหรับบทบาท |
ยืนยันข้อมูล
SELECT count(*) FROM employees;
-- Output: 3
5. เปิดใช้และบังคับใช้การรักษาความปลอดภัย
ตอนนี้เราจะเปิดใช้การป้องกัน นอกจากนี้ เราจะสร้าง "ผู้ใช้แอป" ทั่วไปที่โค้ด Python จะใช้เพื่อเชื่อมต่อ
เรียกใช้คำสั่ง SQL ด้านล่างจากโปรแกรมแก้ไขการค้นหา AlloyDB
-- 1. Activate RLS
ALTER TABLE employees ENABLE ROW LEVEL SECURITY;
-- 2. CRITICAL: Force RLS for Table Owners
ALTER TABLE employees FORCE ROW LEVEL SECURITY;
-- 3. Create the Application User
DO
$do$
BEGIN
IF NOT EXISTS (SELECT FROM pg_catalog.pg_roles WHERE rolname = 'app_user') THEN
CREATE ROLE app_user LOGIN PASSWORD 'password';
END IF;
END
$do$;
-- 4. Grant Access
GRANT SELECT ON employees TO app_user;
GRANT SELECT ON user_roles TO app_user;
ข้อควรระวังและการแก้ปัญหา
ทดสอบในฐานะ postgres (ผู้ใช้ระดับสูง) และเห็นข้อมูลทั้งหมด | สาเหตุที่ล้มเหลว: โดยค่าเริ่มต้น RLS จะไม่ใช้กับเจ้าของตารางหรือผู้ใช้ระดับสูง เนื่องจากผู้ใช้เหล่านี้จะข้ามผ่านนโยบายทั้งหมดการแก้ปัญหา: หากนโยบายดูเหมือน "ใช้งานไม่ได้" (อนุญาตทุกอย่าง) ให้ตรวจสอบว่าคุณเข้าสู่ระบบในฐานะ |
6. สร้างนโยบายการเข้าถึง
เราจะกำหนดกฎ 2 ข้อโดยใช้ตัวแปรเซสชัน (app.active_user) ซึ่งเราจะตั้งค่าจากโค้ดของแอปพลิเคชันในภายหลัง
เรียกใช้คำสั่ง SQL ด้านล่างจากโปรแกรมแก้ไขการค้นหา AlloyDB
-- Policy 1: Self-View
-- Users can see rows where their name matches the session variable
CREATE POLICY "view_own_data" ON employees
FOR SELECT
USING (name = current_setting('app.active_user', true));
-- Policy 2: Manager-View
-- Managers can see ALL rows.
CREATE POLICY "manager_view_all" ON employees
FOR SELECT
USING (
EXISTS (
SELECT 1 FROM user_roles
WHERE username = current_setting('app.active_user', true)
AND role = 'manager'
)
);
ข้อควรระวังและการแก้ปัญหา
ใช้ current_user แทน app.active_user | ปัญหา: current_user เป็นคีย์เวิร์ด SQL ที่สงวนไว้ซึ่งจะแสดงผลบทบาทฐานข้อมูล (เช่น app_user) เราต้องการผู้ใช้แอปพลิเคชัน (เช่น Alice)การแก้ไข: ใช้เนมสเปซที่กำหนดเองเสมอ เช่น app.variable_name. |
ลืมพารามิเตอร์ | ปัญหา: หากไม่ได้ตั้งค่าตัวแปร การค้นหาจะหยุดทำงานพร้อมข้อผิดพลาดการแก้ไข: current_setting('...', true) จะแสดงผล NULL แทนที่จะหยุดทำงาน ซึ่งจะส่งผลให้ไม่มีแถวส่งคืนอย่างปลอดภัย |
7. สร้างแอป "กิ้งก่า"
เราจะใช้ Python และ Streamlit เพื่อจำลองตรรกะของแอปพลิเคชัน
เปิดเทอร์มินัล Cloud Shell ในโหมดโปรแกรมแก้ไข แล้วไปที่โฟลเดอร์รากหรือไดเรกทอรีที่คุณต้องการสร้างแอปพลิเคชันนี้ สร้างโฟลเดอร์ใหม่
1. ติดตั้งทรัพยากร Dependency:
เรียกใช้คำสั่งต่อไปนี้ในเทอร์มินัล Cloud Shell จากภายในไดเรกทอรีโปรเจ็กต์ใหม่:
pip install streamlit psycopg2-binary
2. สร้าง app.py:
สร้างไฟล์ใหม่ชื่อ app.py แล้วคัดลอกเนื้อหาจาก ไฟล์ที่เก็บ
import streamlit as st
import psycopg2
# CONFIGURATION (Replace with your IP)
DB_HOST = "10.x.x.x"
DB_NAME = "postgres"
DB_USER = "postgres"
DB_PASS = "alloydb"
def get_db_connection():
return psycopg2.connect(
host=DB_HOST, database=DB_NAME, user=DB_USER, password=DB_PASS
)
def query_database(user_name):
conn = get_db_connection()
try:
with conn.cursor() as cur:
# THE SECURITY HANDSHAKE
# We tell the database: "For this transaction, I am acting as..."
cur.execute(f"SET app.active_user = '{user_name}';")
# THE BLIND QUERY
# We ask for EVERYTHING. The database silently filters it.
cur.execute("SELECT name, role, salary, performance_review FROM employees;")
return cur.fetchall()
finally:
conn.close()
# UI
st.title("🛡️ The Private Vault")
user = st.sidebar.radio("Act as User:", ["Alice", "Bob", "Charlie", "Eve"])
if st.button("Access Data"):
results = query_database(user)
if not results:
st.error("🚫 Access Denied.")
else:
st.success(f"Viewing data as {user}")
for row in results:
st.write(row)
3. เรียกใช้แอป:
เรียกใช้คำสั่งต่อไปนี้ในเทอร์มินัล Cloud Shell จากภายในไดเรกทอรีโปรเจ็กต์ใหม่:
streamlit run app.py --server.port 8080 --server.enableCORS false
ข้อควรระวังและการแก้ปัญหา
การจัดกลุ่มการเชื่อมต่อ | ความเสี่ยง: หากคุณใช้การจัดกลุ่มการเชื่อมต่อ ตัวแปรเซสชัน SET app.active_user อาจยังคงอยู่ในการเชื่อมต่อและ "รั่วไหล" ไปยังผู้ใช้รายถัดไปที่ใช้การเชื่อมต่อนั้นการแก้ไข:ในเวอร์ชันที่ใช้งานจริง ให้ใช้ RESET app.active_user หรือ DISCARD ALL เสมอเมื่อส่งคืนการเชื่อมต่อไปยังกลุ่ม |
หน้าจอว่างเปล่าใน Cloud Shell | การแก้ไข: ใช้ปุ่ม "แสดงตัวอย่างเว็บ" บนพอร์ต 8080 อย่าคลิกลิงก์ localhost ในเทอร์มินัล |
8. ยืนยัน Zero Trust
ลองใช้แอปเพื่อให้แน่ใจว่าได้ติดตั้งใช้งาน Zero Trust แล้ว
เลือก "Alice": Alice ควรเห็น 1 แถว (ตัวเอง)
เลือก "Bob": Bob ควรเห็น 3 แถว (ทุกคน)
เหตุใดเรื่องนี้จึงมีความสำคัญต่อ AI Agent
ลองนึกภาพการเชื่อมต่อโมเดลกับฐานข้อมูลนี้ หากผู้ใช้ถามโมเดลว่า "สรุปการประเมินประสิทธิภาพทั้งหมด" โมเดลจะสร้าง SELECT performance_review FROM employees
- หากไม่มี RLS: โมเดลจะดึงข้อมูลการประเมินส่วนตัวของทุกคนและรั่วไหลไปยัง Alice
- หากมี RLS: โมเดลจะเรียกใช้การค้นหาแบบเดียวกันทุกประการ แต่ฐานข้อมูลจะแสดงผลการประเมินของ Alice เท่านั้น
นี่คือ AI แบบ Zero Trust คุณไม่เชื่อใจโมเดลในการกรองข้อมูล แต่บังคับให้ฐานข้อมูลซ่อนข้อมูล
นำไปใช้ในเวอร์ชันที่ใช้งานจริง
สถาปัตยกรรมที่แสดงที่นี่เป็นระดับที่ใช้งานจริงได้ แต่การติดตั้งใช้งานเฉพาะเจาะจงนั้นได้รับการทำให้ง่ายขึ้นเพื่อการเรียนรู้ หากต้องการติดตั้งใช้งานอย่างปลอดภัยในสภาพแวดล้อมขององค์กรในโลกแห่งความเป็นจริง คุณควรติดตั้งใช้งานการปรับปรุงต่อไปนี้
- การตรวจสอบสิทธิ์จริง: แทนที่เมนูแบบเลื่อนลง "ตัวสลับข้อมูลประจำตัว" ด้วยผู้ให้บริการข้อมูลประจำตัว (IDP) ที่มีประสิทธิภาพ เช่น Google Identity Platform, Okta หรือ Auth0 แอปพลิเคชันควรยืนยันโทเค็นของผู้ใช้และแยกข้อมูลประจำตัวของผู้ใช้อย่างปลอดภัยก่อนที่จะตั้งค่าตัวแปรเซสชันฐานข้อมูล เพื่อให้มั่นใจว่าผู้ใช้จะปลอมข้อมูลประจำตัวไม่ได้
- ความปลอดภัยของการจัดกลุ่มการเชื่อมต่อ: เมื่อใช้การจัดกลุ่มการเชื่อมต่อ ตัวแปรเซสชันอาจยังคงอยู่ในการเชื่อมต่อคำขอของผู้ใช้ที่แตกต่างกันหากจัดการไม่ถูกต้อง ตรวจสอบว่าแอปพลิเคชันรีเซ็ตตัวแปรเซสชัน (เช่น RESET app.active_user) หรือล้างสถานะการเชื่อมต่อเมื่อส่งคืนการเชื่อมต่อไปยังกลุ่ม เพื่อป้องกันการรั่วไหลของข้อมูลระหว่างผู้ใช้
- การจัดการข้อมูลลับ: การฮาร์ดโค้ดข้อมูลเข้าสู่ระบบฐานข้อมูลเป็นความเสี่ยงด้านความปลอดภัย ใช้บริการจัดการข้อมูลลับโดยเฉพาะ เช่น Google Secret Manager เพื่อจัดเก็บและดึงรหัสผ่านและสตริงการเชื่อมต่อฐานข้อมูลอย่างปลอดภัยในรันไทม์
9. ล้างข้อมูล
เมื่อทำแล็บนี้เสร็จแล้ว อย่าลืมลบคลัสเตอร์และอินสแตนซ์ AlloyDB
ระบบควรล้างคลัสเตอร์พร้อมกับอินสแตนซ์
10. ขอแสดงความยินดี
ขอแสดงความยินดี คุณผลักดันความปลอดภัยลงไปที่ชั้นข้อมูลได้สำเร็จแล้ว แม้ว่าโค้ด Python จะมีข้อบกพร่องที่พยายาม print(all_salaries) ฐานข้อมูลก็จะแสดงผลค่าว่างให้ Alice
ขั้นตอนถัดไป
- ลองใช้กับชุดข้อมูลของคุณเอง
- สำรวจเอก0}เอกสารประกอบของ AlloyDB AI
- ดูเวิร์กช็อปเพิ่มเติมได้ในเว็บไซต์ Code Vipassana