Giới thiệu Cơ chế Quản lý Hội thoại

Trong hệ thống ứng dụng AI dựa trên mô hình ngôn ngữ lớn, việc duy trì trạng thái hội thoại là yếu tố then chốt cho trải nghiệm người dùng liền mạch. Dify cung cấp cơ chế quản lý hội thoại toàn diện, hỗ trợ theo dõi ngữ cảnh đa vòng và lưu trữ lịch sử tương tác.

Quản lý Chu kỳ Sống của Hội thoại

Dify sử dụng định danh duy nhất conv_id để phân tách luồng hội thoại giữa các người dùng. Mỗi hội thoại bao gồm dữ liệu đầu vào, phản hồi, thời gian và biến ngữ cảnh. API cho phép tạo, truy vấn hoặc xóa hội thoại:

{
  "conv_id": "conv_789xyz",
  "message": "Thời tiết hôm nay thế nào?",
  "reply": "Vui lòng cung cấp tên thành phố.",
  "timestamp": "2025-04-05T10:00:00Z"
}

Cấu trúc này phục vụ cho giao diện người dùng và hệ thống ghi log.

Lưu trữ và Truy vấn Lịch sử Hội thoại

Dữ liệu hội thoại được lưu trữ trong cơ sở dữ liệu phía máy chủ, hỗ trợ truy vấn theo user_id hoặc conv_id với phân trang. Ví dụ truy vấn 10 tin nhắn gần nhất:

# Lấy lịch sử hội thoại
curl -X GET "https://api.dify.ai/v2/chats/conv_789xyz/history?limit=10" \
  -H "Authorization: Bearer API_KEY"

Chiến lược Quản lý Ngữ cảnh Hội thoại

Để tránh giảm hiệu năng do ngữ cảnh dài, Dify cung cấp ba phương pháp:

Phương pháp	Ứng dụng	Chi phí Tài nguyên
Lưu toàn bộ ngữ cảnh	Trò chuyện ngắn, nhiệm vụ quan trọng	Ca
Cửa trượt động	Chatbot hỗ trợ khách hàng	Trung bình
Tổng hợp tóm tắt	Tư vấn phức tạp dài hạn	Thấp đến Trung bình

Thiết kế Cơ sở Dữ liệu Hội thoại

Thiết kế Mô hình Dữ liệu

Mô hình hội thoại cần xác định rõ các trường dữ liệu để đảm bảo nhất quán trạng thái. Các trường cốt lõi: - conv_id: Mã định danh toàn cầu - user_key: Liên kết với tài khoản người dùng - expiry_ts: Thời gian hết hạn - client_ip và user_agent: Tăng cường bảo mật Ví dụ cấu trúc:

{
  "conv_id": "conv_789xyz",
  "user_key": "usr_456",
  "created_at": 1712000000,
  "expiry_ts": 1712086400,
  "client_ip": "192.168.1.100",
  "user_agent": "Chrome/120"
}

Thực hành Lưu trữ Hội thoại bằng Redis

Redis được sử dụng làm lớp cache phân tán để xử lý tải cao:

HSET conv:usr:456 token "xyz789" expire_ts 1735689000 ip "192.168.1.2"
EXPIRE conv:usr:456 1800

Cấu trúc này sử dụng user_key làm khóa, kết hợp EXPIRE để tự động xóa hội thoại cũ.

Quản lý Chu kỳ Sống và Tối ưu Hiệu năng

- server.session.timeout trong Spring Boot: 30m (tự động hết hạn sau 30 phút không hoạt động) - Sử dụng Redis tập trung cho quản lý hội thoại - Xóa định kỳ hội thoại hết hạn - Xóa hội thoại khi đăng xuất

Phân tích Lưu trữ Lịch sử Hội thoại

Quy trình Ghi Lịch sử

Dữ liệu hội thoại được ghi dưới dạng cấu trúc có cấu trúc:

type MessageLog struct {
  ConvID     string    `json:"conv_id"`
  UserKey    string    `json:"user_key"`
  Content    string    `json:"content"`
  Timestamp  int64     `json:"timestamp"`
  Direction  string    `json:"direction"` // "input" hoặc "output"
}

Quy trình ghi: 1. Xác thực định dạng tin nhắn 2. Tạo hoặc tái sử dụng conv_id 3. Chuyển đổi thành JSON và gửi vào hàng đợi Kafka 4. Lưu trữ bất đồng bộ vào Elasticsearch và lưu trữ lạnh

Chỉ mục Ngữ nghĩa bằng Cơ sở Dữ liệu Vector

Để tìm kiếm ngữ nghĩa hiệu quả, chuyển đổi văn bản thành vector:

from sentence_transformers import SentenceTransformer
model = SentenceTransformer('all-MiniLM-L6-v2')
vector = model.encode(["Đăng nhập thất bại"])

Bảng so sánh cơ sở dữ liệu vector:

Cơ sở dữ liệu	Loại Chỉ mục	Độ trễ (ms)
FAISS	IVF, HNSW	5-10
Qdrant	HNSW, Graph	10-20

Phân tách Dữ liệu theo Nhiều Người Dùng

Để tối ưu hiệu năng, áp dụng chỉ mục hợp thành:

CREATE INDEX idx_tenant_conv ON conversations (tenant_id, conv_id);

Cơ chế tự động thêm điều kiện tenant_id = ? vào mọi truy vấn.

Giải pháp cho Xử lý 1 Triệu Hội thoại

Thiết kế Phân mảnh Cơ sở Dữ liệu

Với tải cao, sử dụng phân mảnh theo user_key:

spring:
  shardingsphere:
    rules:
      sharding:
        tables:
          t_conv:
            actual-data-nodes: db$->{0..7}.t_conv_$->{0..9}
            table-strategy:
              standard:
                sharding-column: conv_id
                sharding-algorithm-name: conv-hash
            database-strategy:
              standard:
                sharding-column: user_key
                sharding-algorithm-name: user-hash

Tách dữ liệu Nóng/Lạnh

Cơ chế phân tách: - Dữ liệu nóng: Hội thoại hoạt động trong 7 ngày - Dữ liệu lạnh: Hội thoại không hoạt động > 30 ngày Ví dụ xử lý:

func ArchiveInactiveConv() {
    convs := db.Query("SELECT id, data FROM conversations WHERE last_active < NOW() - INTERVAL 30 DAY")
    for _, c := range convs {
        archiveStorage.Store(c.id, c.data)
    }
    db.Exec("DELETE FROM conversations WHERE last_active < NOW() - INTERVAL 30 DAY")
}

Giám sát Hội thoại Thực thời

Phát hiện hành vi bất thường:

func CheckAnomaly(session *SessionData) bool {
    if time.Since(session.LastLogin) < 10*time.Second {
        return true // Đăng nhập quá nhanh
    }
    if session.DistanceFromLastIP() > 500 {
        return true // Chuyển địa lý đột ngột
    }
    return false
}