Sau một năm đưa AI agent vào vận hành thực tế trên Elasticsearch Platform, Elastic cho biết các hệ thống này đã xử lý hơn 1 triệu tin nhắn nhiều quy trình vận hành như hỗ trợ khách hàng, bán hàng, tóm tắt hồ sơ và quản lý nội bộ.

Điểm đáng chú ý không chỉ dừng lại ở việc Elastic triển khai thành công AI agent vào môi trường thật. Điều quan trọng hơn là họ đã giám sát toàn diện cách thức AI vận hành trong thực tế hằng ngày: đối tượng tương tác nhiều nhất, ngữ cảnh nào giúp tối ưu câu trả lời, lỗi truy xuất tài liệu xảy ra ở đâu, nhật ký hệ thống (logs) phản ánh điều gì, và liệu việc tiêu tốn lượng lớn token có thực sự là một vấn đề gì hay không.

Khi đưa AI agent vào môi trường production, câu hỏi khó nhất không còn là “AI có trả lời được không”, mà là “làm sao xác định câu trả lời đó đủ độ chính xác, chất lượng và giá trị hữu ích”. Nếu thiếu một lớp giám sát đủ sâu, đội ngũ phát triển chỉ có thể nhìn thấy kết quả đầu ra cuối cùng mà không thể bóc tách nguyên nhân cốt lõi phía sau: tài liệu đầu vào có thực sự liên quan hay không, nguồn dữ liệu nền tảng đang thiếu hụt những gì, nhu cầu thực tế của người dùng ra sao, và những phản hồi nào cần được tối ưu. thiện.

Elastic giải bài toán này bằng cách chuyển hóa nhật ký hệ thống, kết quả truy xuất, hành vi người dùng và các chỉ số chất lượng thành một vòng phản hồi liên tục (feedback loop). Thay vì chỉ tích hợp mô hình ngôn ngữ lớn vào ứng dụng rồi đánh giá một cách cảm tính, họ xây dựng AI agent trên một hệ sinh thái đồng bộ tích hợp công cụ tìm kiếm, truy xuất kết hợp (hybrid retrieval), giám sát ngữ cảnh và phân tích dữ liệu vận hành ở quy mô lớn.

AI agent của Elastic được dùng trong nhiều quy trình thực tế

Từ năm 2024, đội Field Technology của Elastic đã xây dựng và triển khai nhiều AI agent để cải thiện trải nghiệm hỗ trợ khách hàng và đơn giản hóa quy trình bán hàng. Các công cụ này bao gồm:

• Trợ lý hỗ trợ khách hàng: AI agent trong trung tâm hỗ trợ, giúp trả lời câu hỏi của khách hàng.
• Trợ lý hỗ trợ nội bộ: AI agent được kết nối với nguồn dữ liệu nội bộ mở rộng, giúp đội ngũ nội bộ xử lý vấn đề nhanh hơn.
• Công cụ tóm tắt hồ sơ hỗ trợ: giúp kỹ sư hỗ trợ nhanh chóng nắm bắt use case của khách hàng.
• Công cụ soạn nháp kiến thức: tự động tạo bản nháp bài viết knowledge base từ lịch sử hồ sơ hỗ trợ.
• Trợ lý bán hàng: được tích hợp trực tiếp vào Salesforce để hỗ trợ đội doanh thu phân tích tài khoản và cơ hội bán hàng.

Toàn bộ các công cụ trên đều vận hành chung trên một lớp hạ tầng Elastic cốt lõi, nhưng được thiết kế chuyên biệt cho từng quy trình và đối tượng sử dụng cụ thể. Đây là cách tiếp cận tối ưu cho các hệ thống AI trong môi trường vận hành thực tế, nơi mỗi agent cần được phân định phạm vi trách nhiệm rõ ràng, thay vì hoạt động như một chatbot vạn năng cho mọi tình huống.

Qua một năm vận hành thực tế, thành công của một dự án AI không đơn thuần đến từ việc lựa chọn mô hình ngôn ngữ lớn. Yếu tố quyết định nằm ở chu trình phản hồi, độ phù hợp của tài liệu được truy xuất và năng lực chuyển hóa nhật ký tương tác thành tài sản dữ liệu chiến lược.

Nhật ký hệ thống là nền tảng để đo chất lượng AI

Một trong những bài học lớn nhất là vai trò của nhật ký hệ thống trong việc đánh giá chất lượng AI agent. Nhật ký không chỉ ghi lại nội dung tương tác, mà còn phản ánh hành vi hệ thống, ngữ cảnh ứng dụng, các thành phần phụ thuộc và những tín hiệu vận hành mà các lớp đo lường khác khó thể hiện đầy đủ.

Để khai thác dữ liệu này, Elastic xây dựng một cổng AI tập trung để đánh giá toàn bộ lưu lượng mô hình ngôn ngữ lớn. Từ nhật ký hội thoại, hệ thống tiến hành ẩn dữ liệu cá nhân, sau đó chuyển đổi siêu dữ liệu thành các nhóm trường hợp sử dụng, hành trình tương tác của người dùng và chỉ số đánh giá độ chính xác của phản hồi.

Elastic gọi cách tiếp cận này là Context Performance Monitoring. Hiểu một cách đơn giản, đây là giải pháp giám sát xem phần context được nạp vào AI có thực sự giúp tối ưu hóa chất lượng câu trả lời hay không.

Mô hình này tương đồng với xu hướng khả năng quan sát LLM (LLM observability), sử dụng tổng hợp các chỉ số như nhật ký (logs), dấu vết xử lý (traces), câu lệnh đầu vào (prompts), phản hồi, hiệu năng hệ thống, mức độ tiêu thụ tài nguyên và chi phí để liên tục giám sát cũng như tối ưu hóa ứng dụng AI trong môi trường vận hành thực tế.

Nhờ đó, đội phát triển có thể đánh giá cảm xúc người dùng, chất lượng phản hồi và độ chính xác trên từng cuộc hội thoại. Đây là điểm quan trọng vì AI agent trong môi trường thật không thể chỉ được đánh giá bằng cảm nhận chủ quan hoặc một vài bộ kiểm thử tĩnh trước khi ra mắt. Chúng cần được theo dõi liên tục bằng dữ liệu thực tế.

Nhóm người dùng tích cực tạo ra phần lớn giá trị

Mức độ sử dụng công cụ AI không phân bổ đồng đều giữa các nhóm người dùng. Trong năm 2025, các công cụ AI của Elastic xử lý 209.220 chuỗi hội thoại trên 5 công cụ khác nhau. Đến cuối năm, gần 8% người dùng, được gọi là nhóm người dùng tích cực, tạo ra 80% tổng số phiên, trong khi 92% người dùng còn lại chỉ tạo ra 20% số phiên.

Điều này cho thấy mức độ tiếp nhận AI agent thường đi theo mô hình “số ít tạo ra phần lớn tương tác”. Một nhóm nhỏ người dùng tích hợp AI sâu vào công việc hằng ngày sẽ tạo ra phần lớn dữ liệu sử dụng và cũng là nhóm thể hiện rõ nhất giá trị thực tế của hệ thống.

Nhóm người dùng tích cực không chỉ hỏi các câu đơn giản. Họ ngày càng dùng trợ lý AI cho các vấn đề kỹ thuật phức tạp hơn, đặc biệt là những câu hỏi liên quan đến kiến trúc hệ thống và hướng dẫn triển khai chi tiết. Điều này cho thấy nguồn dữ liệu hỗ trợ cần được mở rộng cùng mức độ trưởng thành của người dùng, thay vì chỉ dừng ở các nội dung hướng dẫn cơ bản.

Ngữ cảnh một phần có thể làm câu trả lời kém hơn

Một phát hiện đáng chú ý khác liên quan đến cơ chế RAG. Về bản chất, RAG là kỹ thuật giúp mô hình AI tối ưu hóa câu trả lời bằng cách truy xuất các tài liệu liên quan từ nguồn dữ liệu nội bộ, thay vì chỉ phụ thuộc vào tri thức đóng băng sẵn có của mô hình.

Độ chính xác của quá trình truy xuất dữ liệu quyết định trực tiếp đến chất lượng đầu ra của AI. Nhằm tối ưu hóa độ liên quan, Elastic áp dụng phương thức tìm kiếm kết hợp (hybrid search), kết hợp giữa tìm kiếm văn bản truyền thống (lexical search) qua thuật toán BM25 và tìm kiếm ngữ nghĩa (semantic search) qua mô hình Elastic Learned Sparse EncodeR (ELSER).

Elastic chia kết quả truy xuất thành ba nhóm:

Kết quả phân tích cho thấy nhóm Helpful đạt điểm chất lượng trung bình 9,81/10, nhóm None đạt 9,18/10, trong khi nhóm Partial chỉ đạt 8,15/10.

Điều này đồng nghĩa với việc: nạp vào hệ thống một ngữ cảnh thiếu sót đôi khi mang lại kết quả tệ hơn việc không cung cấp bất kỳ context nào. Khi mô hình tiếp nhận tài liệu mang tính liên quan mờ nhạt, nó vẫn có xu hướng bám chặt vào thông tin đó để suy luận. Hệ quả là câu trả lời dễ bị chệch hướng hoặc sinh ảo giác (hallucination) do dựa trên một nguồn ngữ cảnh không đạt chuẩn.

Bài học ở đây là việc cấu hình ngưỡng truy xuất tối ưu có vai trò quan trọng hơn nhiều so với số lượng tài liệu trả về. Một hệ thống luôn trả về top 10 tài liệu, bất kể mức độ liên quan cao hay thấp, có thể vô tình đưa context kém chất lượng vào prompt. Cách an toàn hơn là đặt threshold rõ ràng và cho phép hệ thống trả về None khi không có tài liệu nào đủ phù hợp.

Tại sao trạng thái không trả về kết quả lại là dữ liệu đắt giá?

Trong phần lớn các hệ thống RAG, trạng thái không tìm thấy tài liệu phù hợp thường bị đánh giá là một lỗi hệ thống. Tuy nhiên, đối với Elastic, hiện tượng không trả về kết quả lại là một tín hiệu dữ liệu quan trọng.

Nếu hệ thống luôn cố trả về một vài tài liệu, kể cả khi chúng chỉ liên quan lỏng lẻo, đội phát triển sẽ khó nhìn thấy những khoảng trống tri thức (knowledge gaps) thực tế trong hệ thống. Ngược lại, khi siết chặt ngưỡng truy xuất, các truy vấn trả về kết quả trống sẽ trực tiếp chỉ ra những mảng thông tin người dùng đang tìm kiếm nhưng hệ thống chưa được cập nhật.

Nhờ vậy, các lượt truy xuất không có kết quả sẽ tự động trở thành một roadmap định hướng phát triển nội dung tiếp theo. Thay vì bổ sung tài liệu một cách cảm tính hoặc phỏng đoán, đội ngũ phát triển có thể ưu tiên chuẩn hóa và làm giàu dữ liệu dựa trên nhu cầu thực tế của người dùng.

Dùng nhiều token không phải lúc nào cũng xấu

Một góc nhìn chuyên môn mới mẻ khác nằm ở cách đánh giá mức độ tiêu thụ token. Trong việc tối ưu hóa ứng dụng AI, số lượng token lớn thường bị coi là điểm nghẽn cần cắt giảm để tiết kiệm chi phí. Tuy nhiên, chỉ số thực tế từ Elastic lại chứng minh các phiên làm việc chuyên sâu (deep sessions) có mối tương quan thuận rõ rệt với chất lượng đầu ra và mức độ hài lòng của người dùng.

Những phiên tương tác vượt ngưỡng 50.000 token đạt điểm chất lượng trung bình 9,74/10, cao hơn mức trung bình toàn cục 9,45. Đặc biệt, 10 phiên có lượng token cao nhất, trung bình 583.000 token, đạt điểm chất lượng trung bình 9,8/10, trong đó 9 trên 10 phiên đạt điểm tuyệt đối.

Phân tích sâu hơn cho thấy các phiên dài thường đến từ kiến trúc sư hệ thống hoặc người dùng kỹ thuật đang dùng AI như một cộng sự chuyên môn. Những phiên này tiêu thụ nhiều token vì chúng xử lý các tác vụ kỹ thuật có giá trị cao, vốn có thể mất nhiều giờ nếu làm thủ công.

Vì vậy, trước khi áp dụng giới hạn tốc độ hoặc cắt giảm mức dùng token, các đội phát triển nên phân tích những phiên dài nhất để hiểu giá trị thực tế mà chúng tạo ra. Câu hỏi quan trọng không chỉ là làm thế nào để giảm token, mà là tác vụ đó đã tiết kiệm bao nhiêu thời gian và chi phí con người.

Elasticsearch Platform đóng vai trò gì?

Từ những bài học thực chiến kể trên, Elasticsearch Platform khẳng định vị thế hạt nhân trong kiến trúc AI agent ở môi trường vận hành thực tế, đặc biệt tối ưu cho các bài toán đòi hỏi năng lực tìm kiếm chuyên sâu, truy xuất kết hợp (hybrid retrieval), giám sát ngữ cảnh và phân tích log hệ thống ở quy mô lớn.

Elastic hiện đang chuẩn hóa và mở rộng phương thức tiếp cận này thông qua công cụ Elastic Agent Builder. Theo tài liệu của Elastic, Agent Builder là nền tảng AI hội thoại cho phép tạo các AI agent có khả năng trả lời câu hỏi và thực hiện hành động trên dữ liệu Elasticsearch bằng ngôn ngữ tự nhiên. Các agent này kết hợp linh hoạt năng lực suy luận của LLM, kỹ thuật prompt engineering, cùng các built-in tools và custom tools để truy vấn dữ liệu, đảm bảo các phản hồi đầu ra luôn được chặt chẽ vào cơ sở dữ liệu nội bộ của tổ chức.

Giá trị cốt lõi của một hệ thống AI không nằm ở số lượng câu hỏi trả lời mượt mà trong các kịch bản demo. Điều quan trọng là hệ thống có đủ khả năng đo lường, kiểm chứng và cải thiện liên tục hay không. Khi nhật ký tương tác được xử lý như một nguồn dữ liệu chiến lược, đội phát triển có thể nhìn thấy rõ hơn người dùng đang cần gì, quy trình truy xuất đang sai ở đâu và nguồn dữ liệu hỗ trợ cần được mở rộng theo hướng nào.

Kết luận

Câu chuyện hơn 1 triệu tin nhắn AI agent của Elastic cho thấy xây dựng AI trong môi trường sản xuất không chỉ là bài toán tích hợp mô hình ngôn ngữ lớn vào ứng dụng.

Đó là một hệ thống vận hành đầy đủ, gồm độ liên quan của truy xuất, nhật ký hệ thống, chỉ số chất lượng, phân tích hành vi người dùng và vòng phản hồi liên tục.

AI agent chỉ thật sự tạo giá trị khi đội phát triển có thể nhìn thấy điều gì đang diễn ra phía sau mỗi câu trả lời. Và để làm được điều đó, dữ liệu vận hành không chỉ là phần phụ trợ kỹ thuật, mà là nền tảng để cải thiện chất lượng AI theo thời gian.