- OpenAI đã tự xây dựng tác nhân dữ liệu AI tùy chỉnh để phân tích hiệu quả cho hơn 3.500 người dùng nội bộ và 600PB dữ liệu
- Chỉ với câu hỏi bằng ngôn ngữ tự nhiên, hệ thống có thể tự động xử lý quy trình phân tích end-to-end từ khám phá bảng, chạy SQL đến xuất notebook và báo cáo
- Độ chính xác được đảm bảo bằng cách kết hợp 6 lớp ngữ cảnh gồm: sử dụng bảng, chú thích của con người, phân tích mã dựa trên Codex, tri thức tổ chức, bộ nhớ và ngữ cảnh runtime
- Hệ thống vận hành theo cấu trúc vòng lặp khép kín tự học, tự điều tra nguyên nhân và điều chỉnh cách tiếp cận khi kết quả trung gian bị sai
- Một hệ thống đánh giá có cấu trúc dựa trên Evals API giúp phát hiện sớm hồi quy chất lượng, đồng thời kế thừa nguyên trạng mô hình bảo mật và phân quyền hiện có để duy trì độ tin cậy
Vì sao cần tác nhân dữ liệu tùy chỉnh
- Nền tảng dữ liệu của OpenAI có hơn 3.500 người dùng nội bộ, 600 petabyte dữ liệu và hơn 70.000 bộ dữ liệu; vì vậy chỉ riêng việc tìm đúng bảng đã là khâu tốn thời gian nhất trong phân tích
- Có rất nhiều bảng tương tự nhau, nên rất khó phân biệt khác biệt giữa các bảng như có bao gồm người dùng đã đăng xuất hay không, hoặc các trường bị trùng lặp
- Ngay cả khi chọn đúng bảng, các vấn đề như join many-to-many, lỗi filter pushdown hay không xử lý null cũng có thể làm kết quả mất hiệu lực
- Nhà phân tích nên tập trung vào định nghĩa metric, kiểm chứng giả định và ra quyết định dựa trên dữ liệu, thay vì debug SQL
Tác nhân hoạt động như thế nào
- Được vận hành trên nền GPT-5.2
- Có thể truy cập từ các môi trường mà nhân viên đã quen dùng như tác nhân Slack, giao diện web, IDE, Codex CLI (tích hợp MCP), và ứng dụng ChatGPT nội bộ
- Có thể xử lý cả những câu hỏi phức tạp và mang tính mở
- Hiểu câu hỏi
- Khám phá dữ liệu
- Chạy SQL
- Phân tích và tóm tắt kết quả theo cách end-to-end
- Ví dụ: phân tích trong bộ dữ liệu taxi NYC để tìm cặp ZIP pickup-dropoff có độ biến thiên thời gian di chuyển lớn nhất
- Không đi theo script cố định mà tự đánh giá tiến độ của chính mình; nếu kết quả trung gian có vấn đề (ví dụ trả về 0 dòng do join hoặc filter sai), hệ thống sẽ điều tra nguyên nhân, điều chỉnh cách tiếp cận rồi thử lại
- Bao phủ toàn bộ workflow phân tích: phát hiện dữ liệu, chạy SQL, xuất notebook và báo cáo, tham chiếu tri thức nội bộ, tìm kiếm web và học dựa trên bộ nhớ
Cấu trúc các lớp ngữ cảnh
-
Layer 1: Sử dụng bảng (Table Usage)
- Neo theo metadata: sử dụng metadata của schema (tên cột, kiểu dữ liệu) để viết SQL, và dùng lineage của bảng (quan hệ bảng cha-con) để nắm bắt quan hệ giữa các bảng
- Suy luận truy vấn: thu thập các truy vấn trong quá khứ để tác nhân học cách tự viết truy vấn và các tổ hợp bảng thường được join với nhau
-
Layer 2: Chú thích của con người (Human Annotations)
- Chuyên gia miền viết mô tả được tuyển chọn cho các bảng và cột, nắm bắt những thông tin khó suy ra từ schema hay truy vấn cũ như mục đích, ngữ nghĩa, bối cảnh kinh doanh và các lưu ý đã biết
- Chỉ dựa vào metadata thì khó phân biệt các bảng, vì vậy hiểu cách bảng được tạo ra và nguồn gốc của nó là điều thiết yếu
-
Layer 3: Phân tích mã dựa trên Codex (Codex Enrichment)
- Trích xuất định nghĩa ở cấp độ mã của bảng để hiểu sâu hơn nội dung dữ liệu thực tế
- Cung cấp các sắc thái dựa trên sự kiện phân tích như tính duy nhất của giá trị, tần suất cập nhật dữ liệu của bảng, phạm vi dữ liệu (có loại trừ trường cụ thể hay không, mức độ chi tiết)
- Ngoài SQL, còn có thể nắm bắt ngữ cảnh sử dụng trong nhiều hệ thống dữ liệu khác nhau như Spark, Python
- Có thể phân biệt các bảng trông có vẻ giống nhau nhưng khác biệt cốt lõi (ví dụ: bảng có chỉ bao gồm traffic ChatGPT bên thứ nhất hay không)
- Ngữ cảnh này được cập nhật tự động, không cần bảo trì thủ công
-
Layer 4: Tri thức tổ chức (Institutional Knowledge)
- Thu thập bối cảnh doanh nghiệp từ Slack, Google Docs, Notion như các đợt launch, sự cố, codename nội bộ, định nghĩa chuẩn và logic tính toán của các metric quan trọng
- Vận hành một dịch vụ tìm kiếm thu thập tài liệu, tạo embedding, lưu trữ cùng metadata và quyền truy cập, đồng thời xử lý kiểm soát truy cập và caching ở runtime
-
Layer 5: Bộ nhớ (Memory)
- Khi tác nhân nhận được chỉnh sửa hoặc phát hiện sắc thái trong câu hỏi dữ liệu, nó sẽ lưu lại để bắt đầu từ một đường cơ sở chính xác hơn trong lần phân tích tiếp theo
- Mục tiêu của bộ nhớ là lưu giữ và tái sử dụng những chỉnh sửa, bộ lọc và ràng buộc không hiển nhiên mà các lớp khác khó suy ra
- Ví dụ: khi lọc một thử nghiệm phân tích cụ thể, cần matching đúng một chuỗi được định nghĩa trong cổng thử nghiệm; nếu không có bộ nhớ, hệ thống có thể mắc lỗi khi thử fuzzy string matching
- Khi có chỉnh sửa hoặc phát hiện mới trong quá trình học, tác nhân sẽ gợi ý lưu vào bộ nhớ; người dùng cũng có thể tự tạo và chỉnh sửa
- Phạm vi bộ nhớ được phân tách ở mức toàn cục và mức cá nhân
-
Layer 6: Ngữ cảnh runtime (Runtime Context)
- Khi không có ngữ cảnh sẵn có cho bảng hoặc thông tin đã cũ, hệ thống phát hành truy vấn trực tiếp tới data warehouse để kiểm tra schema và nắm dữ liệu theo thời gian thực
- Cũng giao tiếp với các hệ thống khác của Data Platform như dịch vụ metadata, Airflow, Spark để lấy ngữ cảnh dữ liệu bên ngoài warehouse
-
Pipeline offline hằng ngày và RAG
- Vận hành một pipeline offline hằng ngày để tổng hợp thông tin sử dụng bảng, chú thích của con người và thông tin tăng cường dựa trên Codex thành một biểu diễn chuẩn hóa duy nhất
- Ngữ cảnh đã được tăng cường sẽ được chuyển thành embedding bằng OpenAI Embeddings API rồi lưu trữ; khi truy vấn, hệ thống dùng RAG (Retrieval-Augmented Generation) để chỉ lấy ra ngữ cảnh liên quan
- Cách làm này giúp duy trì khả năng hiểu bảng nhanh và có thể mở rộng trên hàng chục nghìn bảng, đồng thời giữ độ trễ runtime thấp và dễ dự đoán
Thiết kế để suy nghĩ và cộng tác như một đồng đội
- Hỗ trợ khám phá lặp mang tính hội thoại thay vì câu trả lời one-shot, đồng thời giữ đầy đủ ngữ cảnh qua các lượt nên không cần giải thích lại từ đầu khi có câu hỏi tiếp theo hay đổi hướng
- Nếu tác nhân đang đi sai hướng, người dùng có thể can thiệp giữa chừng để chuyển hướng trong lúc phân tích
- Nếu chỉ dẫn không rõ ràng, hệ thống sẽ chủ động đưa ra câu hỏi làm rõ; nếu không có phản hồi, nó sẽ tiếp tục bằng các giá trị mặc định hợp lý (ví dụ 7 ngày hoặc 30 ngày gần nhất)
- Sau khi quan sát các mẫu phân tích lặp đi lặp lại, hệ thống đóng gói chúng thành workflow (instruction set) có thể tái sử dụng
- Ví dụ như báo cáo kinh doanh hằng tuần hoặc kiểm tra xác thực bảng
- Chỉ cần mã hóa ngữ cảnh và best practice một lần để đảm bảo kết quả nhất quán giữa người dùng
Khung đánh giá để cải thiện nhanh mà vẫn giữ được niềm tin
- Vì đây là tác nhân luôn tiến hóa nên độ lệch chất lượng có thể dễ dàng xuất hiện; nếu không có đánh giá có hệ thống thì hồi quy có thể diễn ra âm thầm
- Dựa trên OpenAI Evals API, nhóm xây dựng một tập câu hỏi-trả lời được tuyển chọn, trong đó mỗi câu hỏi đi kèm một truy vấn SQL "golden" được viết thủ công
- Câu hỏi ngôn ngữ tự nhiên được gửi tới endpoint tạo truy vấn, sau đó SQL được sinh ra sẽ được thực thi và so sánh với kết quả từ SQL kỳ vọng
- Không chỉ đối sánh chuỗi đơn thuần, hệ thống còn so sánh cả SQL lẫn dữ liệu kết quả rồi đưa vào grader của Evals để tạo ra điểm số cuối cùng và giải thích có tính đến độ chính xác và mức dao động chấp nhận được
- Việc đánh giá này đóng vai trò như unit test được chạy liên tục trong quá trình phát triển, đồng thời là lớp canary cho production để bắt hồi quy sớm
Bảo mật của tác nhân
- Hệ thống kết nối trực tiếp với mô hình bảo mật và kiểm soát truy cập hiện có của OpenAI, kế thừa và áp dụng cùng quyền hạn và guardrail ở lớp giao diện
- Mọi truy cập đều theo cơ chế pass-through; người dùng chỉ có thể truy vấn những bảng mà họ đã có quyền, và nếu không có quyền thì hệ thống sẽ thông báo hoặc fallback sang bộ dữ liệu thay thế
- Để đảm bảo tính minh bạch, hệ thống công khai quá trình suy luận: tóm tắt các giả định và bước thực thi cùng câu trả lời, đồng thời liên kết trực tiếp tới kết quả gốc của truy vấn đã chạy để người dùng có thể kiểm chứng mọi bước phân tích
Những bài học rút ra trong quá trình xây dựng
-
Lesson 1: Ít hơn là tốt hơn (Less is More)
- Ban đầu nhóm đưa toàn bộ bộ công cụ cho tác nhân, nhưng điều này gây nhầm lẫn do trùng lặp chức năng
- Những chức năng trùng lặp vốn hữu ích khi con người gọi thủ công lại gây mơ hồ cho tác nhân, vì vậy việc giới hạn và hợp nhất một số lệnh gọi công cụ đã cải thiện độ tin cậy
-
Lesson 2: Hướng dẫn mục tiêu, không phải lộ trình (Guide the Goal, Not the Path)
- Prompt quá chi tiết lại làm kết quả tệ hơn
- Vì chi tiết khác nhau ở từng câu hỏi, chỉ dẫn cứng nhắc có thể đẩy tác nhân vào sai hướng; cách tốt hơn là cung cấp định hướng ở mức cao và giao cho khả năng suy luận của GPT-5 chọn lộ trình thực thi
-
Lesson 3: Ý nghĩa nằm trong mã (Meaning Lives in Code)
- Schema và lịch sử truy vấn chỉ mô tả hình dạng của bảng và cách nó được dùng, còn ý nghĩa thực sự nằm trong đoạn mã tạo ra bảng
- Logic pipeline nắm bắt các giả định, bảo đảm độ mới của dữ liệu và ý đồ kinh doanh mà SQL hay metadata không thể hiện ra
- Bằng cách để Codex crawl codebase và hiểu cách bộ dữ liệu thực sự được xây dựng, hệ thống có thể trả lời chính xác về "bên trong có gì" và "khi nào có thể dùng" theo cách mà chỉ tín hiệu từ warehouse không thể làm được
Hướng đi tiếp theo
- Nhóm đang tiếp tục thúc đẩy khả năng xử lý câu hỏi mơ hồ, cải thiện độ tin cậy và độ chính xác thông qua xác minh mạnh hơn, đồng thời tăng cường tích hợp workflow
- Mục tiêu là hòa nhập một cách tự nhiên vào cách mọi người đang làm việc thay vì trở thành một công cụ riêng biệt
- Khi công nghệ nền tảng cho suy luận, xác minh và tự sửa lỗi của tác nhân tiếp tục được cải thiện, hệ thống cũng sẽ tiếp tục phát triển, và
sứ mệnh của nhóm là cung cấp liền mạch khả năng phân tích dữ liệu nhanh và đáng tin cậy trên toàn bộ hệ sinh thái dữ liệu của OpenAI
1 bình luận
Ý kiến trên Hacker News
Vấn đề lớn nhất là độ tin cậy và khả năng giải thích
Chúng tôi đã phát triển phân tích ngôn ngữ tự nhiên tại Veezoo suốt 10 năm, và cách tiếp cận Text-to-SQL đơn thuần không có khả năng mở rộng tốt
Khi CFO hỏi về doanh thu, một con số chỉ đúng 99% là vô nghĩa, và CFO cũng không thể tự mình kiểm chứng SQL
Vì vậy chúng tôi đặt một tầng trừu tượng là Knowledge Graph, nơi AI chuyển ngôn ngữ tự nhiên thành ngôn ngữ truy vấn dựa trên ngữ nghĩa rồi biên dịch nó thành SQL theo cách tất định
Theo chiều ngược lại, truy vấn ngữ nghĩa đó lại được chuyển thành phần giải thích bằng ngôn ngữ tự nhiên để người dùng có thể dễ dàng xác minh xem kết quả có đúng với ý định hay không
Logic nghiệp vụ tồn tại trong Knowledge Graph, và trình biên dịch đảm bảo mọi truy vấn đều tuân theo nó 100%
Cấu trúc chi tiết được tổng hợp trong tài liệu Veezoo Architecture
Điều tôi tò mò là các bạn quản lý bùng nổ độ lực lượng (cardinality explosion) như thế nào, và xử lý ra sao với các yêu cầu đa truy vấn phụ thuộc vào kết quả của truy vấn trước đó
Cần phải theo dõi được vào ngày nào truy vấn nào đã được dùng và nó đã được xác minh như thế nào
(Tất nhiên, prompt cũng là đối tượng cần quản lý phiên bản)
Tôi khá bất ngờ vì ví dụ đầu tiên hoàn toàn phi logic
Nếu cái này đã qua được bước kiểm duyệt của con người thì có lẽ nó do AI viết, và nếu vậy thì tôi nghi ngờ độ tin cậy của hệ thống
Liên kết ảnh có vấn đề
Bản desktop là prompt đúng,
còn bản mobile là prompt sai
Theo kinh nghiệm của tôi khi dùng nhiều hệ thống BI, kiểu AI agent này là một ca sử dụng gần như hoàn hảo
BI vốn dĩ phát sinh lỗi ở nhiều tầng — bản thân truy vấn có thể sai, hoặc cách diễn giải dữ liệu có thể sai
Khi hai thứ này cộng lại thì coi như đã bước vào một ‘thế giới giả lập’, nên thà để AI đảm nhận bước 1 còn hơn
Tôi đã hy vọng OpenAI giải quyết được vấn đề độ tin cậy, nhưng tiếc là chưa
Bước 0: lưu dữ liệu sai
Bước -1: hiểu sai ngay từ khâu mô hình hóa
Bước -2: quy trình kinh doanh đã sai ngay từ đầu
Vì thế tôi gọi nó là ‘nguồn sai lệch duy nhất’ thay vì ‘nguồn sự thật duy nhất’
Phần khó nhất là mở rộng niềm tin
Chúng tôi cũng đang xây thứ tương tự, và dù vòng lặp agent có tốt đến đâu thì cuối cùng vẫn cần các chỉ số chuẩn do con người tuyển chọn (canonical metrics)
Nếu không, người dùng không chuyên kỹ thuật sẽ đưa ra những quyết định rủi ro dựa trên SQL mà họ không thể kiểm chứng
Cách tiếp cận của chúng tôi là
Theo thời gian, phần lớn truy vấn sẽ dùng chỉ số chuẩn, và agent không còn là một công cụ tạo SQL đơn thuần mà trở thành một bộ định tuyến thông minh từ ý định → chỉ số đã xác minh
Hệ thống đánh giá golden SQL trong phần “di chuyển nhanh mà không phá vỡ niềm tin” cũng chứa cùng một insight
Bài viết liên quan được tổng hợp trong bài blog này
Nếu có nhiều con đường dẫn tới câu trả lời thì sẽ cho ra các kết quả khác nhau
LLM thường bịa ra những chỉ số vô nghĩa kiểu ‘xyz_index’, rồi người dùng thấy có vẻ hợp lý nên cứ thế dùng luôn
Theo tôi, tác động thực sự của AI lên việc làm của lập trình viên sẽ nằm ở chất lượng dữ liệu và tài liệu
Dữ liệu nội bộ của doanh nghiệp được tổ chức tốt đến đâu sẽ quyết định hiệu quả ứng dụng AI
Dữ liệu công khai thì đã gần cạn rồi, và nguồn tài nguyên tiếp theo là tài liệu nội bộ, kho mã nguồn và data lake
Những công ty có nền tảng này tốt sẽ có thể tạo và duy trì dịch vụ mới bằng AI nhanh hơn và rẻ hơn
Ngược lại, các công ty có tài liệu và quản lý mã nguồn lộn xộn thì AI sẽ không vận hành tử tế được
Cuối cùng họ sẽ để đối thủ lấy mất thị trường
Vì vậy khi tìm việc sau này, tôi định sẽ nhất định hỏi về mức độ quản lý tài liệu, dữ liệu và kho lưu trữ
Amplitude cũng đã xây một hệ thống tương tự tên là Moda
Vài tháng trước, Wade đã cho Claire Vo xem video demo, thật sự rất ấn tượng
Tôi dùng nó hằng ngày để đặt đủ loại câu hỏi
Chúng tôi cũng cung cấp tính năng tương tự tại Definite.app chỉ trong 5 phút
Không cần Spark hay Snowflake
Chúng tôi cung cấp data lake, pipeline, semantic layer và data agent trong một ứng dụng duy nhất
Thực ra thứ khó hơn nhiều so với bản thân agent là xây dựng hạ tầng dữ liệu
Nếu agent chỉ có thể viết SQL thì giới hạn sẽ rất lớn, nhưng chúng tôi đã tạo ra một bước ngoặt lớn bằng cách cho phép nó quản lý chính hạ tầng đó
Nội dung thực sự rất hay
Tuy vậy, có vẻ vẫn thiếu phần giải thích kết quả được tính như thế nào
Với công cụ nội bộ của OpenAI thì giả định người dùng đọc được SQL là chấp nhận được, nhưng với người dùng không chuyên kỹ thuật thì đây là một thách thức lớn về mặt thiết kế
Chỉ cần từng làm việc với hệ thống dữ liệu là sẽ nhanh chóng nhận ra rằng, ‘câu trả lời’ quan trọng đến đâu thì ‘câu trả lời đó được suy ra như thế nào’ cũng quan trọng đến mức đó
Cá nhân tôi thấy In-House Data Agent của Kimi thú vị hơn
Vấn đề dữ liệu không phải là vấn đề kỹ thuật mà là vấn đề tổ chức
Theo kinh nghiệm của tôi, nguyên nhân của các vấn đề dữ liệu không nằm ở ‘chọn sai công nghệ’ mà nằm ở các quyết định về governance và quyền sở hữu
Cuối cùng thì mọi thứ đều quy về định luật Conway