Từ Dữ Liệu Đến Quyết Định: Sức Mạnh Của Agentic RAG & LEO CDP

Trong kỷ nguyên AI, dữ liệu không còn là vấn đề lớn nhất. Thách thức thực sự là làm thế nào để biến dữ liệu thành tri thức, tri thức thành insight, và insight thành hành động kinh doanh.

Nhiều doanh nghiệp đã áp dụng RAG (Retrieval-Augmented Generation) để giúp AI truy cập dữ liệu nội bộ và trả lời câu hỏi. Tuy nhiên, khi đối mặt với các bài toán phức tạp như phân tích khách hàng, dự báo hành vi, tối ưu chiến dịch marketing hay hỗ trợ ra quyết định, RAG truyền thống bắt đầu bộc lộ nhiều hạn chế.

Đó chính là lý do kiến trúc Agentic RAG ra đời. Tại LEO, chúng tôi xây dựng LEO CDP và LEO Agentic Notebook dựa trên tư duy Agentic AI nhằm giúp doanh nghiệp không chỉ tìm kiếm thông tin mà còn chủ động phân tích, suy luận và đề xuất hành động kinh doanh.

---

1. Vì Sao RAG Truyền Thống Chưa Đủ?

RAG hoạt động giống như một công cụ tìm kiếm thông minh với 3 bước cơ bản: Người dùng đặt câu hỏi ➔ Hệ thống tìm tài liệu ➔ LLM tạo câu trả lời.

Cách tiếp cận này hiệu quả với các câu hỏi đơn giản, nhưng lại gặp rào cản lớn khi doanh nghiệp cần:

• Tổng hợp dữ liệu từ nhiều nguồn đa dạng.
• Phân tích các tệp dữ liệu có cấu trúc phức tạp.
• Thực hiện chuỗi suy luận nhiều bước.
• Tự động hóa quy trình ra quyết định và đề xuất hành động.

"Nhóm khách hàng nào có khả năng mở thẻ tín dụng cao nhất trong 30 ngày tới?"

Với câu hỏi trên, một hệ thống RAG thông thường chỉ trả về các tài liệu tham khảo liên quan. Trong khi đó, để giải quyết bài toán này, doanh nghiệp thực sự cần một hệ thống có khả năng phân tích lịch sử giao dịch, xác định phân khúc, tính toán xác suất chuyển đổi, so sánh chiến dịch và tự động tạo kế hoạch kích hoạt marketing.

Đây chính là lúc Agentic RAG phát huy giá trị.

---

2. Agentic RAG Là Gì?

Agentic RAG không chỉ là công cụ tìm kiếm, nó là sự hội tụ của 5 yếu tố cốt lõi:

1. Knowledge Retrieval (RAG truyền thống)
2. AI Agents (Năng lực suy luận & Ra quyết định)
3. Workflow Orchestration (Điều phối luồng công việc)
4. Tool Calling (Khả năng sử dụng công cụ)
5. Memory & Learning (Ghi nhớ & Tự học)

Thay vì thụ động tìm kiếm thông tin, Agentic RAG chủ động thực hiện chuỗi nhiệm vụ:

• ✅ Hiểu rõ mục tiêu kinh doanh.
• ✅ Lập kế hoạch và tự động chia nhỏ nhiệm vụ.
• ✅ Truy xuất dữ liệu từ nhiều luồng.
• ✅ Phân tích và đưa ra đề xuất hành động.
• ✅ Tự học từ phản hồi của người dùng.

Tóm lại: RAG trả lời câu hỏi. Agentic RAG giải quyết vấn đề.

---

3. LEO Agentic Notebook: Nền Tảng Cho Customer Intelligence

LEO Agentic Notebook được thiết kế để trở thành một AI Operating Workspace for Customer Intelligence.

Thay vì sử dụng mô hình thụ động truyền thống (Chat ➔ Answer), LEO ứng dụng mô hình chủ động và toàn diện hơn:

Source ➔ Insight ➔ Action

Để dễ hình dung, dưới đây là cách LEO vận hành qua 3 giai đoạn:

Giai đoạn	Nhiệm vụ chính	Các hạng mục tiêu biểu
1. Source

(Thu thập) | Gom nguồn dữ liệu đa kênh | Website/App Tracking, CRM, Core Banking, Data Warehouse, PDF, Excel, URL, Knowledge Base... | | 2. Insight

(Phân tích) | AI Agent bóc tách dữ liệu | Customer Journey, Segmentation, Campaign Performance, Churn Prediction, Lead Scoring... | | 3. Action

(Thực thi) | Tự động hóa đầu ra | Tạo Reports, Dashboards, Slides, Marketing Campaigns, Workflow Automation... |

---

4. Kiến Trúc Agentic RAG Bật Mở Sức Mạnh Của LEO

Hệ sinh thái của LEO được xây dựng trên 3 trụ cột vững chắc:

Trụ cột 1: LEO CDP (Customer Data Platform)

Đóng vai trò là trung tâm dữ liệu khách hàng. Hệ thống thu thập và hợp nhất dữ liệu từ Website, Mobile App, CRM, Contact Center, Core Banking... để tạo ra:

• Unified Customer Profile (Hồ sơ khách hàng hợp nhất)
• Góc nhìn Customer 360
• Identity Resolution (Định danh khách hàng)
• Customer Journey (Hành trình khách hàng)

Trụ cột 2: Knowledge Hub

Kho lưu trữ tri thức thông minh chứa tài liệu nội bộ, quy trình nghiệp vụ, chính sách sản phẩm, báo cáo thị trường và nghiên cứu khách hàng. AI có thể truy xuất dữ liệu theo đúng ngữ cảnh thực tế thay vì tìm kiếm theo từ khóa đơn thuần.

Trụ cột 3: Agent Runtime

Sử dụng kiến trúc Multi-Agent Architecture với LangGraph. Mỗi AI Agent sẽ đảm nhận một chuyên môn sâu biệt lập, làm việc phối hợp cùng nhau:

Tên Agent	Vai Trò Chuyên Trách
Research Agent	Chuyên tìm kiếm, tổng hợp dữ liệu chuẩn xác.
Analytics Agent	Phân tích các luồng dữ liệu phức tạp.
Customer Insight Agent	"Đọc vị" hành vi, phát hiện insight tiềm ẩn.
Campaign Agent	Lên chiến lược, đề xuất chiến dịch Marketing.
Report Agent	Viết báo cáo tổng quan tự động.
Slide Agent	Trực quan hóa dữ liệu thành PowerPoint cho C-level.

---

5. Ví Dụ Thực Tế Trong Ngành Ngân Hàng

Hãy thử đặt bài toán từ Ban Marketing: "Khách hàng nào có khả năng mua bảo hiểm nhân thọ trong quý tới?"

Thay vì mất nhiều ngày làm việc thủ công, LEO Agentic Notebook sẽ tự động xử lý chỉ trong vài phút qua 7 bước:

1. Thấu hiểu: Phân tích mục tiêu kinh doanh của chiến dịch.
2. Truy xuất: Lấy dữ liệu từ CDP, CRM, Core Banking và lịch sử các chiến dịch cũ.
3. Phân tích: Đánh giá độ tuổi, thu nhập, hành vi giao dịch và các sản phẩm đang sử dụng.
4. Dự báo: Xây dựng mô hình propensity scoring (chấm điểm xu hướng mua).
5. Lọc tệp: Tạo danh sách khách hàng tiềm năng có tỷ lệ chuyển đổi cao nhất.
6. Đề xuất chiến lược: Đưa ra thông điệp truyền thông, kênh tiếp cận và thời điểm kích hoạt phù hợp cho từng segment.
7. Trình bày: Tự động tạo báo cáo và slide thuyết trình chuyên nghiệp.

---

6. Lợi Ích Khác Biệt Dành Cho Doanh Nghiệp

Việc chuyển đổi sang Agentic RAG mang lại những giá trị hiện hữu:

• Ra quyết định nhanh hơn: AI cung cấp sẵn các đề xuất hành động thực tiễn thay vì chỉ đưa ra những con số vô hồn.
• Tối ưu hiệu quả Marketing: Xác định và tiếp cận đúng khách hàng mục tiêu với độ chính xác cao.
• Tự động hóa phân tích: Giải phóng khối lượng công việc khổng lồ cho đội ngũ Data Analyst.
• Khai thác tri thức triệt để: Biến các tài liệu nội bộ đang nằm im thành "tài sản AI" có thể tái sử dụng sinh lời.
• Customer Intelligence Real-time: Phân tích và kích hoạt khách hàng liên tục, không độ trễ.

---

Kết Luận: Từ Chatbot Đến "AI Operating Workspace"

Nhiều doanh nghiệp hiện tại vẫn đang đánh đồng AI với một chiếc Chatbot hỏi-đáp. Tuy nhiên, tương lai không nằm ở Chatbot. Tương lai của doanh nghiệp nằm ở AI Agents, Agentic RAG, Autonomous Analytics và các AI Operating Workspace.

Đó chính là định hướng mà LEO CDP và LEO Agentic Notebook đang kiến tạo. Chúng tôi không chỉ giúp doanh nghiệp trả lời câu hỏi, mà còn giúp bạn:

• Hiểu khách hàng hơn.
• Ra quyết định tốt hơn.
• Hành động nhanh hơn.

Agentic RAG là bước tiến tất yếu của AI doanh nghiệp. Bằng cách kết hợp LEO CDP và LEO Agentic Notebook, bạn đang xây dựng một cỗ máy Customer Intelligence hoàn chỉnh và khép kín:

Data Sources ➔ LEO CDP ➔ Knowledge Hub ➔ Agentic RAG ➔ Insights ➔ Actions ➔ Business Growth

Trong thế giới kinh doanh ngày càng phức tạp, người chiến thắng không phải là người sở hữu nhiều dữ liệu nhất, mà là người có khả năng biến dữ liệu thành quyết định nhanh và chính xác nhất.

🚀 Hướng Dẫn Toàn Diện Chuẩn Bị Phỏng Vấn AI: Làm Chủ RAG (Retrieval-Augmented Generation)

Nếu bạn đang nhắm tới một vị trí trong lĩnh vực AI—đặc biệt là các hệ thống LLM (Large Language Model)—thì RAG (Retrieval-Augmented Generation) không còn là “nice-to-have”, mà là bắt buộc phải hiểu sâu.

Bài viết này sẽ giúp bạn nắm chắc từ nền tảng đến triển khai thực tế, đúng chuẩn những gì nhà tuyển dụng đang tìm kiếm.

---

1. 🧠 RAG Là Gì Và Tại Sao Nó Quan Trọng?

RAG (Retrieval-Augmented Generation) là kỹ thuật cho phép mô hình ngôn ngữ tra cứu thông tin bên ngoài trước khi trả lời.

👉 So sánh đơn giản:

• LLM thuần = học sinh trả lời bằng trí nhớ
• RAG = học sinh được mở sách đúng trang rồi mới trả lời

Vì sao RAG critical?

• 📌 Truy cập dữ liệu mới nhất (real-time)
• 📌 Sử dụng được dữ liệu nội bộ (private data)
• 📌 Giảm hallucination (bịa thông tin)
• 📌 Tăng độ chính xác và tin cậy

---

2. ⚠️ Hạn Chế Của LLM Thuần (Không Có RAG)

Một LLM không có RAG sẽ:

• ❌ Chỉ biết những gì đã được train trước đó
• ❌ Không biết thông tin mới (ví dụ: hôm qua xảy ra gì)
• ❌ Không truy cập được dữ liệu nội bộ (policy, CRM…)
• ❌ Có thể trả lời sai nhưng vẫn rất tự tin (hallucination)

👉 Kết luận: LLM thuần = kiến thức đóng băng + rủi ro cao

---

3. ⚖️ RAG vs Fine-tuning: Chọn Cái Nào?

🧠 RAG (Retrieval-Augmented Generation)

• ⚙️ Cách hoạt động: Truy vấn dữ liệu runtime
• 📦 Bản chất: Thêm “kiến thức bên ngoài”
• ⚡ Update: Nhanh, linh hoạt
• 🎯 Use case: Q&A, search, knowledge system

🧬 Fine-tuning

• ⚙️ Cách hoạt động: Train lại model
• 🧠 Bản chất: Thay đổi “bộ não”
• 🐢 Update: Chậm, tốn chi phí
• 🎯 Use case: Style, tone, rule-based behavior

Khi nào dùng RAG?

• Dữ liệu thay đổi liên tục
• Dữ liệu lớn hoặc private
• Cần minh bạch & dễ update

Khi nào dùng Fine-tuning?

• Điều chỉnh tone, style
• Dạy rule cụ thể
• Tối ưu task chuyên biệt

👉 Thực tế: RAG first → Fine-tune later (nếu cần)

---

4. 🎯 Use Case Phù Hợp Với RAG

RAG mạnh khi:

• 📚 Q&A trên tài liệu
• 🏢 Enterprise search
• ⚖️ Legal / compliance systems
• 🛠️ Technical documentation assistant

Không phù hợp khi:

• 🎨 Creative writing
• 🧩 Logic puzzles
• 🧠 Pure reasoning (không cần data ngoài)

---

5. 🧱 Kiến Trúc RAG: 2 Thành Phần Chính

1. Retrieval (Truy xuất)

• Tìm dữ liệu liên quan từ external sources

2. Generation (Sinh câu trả lời)

• LLM kết hợp:

• câu hỏi user
• context đã retrieve

👉 Goal: Accuracy + Natural Language

---

6. 🔄 Pipeline RAG End-to-End

Một pipeline RAG chuẩn gồm:

1. User query
2. Convert query → embedding
3. Search vector DB
4. Ranking + filtering
5. Build context
6. LLM generate answer

👉 Điểm mấu chốt:
LLM không đoán → LLM đọc rồi giải thích

---

7. 📥 Data Ingestion & Document Loading

DocumentLoader là gì?

Công cụ đưa dữ liệu từ:

• PDF
• Web
• Database

→ về format chuẩn (Document trong LangChain)

---

🌐 WebBaseLoader hoạt động thế nào?

• Crawl HTML từ URL
• Extract text
• Convert thành Document objects

---

🧩 WebBaseLoader + TextSplitter

• Loader → lấy raw content
• TextSplitter → chia nhỏ thành chunks

👉 Vì embedding cần text nhỏ, rõ nghĩa

---

⚙️ Tùy chỉnh HTML Parsing

Dùng:

• BeautifulSoup: parse HTML
• SoupStrainer: lọc phần cần thiết

👉 Ví dụ:

• Chỉ lấy <article>
• Bỏ menu, ads, cookie banner

Vì sao quan trọng?

Garbage in → Garbage out

Nếu bạn index:

• “Accept cookies”
• Navigation menu

👉 LLM sẽ trả lời rất tệ

---

8. ✂️ Chunking: Nghệ Thuật Chia Nhỏ Dữ Liệu

Tại sao phải chia nhỏ?

• Document lớn = nhiều topic → embedding bị “loãng”
• Chunk nhỏ = 1 ý rõ ràng → retrieval chính xác hơn

---

Vì sao không embed cả document?

• Token limit của model
• Embedding bị “average hóa” → mất meaning

👉 Nguyên tắc:

• Chunk = 1 concept
• Không quá dài, không quá ngắn

---

🔚 Kết Luận

RAG không chỉ là một kỹ thuật—nó là xương sống của AI system hiện đại.

Nếu bạn muốn build AI production-grade:

• ❌ Đừng rely vào LLM thuần

• ✅ Phải hiểu sâu:

• Retrieval
• Embedding
• Chunking
• Data quality

👉 Và quan trọng nhất: AI không mạnh vì model — mà mạnh vì DATA + PIPELINE

---

Sample Multi-Agent + RAG project: 

🚀 AI-Native Trip Planner (Multi-Agent + RAG)

Một hệ thống multi-agent production-grade, xây dựng trên Gemini 2.0 Flash và LangGraph, minh họa cách triển khai AI cá nhân hóa theo hướng Privacy-First bằng cách tích hợp:

• Customer Data Platform (LEO CDP)
• PostgreSQL 16
• Kiến trúc agent song song (parallel processing)

👉 Đây không chỉ là agent system — mà là RAG system nâng cao + orchestration layer

---

🌟 Core Architecture (Mapping sang RAG)

🤖 Parallel Agent Orchestration → Multi-Retriever RAG

• Sử dụng LangGraph để fan-out nhiều agent:

• Research Agent (tìm thông tin)
• Budget Agent (phân tích chi phí)
• Local Agent (insight địa phương)

👉 Tương đương:

• Multiple retrievers chạy song song

• Giảm latency + tăng coverage context

➡️ Đây là pattern: Parallel RAG Retrieval

---

📂 OOP Data Service → Personalized Retrieval Layer

• Strategy Pattern để load dữ liệu user từ:

• LEO CDP
• PostgreSQL 16
• CRM khác

👉 Trong RAG:

• Đây chính là User Context Retriever

• Enable:

• Personalization
• Context-aware generation

➡️ Upgrade từ:
Generic RAG → Personalized RAG

---

⚡ Gemini 2.0 Flash → Generator + Tool-Calling Engine

• LLM đóng vai trò:

• Tổng hợp context từ nhiều agent
• Gọi tool (search, DB, APIs)

👉 Trong RAG:

• Đây là Generation Layer

• Nhưng nâng cấp:

  • Native tool-use → Agentic RAG

---

👁️ Observability (Arize Phoenix) → RAG Debugging Layer

• OTLP tracing full pipeline:

• Agent decisions
• Tool calls
• Retrieval quality

👉 Trong RAG:

• Đây là phần thường bị thiếu nhưng cực kỳ critical:

  • Debug hallucination

  • Analyze retrieval relevance

➡️ Pattern: Observable RAG

---

🛡️ Graceful Degradation → Robust Retrieval Strategy

• Fallback:

• Tavily
• SerpAPI

👉 Trong RAG:

• Đây là:

• Fail-safe retrieval
• Không để system “silent fail”

➡️ Pattern: Resilient RAG

---

🧠 Tổng Kết Kiến Trúc (RAG Perspective)

Hệ thống này thực chất là:

Agentic + Personalized + Parallel + Observable RAG System

---

Stack tư duy:

• Retrieval:

• Multi-agent (parallel)
• User data (CDP + DB)
• External search fallback

• Generation:

  • Gemini 2.0 Flash (tool-aware)

• Orchestration:

  • LangGraph

• Observability:

  • Arize Phoenix

---

🔥 Insight Quan Trọng

👉 Đây là evolution của RAG:

Level	Mô tả
Basic RAG	1 retriever + 1 LLM
Advanced RAG	Chunking + ranking
Agentic RAG	Multi-agent orchestration
Personalized RAG	CDP + user profile
Production RAG	Observability + fallback

---

🎯 Kết luận

• RAG không còn là vector DB + LLM đơn giản
• Production AI = Data + Orchestration + Observability

👉 Nếu không có:

• personalization
• fallback
• tracing

→ system của bạn chỉ là demo, không phải production

---

Nếu bạn muốn, tôi có thể:

• Vẽ lại kiến trúc này thành diagram chuẩn system design (LEO CDP + LangGraph)

• Hoặc viết code skeleton LangGraph + RAG pipeline đúng theo stack bạn đang dùng

https://github.com/trieu/ai-trip-planner

RAG vs. CAG: Giải quyết "điểm mù" của AI với Google Gen AI, pgvector & marker-pdf

RAG vs. CAG, explained visually for AI engineers

RAG (Retrieval-Augmented Generation) đã thay đổi hoàn toàn cách chúng ta xây dựng các hệ thống AI dựa trên dữ liệu thực tế. Tuy nhiên, nếu bạn đã từng đưa hệ thống AI lên môi trường production, bạn sẽ nhanh chóng nhận ra một điểm yếu cố hữu:

Mỗi khi có một truy vấn mới, model thường xuyên phải truy xuất và đọc lại cùng một ngữ cảnh (context) từ Vector Database. Điều này gây ra 3 vấn đề lớn: đắt đỏ (tốn token), dư thừa và chậm trễ (high latency).

Đây là lúc CAG (Cache-Augmented Generation) xuất hiện. Bằng cách kết hợp khéo léo giữa RAG và CAG, bạn có thể tạo ra một hệ thống vừa thông minh, vừa siêu tốc độ.

---

1. Bản chất của RAG và CAG là gì?

• RAG (Truy xuất truyền thống): Truy vấn -> Tìm kiếm top-K chunks từ DB -> Nhồi chunks vào prompt -> Gửi cho LLM đọc lại từ đầu.

• CAG (Sử dụng bộ nhớ đệm): Cho phép model "ghi nhớ" các thông tin cố định bằng cách lưu chúng trực tiếp vào bộ nhớ Key-Value (KV memory) của LLM. Lần sau hỏi, model dùng luôn cache mà không cần đọc lại ngữ cảnh.

2. So sánh RAG vs. CAG (Pros & Cons)

Tiêu chí	RAG (Retrieval-Augmented)	CAG (Cache-Augmented)
Bản chất	Tìm kiếm dữ liệu mới cho mỗi câu hỏi.	Lưu trước dữ liệu vào bộ nhớ của LLM.
Tốc độ (Latency)	Chậm hơn (Mất thời gian Query DB + LLM đọc lại).	Cực nhanh (LLM đã có sẵn ngữ cảnh).
Chi phí Token	Tốn phí input token cho mỗi lần query.	Rẻ hơn đáng kể (phí cache hit cực thấp).
Điểm yếu (Cons)	Latency cao, dễ retrieve sai đoạn văn (hallucination).	Giới hạn bởi Context Window. Không thể cache dữ liệu thay đổi liên tục.

3. Use Cases: Chọn lọc những gì bạn Cache

Nguyên tắc vàng: Không cache mọi thứ. Bạn cần phân tách dữ liệu thành 2 luồng:

• 🟢 Dữ liệu "Lạnh" (Cold Data) -> Dùng CAG: Sổ tay nhân viên, chính sách công ty, API Documentation, System Instructions dài.

• 🔵 Dữ liệu "Nóng" (Hot Data) -> Dùng RAG: Lịch sử chat của user, trạng thái đơn hàng, dữ liệu real-time cập nhật từng phút.

---

4. Giải pháp Tối ưu: Kiến trúc RAG + CAG (Hybrid) với Modern Tech Stack

Để xây dựng một hệ thống production-ready, chúng ta sẽ kết hợp RAG và CAG bằng một Tech Stack hiện đại:

1. marker-pdf: Chuyển đổi các file PDF phức tạp (chứa bảng biểu, định dạng khó) thành Markdown siêu sạch — định dạng mà LLM hiểu tốt nhất. Đây là nguồn cho Dữ liệu tĩnh (CAG).

2. Google Gen AI (google-genai): Sử dụng Gemini 1.5 với tính năng Context Caching API bản địa để lưu trữ Markdown tĩnh này.

3. PostgreSQL 16 + pgvector: Đóng vai trò là Vector Database mạnh mẽ để lưu trữ và truy xuất siêu tốc các sự kiện, lịch sử tương tác động của người dùng (RAG).

💻 Python Code: Optimized Hybrid RAG + CAG

Dưới đây là mã nguồn đã được tối ưu hóa cho môi trường thực tế, xử lý triệt để các vấn đề về SDK logic, format dữ liệu vector và hiệu năng.

Cài đặt: pip install google-genai psycopg2-binary marker-pdf

import os

import psycopg2

import json

from google import genai

from google.genai import types

from marker.converters.pdf import PdfConverter

# Khởi tạo Client theo SDK mới của Google

client = genai.Client(api_key=os.environ.get("GEMINI_API_KEY"))

MODEL_NAME = "models/gemini-1.5-flash"

# ==========================================

# PHẦN 1: CAG (COLD DATA - DỮ LIỆU TĨNH)

# ==========================================

def create_cag_from_pdf(pdf_path: str):

    print(f"[*] Đang sử dụng marker-pdf bóc tách Markdown: {pdf_path}")

    

    # Khởi tạo converter (Lưu ý: marker-pdf chạy tốt nhất trên GPU)

    converter = PdfConverter()

    rendered = converter(pdf_path)

    markdown_text = rendered.markdown

    

    print("[*] Đang khởi tạo Google Gemini Context Cache...")

    # LƯU Ý QUAN TRỌNG: system_instruction được đóng gói cứng vào Cache

    # Việc này giúp LLM tiền xử lý (pre-process) luôn chỉ dẫn, giảm tối đa độ trễ.

    cache = client.caches.create(

        model=MODEL_NAME,

        config=types.CreateCacheConfig(

            display_name="HR_Policy_2024",

            contents=[types.Content(parts=[types.Part(text=markdown_text)], role="user")],

            system_instruction="Bạn là trợ lý nhân sự chuyên nghiệp. Hãy sử dụng quy định công ty trong ngữ cảnh được cung cấp để giải đáp thắc mắc.",

            ttl="3600s" # Tự động hủy sau 1 giờ

        )

    )

    return cache

# ==========================================

# PHẦN 2: RAG (HOT DATA - DỮ LIỆU BIẾN ĐỘNG)

# ==========================================

def retrieve_dynamic_data(query: str, user_id: str) -> str:

    # 1. Embedding câu hỏi

    embedding_response = client.models.embed_content(

        model="text-embedding-004",

        contents=query

    )

    query_vector = embedding_response.embeddings[0].values

    # 2. Kết nối PostgreSQL 16 (pgvector)

    try:

        conn = psycopg2.connect("dbname=ragdb user=postgres password=secret host=localhost")

        cur = conn.cursor()

        

        # CHUẨN HÓA VECTOR: pgvector yêu cầu chuỗi định dạng [0.1, 0.2, ...]

        query_vector_str = f"[{','.join(map(str, query_vector))}]"

        

        # Truy vấn kết hợp: Lọc cứng theo user_id trước, sau đó tính khoảng cách Cosine (<=>)

        cur.execute("""

            SELECT content 

            FROM user_interactions 

            WHERE user_id = %s 

            ORDER BY embedding <=> %s::vector 

            LIMIT 3;

        """, (user_id, query_vector_str))

        

        rows = cur.fetchall()

        cur.close()

        conn.close()

        

        return "\n".join([r[0] for r in rows]) if rows else "Không tìm thấy dữ liệu cá nhân."

    except Exception as e:

        return f"Lỗi truy xuất RAG: {str(e)}"

# ==========================================

# PHẦN 3: HYBRID GENERATION (KẾT HỢP RAG & CAG)

# ==========================================

def ask_ai_assistant(user_query: str, user_id: str, cache_obj):

    # Lấy thông tin cá nhân của user (RAG)

    dynamic_context = retrieve_dynamic_data(user_query, user_id)

    

    # Tạo prompt kết hợp - Tách bạch rõ ràng dữ liệu để tránh nhầm lẫn

    prompt = f"""

THÔNG TIN CÁ NHÂN NHÂN VIÊN (Dữ liệu động):

{dynamic_context}

YÊU CẦU CỦA NHÂN VIÊN:

{user_query}

"""

    print("[*] Đang thực thi Hybrid Reasoning (CAG + RAG)...")

    response = client.models.generate_content(

        model=MODEL_NAME,

        contents=prompt,

        config=types.GenerateContentConfig(

            cached_content=cache_obj.name, # Kích hoạt CAG qua Cache ID

            temperature=0.1, # Giảm độ sáng tạo, bắt buộc tuân thủ đúng quy định HR

            max_output_tokens=1000

        )

    )

    return response.text

# ==========================================

# LUỒNG VẬN HÀNH THỰC TẾ

# ==========================================

if __name__ == "__main__":

    # BƯỚC 1: Tạo Cache (Chỉ làm 1 lần khi server start hoặc file update)

    # Thực tế: Nên lưu `policy_cache.name` vào DB để tái sử dụng

    policy_cache = create_cag_from_pdf("hr_handbook_2024.pdf")

    

    # BƯỚC 2: Nhận câu hỏi từ User

    uid = "employee_007"

    q = "Tôi còn 5 ngày phép, muốn nghỉ từ thứ 4 đến thứ 6 tuần này. Có vi phạm quy định báo trước của công ty không?"

    

    # BƯỚC 3: Trả lời siêu tốc

    result = ask_ai_assistant(q, uid, policy_cache)

    

    print("-" * 30)

    print(f"👤 USER: {q}")

    print(f"🤖 AI:\n{result}")

Tại sao Kiến trúc này là "vũ khí tối thượng"?

Đoạn code trên không chỉ là ví dụ minh họa mà đã giải quyết những bài toán hóc búa nhất khi làm hệ thống RAG thực tế:

1. Chất lượng Context tuyệt đối (marker-pdf): RAG truyền thống thường "gãy" khi parse file PDF chứa bảng biểu pháp lý, nhân sự. Việc bóc tách sạch sẽ bằng mô hình deep-learning của marker-pdf đảm bảo LLM không bị "mù" định dạng.

2. Tối ưu TTFT (Time-To-First-Token) cực đỉnh: Bằng cách đưa system_instruction trực tiếp vào hàm create_cache, Gemini sẽ tiền xử lý toàn bộ luật lệ. Model trả lời gần như tức thì và bạn chỉ tốn 1 phần nhỏ phí token so với việc gửi đi gửi lại hàng chục ngàn từ mỗi lần.

3. Khắc phục lỗi Multi-tenancy với pgvector: Các hệ thống In-memory Vector DB thường gặp khó khi lọc dữ liệu theo user. SQL thuần của Postgres (WHERE user_id = %s) lọc dữ liệu người dùng cực kỳ an toàn trước khi tính khoảng cách không gian (Cosine Distance).

4. Kiểm soát Hallucination: Việc set temperature=0.1 kết hợp với prompt tách bạch rõ (Dữ liệu động vs Câu hỏi) ép LLM trở thành một cỗ máy suy luận logic nghiêm ngặt dựa trên Cache thay vì "sáng tác" thêm.

---

🎯 Lời kết

Kiến trúc Hybrid RAG + CAG chính là tương lai của các hệ thống AI cấp doanh nghiệp. Thay vì bắt LLM của bạn đóng vai một "người mắc bệnh mất trí nhớ ngắn hạn" phải đọc lại nội quy công ty 10,000 lần một ngày, hãy lưu nó vào Cache.

Giữ RAG cho những gì đang di chuyển, và dùng CAG cho những gì đứng yên.

👉 Còn bạn thì sao? Đã đến lúc nâng cấp hệ thống RAG của bạn bằng Prompt Caching chưa?