Dùng Gemini 2.5 Flash-Lite để trích xuất thông tin từ yêu cầu hỗ trợ, kể cả khi dữ liệu bị thiếu

Một quy trình nhỏ để biến tin nhắn tự do thành trường có thể kiểm tra, mà không biến chỗ trống thành sự thật.

Một khách hàng viết: “Đơn A-1042 giao hôm qua nhưng thiếu một món. Tôi muốn được kiểm tra lại.” Nhân viên có thể hiểu ngay vấn đề, còn phần mềm cần những trường cụ thể: mã đơn, loại sự cố, món hàng bị thiếu và hành động khách mong muốn. Tin nhắn này không nói món nào bị thiếu. Nếu hệ thống tự đoán một tên sản phẩm để điền đủ biểu mẫu, lỗi đó có thể đi tiếp tới người xử lý, kho hàng hoặc câu trả lời cho khách.

Tôi sẽ dùng Gemini 2.5 Flash-Lite cho bước đề xuất dữ liệu có cấu trúc từ những yêu cầu như vậy. Đây là hướng dẫn xây dựng một luồng thử nhỏ, không phải báo cáo hiệu năng trên hộp thư thật. Ví dụ API ở dưới dùng dữ liệu giả và được kiểm tra riêng; nó không chứng minh rằng mô hình luôn trích xuất đúng trên mọi loại yêu cầu.

Bài toán không chỉ là nhận diện từ khóa

Một yêu cầu hỗ trợ thường chứa nhiều việc cùng lúc. Khách có thể nhắc tới đơn hàng cũ, mô tả lỗi hiện tại rồi hỏi về hoàn tiền. Có khi họ viết “gói hàng đó” mà không có mã đơn. Có khi một mã xuất hiện trong phần trích dẫn email cũ chứ không phải yêu cầu mới. Tìm chuỗi giống mã đơn là hữu ích, nhưng chưa đủ để quyết định chuỗi ấy thuộc vấn đề nào.

Vì vậy tôi tách hai nhiệm vụ. Mô hình đọc câu chữ và đề xuất các trường. Ứng dụng kiểm tra định dạng, đối chiếu dữ liệu có thẩm quyền và quyết định có được chuyển sang bước kế tiếp hay không. “Trích xuất” ở đây là rút thông tin đã có trong nguồn, không phải suy luận cho đầy những ô còn trống.

Các trường tối thiểu cho ví dụ này là order_id, issue, missing_item và requested_action. Giá trị null trong JSON nghĩa là chưa có dữ liệu, khác với chuỗi rỗng và khác với một dự đoán. Tôi còn giữ evidence: đoạn nguyên văn ngắn mà mô hình dùng làm căn cứ. Người rà soát có thể nhìn lại câu gốc, thay vì chỉ thấy một nhãn được tạo ra.

Một bản ghi tốt từ câu mở đầu có mã đơn A-1042, sự cố “thiếu một món”, món bị thiếu là null, và yêu cầu “kiểm tra lại”. Nó không nên biến “giao hôm qua” thành lời hứa giao bù, cũng không nên tự điền tên món hàng.

Sơ đồ khái niệm do tác giả tạo; không phải giao diện sản phẩm hay kết quả mô hình.

Chọn phạm vi mà Flash-Lite có thể giúp

Trang mô hình chính thức của Google mô tả Gemini 2.5 Flash-Lite là mô hình hướng tới các tác vụ tần suất cao, nhẹ, như phân loại và trích xuất dữ liệu đơn giản. Nó nhận văn bản, hình ảnh, âm thanh, video và PDF làm đầu vào; đầu ra là văn bản. Khả năng nhận nhiều loại dữ liệu không có nghĩa là ứng dụng hỗ trợ của bạn tự có OCR, lưu tệp, phân quyền hoặc kiểm toán. Những phần ấy thuộc về hệ thống bao quanh mô hình.

Trang Google hiện cũng lưu ý quyền truy cập trực tiếp vào dòng 2.5 có thể bị giới hạn với dự án mới. Điều đó không tự mô tả khả năng của từng gateway: hãy kiểm tra model và ràng buộc trên chính tuyến API bạn định dùng. Bài này xác nhận một lệnh gọi mẫu qua Crazyrouter, không bảo đảm quyền truy cập tương lai cho mọi tài khoản.

Với tin nhắn ngắn, tôi bắt đầu bằng văn bản đã được tách khỏi chữ ký email, lịch sử chuyển tiếp và nội dung không cần thiết. Nếu đưa cả một chuỗi trao đổi dài vào một lần, hệ thống cần chỉ rõ đâu là tin mới nhất. Nếu có tệp đính kèm, phải xác định nguồn nào có quyền quyết định trước khi gom chúng vào một prompt.

Việc đầu tiên không phải là tối ưu một prompt rất dài. Tôi sẽ chốt một schema nhỏ và định nghĩa từng trường bằng ví dụ tích cực lẫn ví dụ thiếu dữ liệu. Nếu hai người trong nhóm còn hiểu requested_action khác nhau, mô hình cũng không thể tự giải quyết sự mơ hồ ấy một cách đáng tin cậy.

Một lần gọi có thể chạy lại

Đoạn sau dùng Node.js 18 trở lên, vì phiên bản đó có fetch sẵn. Lưu thành tệp .mjs, đặt CRAZYROUTER_API_KEY trong biến môi trường rồi chạy bằng node ten-tep.mjs. Không ghi khóa vào mã nguồn hoặc bài đăng. Đầu vào là tình huống giả, không phải dữ liệu khách hàng thực.

const apiKey = process.env.CRAZYROUTER_API_KEY;
if (!apiKey) throw new Error("Set CRAZYROUTER_API_KEY first");

const ticket = "Đơn A-1042 giao hôm qua nhưng thiếu một món. Tôi muốn được kiểm tra lại.";
const response = await fetch("https://api.crazyrouter.com/v1/chat/completions", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "gemini-2.5-flash-lite",
    messages: [{
      role: "user",
      content: `Trả về đúng một đối tượng JSON với các khóa order_id, issue, missing_item, requested_action, evidence. Chỉ dùng thông tin có trong tin nhắn. Trường không có căn cứ phải là null. evidence là một đoạn nguyên văn ngắn từ tin nhắn. Không thêm Markdown.\n\nTin nhắn: ${ticket}`,
    }],
  }),
});

if (!response.ok) throw new Error(`API ${response.status}: ${await response.text()}`);
const body = await response.json();
const item = JSON.parse(body.choices?.[0]?.message?.content ?? "null");
if (!item || typeof item !== "object" || Array.isArray(item)) throw new Error("Invalid JSON object");
for (const field of ["order_id", "issue", "missing_item", "requested_action", "evidence"]) {
  if (!(field in item)) throw new Error(`Missing field: ${field}`);
}
console.log(item);

Lệnh gọi dùng giao diện tương thích OpenAI của Crazyrouter. Địa chỉ API là https://api.crazyrouter.com; đường dẫn /v1/chat/completions là endpoint của ví dụ này. Một gateway là con đường truy cập mô hình, không thay thế quy tắc xử lý yêu cầu hỗ trợ của doanh nghiệp.

JSON là dạng dữ liệu có cấu trúc để chương trình đọc được. Việc parse thành công chỉ chứng tỏ câu trả lời hợp cú pháp JSON, chưa chứng tỏ từng giá trị đúng. Đoạn mã cố ý kiểm tra đủ khóa, còn kiểm tra nghiệp vụ nên nằm ở bước tiếp theo. Nếu API trả lỗi, mã hiện thông báo HTTP; nếu trả nội dung không phải JSON, JSON.parse sẽ dừng. Đây là kết quả tốt hơn việc âm thầm chuyển một câu trả lời khó hiểu thành bản ghi hợp lệ.

Từ bản ghi đề xuất đến phiếu được xử lý

Tôi sẽ kiểm tra theo thứ tự sau. Trước hết, mã đơn phải đúng định dạng ứng dụng đang dùng. Sau đó, tìm mã ấy trong hệ thống đơn hàng bằng quyền truy cập phù hợp; sự tồn tại trong tin nhắn không chứng minh đơn thuộc về người gửi. Tiếp theo, so từng giá trị với câu gốc và giữ những trường thiếu ở trạng thái chưa biết. Cuối cùng, chuyển cho nhân viên nếu yêu cầu chạm tới hoàn tiền, bồi thường, tranh chấp hoặc bất kỳ quyết định nào có hậu quả tài chính.

Ở ví dụ này, missing_item: null không phải lỗi cần “sửa” bằng một dự đoán. Nó là tín hiệu để hỏi khách: “Bạn có thể cho biết món nào bị thiếu không?” Câu hỏi ấy phải dựa trên chính sách hỗ trợ của cửa hàng và ngữ cảnh đơn hàng. Nếu hệ thống có dữ liệu sản phẩm đã đặt, nhân viên vẫn nên xác nhận món nào không đến, vì một đơn có thể có nhiều món.

Sơ đồ quy trình đề xuất; bước phê duyệt thực tế cần theo chính sách của nhóm hỗ trợ.

Tôi cũng sẽ giữ câu gốc cùng thời gian nhận và phiên bản schema. Khi một trường trích xuất bị sửa, nhóm cần biết thay đổi đó đến từ khách, nhân viên hay từ lần chạy mô hình khác. Không nên chỉ lưu câu trả lời cuối cùng rồi mất hết căn cứ. Với dữ liệu cá nhân, hãy giảm thông tin gửi tới API, kiểm tra điều khoản của nhà cung cấp và chính sách nội bộ trước khi dùng tin thật.

Một bước thực dụng là tạo tập ví dụ đã được con người gán nhãn. Nó phải có tin ngắn, tin dài, mã đơn vắng mặt, nhiều mã, email chuyển tiếp và câu mơ hồ. Rà soát theo loại lỗi, nhất là lỗi điền thông tin không có nguồn, thay vì chỉ nhìn tỷ lệ JSON hợp lệ. Nếu lỗi tập trung ở một kiểu thư, hãy sửa cách tách nguồn hoặc định nghĩa trường trước khi đổi mô hình.

Khi nào nên để người đọc quyết định

Gemini 2.5 Flash-Lite phù hợp để đề xuất cấu trúc ban đầu cho lượng lớn yêu cầu ngắn, miễn là đầu vào có nguồn rõ và có bước kiểm tra sau đó. Nó không biết khách đã được hứa điều gì qua điện thoại, không có quyền tự phê duyệt hoàn tiền và không thể chứng minh một suy đoán là dữ kiện chỉ bằng cách viết trôi chảy.

Giá API Google được công bố riêng trên trang giá chính thức; giá qua Crazyrouter cần xem tại đường truy cập bạn thực dùng. Đừng lấy giá công bố của một nhà cung cấp để hứa chi phí của nhà cung cấp khác. Với một luồng hỗ trợ, chi phí thật còn gồm bước rà soát và xử lý lỗi, không chỉ token của một lần gọi.

Nếu bạn làm công cụ nội bộ cho nhóm hỗ trợ, mô hình này đáng cân nhắc ở khâu đọc và phân loại yêu cầu ban đầu. Nếu yêu cầu hiếm, dữ liệu luôn thiếu hoặc mỗi trường đều dẫn tới một quyết định có rủi ro cao, biểu mẫu hỏi rõ thông tin và nhân viên xử lý có thể phù hợp hơn. Điều cần nhớ là: trường trống phải được giữ trống cho tới khi có nguồn xác nhận; mô hình giúp sắp xếp công việc, không được nhận quyền tạo ra sự thật.

Nguồn: Google, Gemini 2.5 Flash-Lite; Google, Gemini API pricing. Kiểm tra ngày 21/10/2026. Ví dụ và luồng kiểm tra là minh họa kỹ thuật, không phải kết quả đo hiệu năng trên dữ liệu thật.