Sử dụng các tiêu chuẩn đánh giá ngữ nghĩa để xây dựng tác nhân text-to-query tự cải tiến

Tác nhân chuyển văn bản thành truy vấn của chúng tôi đã giảm từ 45 giây trên các mô hình tiên tiến xuống còn 2 giây trên GLM 5.3 Flash, với độ chính xác tương đương nhưng chi phí chỉ bằng 1/20.

Phần lớn công việc AI gần đây của chúng tôi tại Conversion tập trung vào trí tuệ tiếp thị tổng quát.

Các nhóm tự động hóa tiếp thị thực hiện nhiều công việc khác nhau trên nhiều hệ thống: nghiên cứu tài khoản, xây dựng đối tượng, lập kế hoạch chiến dịch, viết nội dung và hành động dựa trên dữ liệu hiệu suất. Chúng tôi đã xây dựng các tác nhân có thể suy luận xuyên suốt các quy trình làm việc đó và sử dụng các công cụ giống như một chuyên gia tiếp thị lành nghề sẽ sử dụng.

Các hệ thống đó được hưởng lợi từ các mô hình đa năng, có năng lực. Công việc mang tính mở, và khả năng phán đoán tốt thường quan trọng hơn việc hoàn thành nhiệm vụ một cách nhanh chóng.

Nhưng chúng tôi cũng có một danh sách các tính năng AI nhỏ hơn, tập trung hơn cần xử lý. Một trong số đó là bộ lọc ngôn ngữ tự nhiên: cho phép người dùng mô tả một đối tượng bằng tiếng Anh đơn giản và chuyển mô tả đó thành bộ lọc mà họ có thể kiểm tra và chỉnh sửa trong trình xây dựng câu lệnh hiện có của Conversion. (Trong Conversion, bộ lọc được gọi là câu lệnh.)

Ban đầu, điều này có vẻ như một nhiệm vụ tạo cấu trúc đơn giản. Cung cấp cho mô hình các trường có sẵn, mô tả định dạng đầu ra và yêu cầu nó tạo ra JSON. Hóa ra nó khó hơn đáng kể so với tưởng tượng.

Câu lệnh tổng hợp được tạo trong vòng chưa đầy 5 giây bằng GLM 5.3 Flash.

Hãy xem ví dụ sau:

Tìm các liên hệ đã gửi biểu mẫu dùng thử ít nhất một lần trong 30 ngày qua và làm việc tại một công ty phần mềm có cơ hội mở trị giá hơn 50.000 đô la.

Điều này yêu cầu hệ thống phải:

• Tìm biểu mẫu cụ thể mà người dùng muốn nói đến với "biểu mẫu dùng thử"
• Xác định trường nào đại diện cho ngành của công ty
• Tìm hiểu cách không gian làm việc đó biểu diễn "phần mềm," điều này có nghĩa là xem xét các giá trị thực tế được lưu trữ trong trường đó thay vì phỏng đoán
• Đi từ một liên hệ đến công ty của nó và sau đó đến các cơ hội của công ty đó
• Đảm bảo rằng "mở" và "hơn 50.000 đô la" áp dụng cho cùng một cơ hội
• Áp dụng một cửa sổ sự kiện tương đối

Nó cũng cần phải thực hiện tất cả điều này đủ nhanh để tạo cảm giác như một giao diện bộ lọc, chứ không phải một tác nhân nghiên cứu.

Những gì có vẻ như một nhiệm vụ kỹ thuật prompt nhỏ đã trở thành một bài toán chuyển văn bản thành truy vấn có ràng buộc. Giải quyết nó đòi hỏi một tác nhân sử dụng công cụ, một biểu diễn trung gian (IR), một trình biên dịch xác định và một điểm chuẩn ngữ nghĩa.

Chúng tôi đã chạy tám mô hình thông qua điểm chuẩn kết quả, Statement Bench, bao gồm Claude Opus 5, Kimi K3, GLM 5.3 Flash và bản phát hành Gemini 3.8 Flash sáng nay. Kết quả ở bên dưới.

Cung cấp công cụ cho tác nhân

Hầu hết thông tin cần thiết để trả lời yêu cầu trên là cụ thể cho môi trường của khách hàng. Một không gian làm việc duy nhất có thể chứa hàng trăm triệu giá trị trường lịch sử, cùng với các tài sản và đối tượng của nó. Vì những lý do hiển nhiên, chúng tôi không thể đưa tất cả vào một prompt duy nhất.

Quyết định kiến trúc hữu ích đầu tiên của chúng tôi là ngừng coi vấn đề như một quá trình tạo cấu trúc thông thường. Thay vào đó, mô hình nhận được một bộ công cụ nhỏ. Nó có thể tìm kiếm các trường, kiểm tra các giá trị lịch sử và giải quyết các tài sản cụ thể của doanh nghiệp như biểu mẫu, chiến dịch, email và đối tượng. Nó chỉ sử dụng các công cụ đó khi yêu cầu cần đến chúng.

Phần lớn cơ sở hạ tầng tìm kiếm này đến từ công việc Global Search gần đây của chúng tôi, cung cấp tìm kiếm văn bản và ngữ nghĩa trên tất cả các bản ghi trong Conversion. Chúng tôi dự định sẽ chia sẻ thêm về điều đó sớm!

Luồng cơ bản trông như thế này:

1Yêu cầu ngôn ngữ tự nhiên
2          |
3          v
4   Tác nhân sử dụng công cụ  <-----------------+
5    /     |      \                             |
6trường  tài sản  mối quan hệ                   | từ chối kèm lý do
7    \     |      /                             |
8          v                                    |
9    IR có ràng buộc                            |
10          |                                    |
11          v                                    |
12 Trình xác thực và biên dịch ------------------+
13          |
14          v
15 Câu lệnh sản xuất

Điều này giữ cho ngữ cảnh ban đầu nhỏ. Nó cũng làm cho các lỗi dễ hiểu hơn nhiều. Nếu một câu lệnh sai, chúng tôi có thể xác định liệu tác nhân có tìm sai tài sản, chọn sai trường, hiểu sai mối quan hệ, biểu diễn ý tưởng đúng một cách không chính xác hay phát hiện ra lỗi trong trình biên dịch hay không. Sự khác biệt đó sau đó trở nên quan trọng cho vòng lặp đánh giá của chúng tôi.

Tạo ra một ngôn ngữ nhỏ hơn

Việc sử dụng công cụ đã giải quyết vấn đề ngữ cảnh. Nó không giải quyết được độ trễ.

Một bài học từ phản hồi ban đầu: người dùng chịu đựng độ trễ ít hơn nhiều trong một giao diện được xây dựng có mục đích so với trong chat.

Điều này chỉ ra một nghịch lý rộng hơn. Chúng tôi đặt kỳ vọng về độ trễ dựa trên mức độ khó khăn của một nhiệm vụ đối với chúng tôi, chứ không phải mức độ khó khăn đối với hệ thống. Viết nội dung có vẻ khó vì chúng ta có thể thấy công việc. Mô tả một bộ lọc có vẻ đơn giản vì tâm trí chúng ta âm thầm giải quyết ngữ cảnh, thực thể, mối quan hệ và ý định. Đối với mô hình, việc tái tạo lại những giả định ẩn đó là nhiệm vụ. Người dùng càng cảm thấy ít công việc, họ càng dành ít thời gian cho hệ thống để thực hiện nó.

Dựa trên phản hồi ban đầu, chúng tôi đặt hai mục tiêu: độ chính xác hơn 95 phần trăm và thời gian phản hồi khoảng 5 giây cho các truy vấn phổ biến.

Conversion có một ngôn ngữ truy vấn nội bộ biểu cảm. Trong các thử nghiệm ban đầu của chúng tôi, sử dụng trực tiếp định dạng sản xuất, chỉ các mô hình lớn nhất như Claude Opus mới có thể tạo ra nó một cách đáng tin cậy. Ngay cả các câu lệnh đơn giản cũng mất khoảng 45 giây.

Trình xây dựng câu lệnh trực quan chỉ hiển thị một tập con của ngôn ngữ đầy đủ. Chúng tôi đã tạo ra một biểu diễn trung gian nhỏ hơn, thân thiện với tác nhân cho tập con đó. Các mô hình nhỏ hơn có thể tạo ra nó bằng cách sử dụng ít token hơn, trong khi một trình biên dịch xác định xử lý định dạng sản xuất đầy đủ.

Hãy xem xét câu lệnh:

Chức danh công việc chứa "Giám đốc."

Câu lệnh sản xuất gốc trông như thế này:

1{
2  "type": "LOGICAL",
3  "version": 1,
4  "logical": {
5    "operator": "OR",
6    "operands": [
7      {
8        "type": "LOGICAL",
9        "version": 1,
10        "logical": {
11          "operator": "AND",
12          "operands": [
13            {
14              "type": "VARIABLE",
15              "version": 1,
16              "variable": {
17                "variableSchemaId": "550e8400-e29b-41d4-a716-446655440000",
18                "where": {
19                  "type": "LOGICAL",
20                  "version": 1,
21                  "logical": {
22                    "operator": "AND",
23                    "operands": [
24                      {
25                        "type": "LOGICAL",
26                        "version": 1,
27                        "logical": {
28                          "operator": "CONTAINS",
29                          "operands": [
30                            {
31                              "type": "ATTRIBUTE",
32                              "version": 1,
33                              "attribute": {
34                                "name": "value"
35                              }
36                            },
37                            {
38                              "type": "CONSTANT",
39                              "version": 1,
40                              "constant": {
41                                "value": "Giám đốc"
42                              }
43                            }
44                          ]
45                        }
46                      }
47                    ]
48                  }
49                }
50              }
51            }
52          ]
53        }
54      }
55    ]
56  }
57}

Biểu diễn hướng đến mô hình của cùng một bộ lọc là:

1{
2  "field": "550e8400-e29b-41d4-a716-446655440000",
3  "op": "contains",
4  "value": "Giám đốc"
5}

IR đã trải qua nhiều thế hệ, và thế hệ mới nhất được định hình bằng cách quan sát các mô hình nhỏ thất bại trên các thế hệ trước đó. Một cải tiến lớn là giới thiệu ngữ nghĩa cùng bản ghi tốt hơn (điều mà xác thực lược đồ không thể phát hiện):

1{
2  "related": "OPPORTUNITY",
3  "all": [
4    { "field": "<uuid giai đoạn>", "op": "equals", "value": "Đã thắng" },
5    { "field": "<uuid số tiền>", "op": "gt", "value": 100000 }
6  ]
7}

Sự phân chia giữa mô hình và mã này đã cho chúng tôi một vài thuộc tính hữu ích:

• Các câu lệnh không được hỗ trợ rất khó để diễn đạt
• Ngữ nghĩa mối quan hệ cùng bản ghi có thể nhìn thấy được
• Các tham chiếu trường và mối quan hệ có thể được xác thực
• Trình biên dịch có thể được kiểm tra độc lập với mô hình
• Các câu lệnh được tạo vẫn có thể chỉnh sửa trong giao diện người dùng hiện có

IR cuối cùng làm giảm công việc của mô hình: tác nhân giải quyết ý định của người dùng và tạo ra một kế hoạch có ràng buộc; mã xử lý định dạng sản xuất.

Xây dựng một điểm chuẩn ngữ nghĩa

Một đầu ra có thể hoàn toàn hợp lệ và vẫn sai. Hãy xem yêu cầu này:

Các liên hệ tại các công ty có cơ hội đã thắng trị giá hơn 100.000 đô la.

Một liên hệ thuộc về một công ty, và một công ty có thể có nhiều cơ hội. Khớp với bộ lọc này có nghĩa là đi qua các mối quan hệ (liên hệ đến công ty, công ty đến cơ hội) và kiểm tra hai điều kiện trên đường đi: thương vụ đã thắng và thương vụ trị giá hơn 100.000 đô la.

Khó khăn là các điều kiện đó phải đúng cho cùng một cơ hội. Nếu chúng được kiểm tra độc lập, một công ty có thương vụ đã thắng 20.000 đô la và một thương vụ mở 150.000 đô la thỏa mãn cả hai: mỗi điều kiện khớp với một thương vụ. Xác thực lược đồ sẽ không bao giờ phát hiện được điều này.

Khi một vài ví dụ như thế này đã vượt qua, việc chỉnh sửa prompt có nguy cơ làm chúng thoái lui. Chúng tôi cần một cách để kiểm tra ý nghĩa, không chỉ tính hợp lệ, và kiểm tra nó mỗi khi có điều gì đó thay đổi.

Chúng tôi đã xây dựng Statement Bench xoay quanh các hành vi của sản phẩm, bắt nguồn từ các mẫu đối tượng ẩn danh mà khách hàng của chúng tôi đã xây dựng trước đó. Bộ kiểm tra hiện có 100 trường hợp trên mười lăm danh mục như điều kiện trường đơn giản, sự kiện, cửa sổ thời gian tương đối và lịch, mối quan hệ và truy vấn tổng hợp.

Mỗi trường hợp chạy trên một hộp cát không gian làm việc thực tế. Tác nhân nhận được cùng dữ liệu và công cụ như trong sản xuất.

Trình đánh giá kiểm tra một số lớp:

1. Tác nhân có trả về một câu lệnh không?
2. IR có thỏa mãn lược đồ của nó không?
3. Các trường và mối quan hệ được tham chiếu có tồn tại không?
4. Câu lệnh có thể biên dịch và vượt qua xác thực sản xuất không?
5. Nó có biểu diễn ý nghĩa được yêu cầu không?
6. Nó yêu cầu bao nhiêu bước mô hình, cuộc gọi công cụ, token và số lần gửi bị từ chối?

Lớp thứ năm là thú vị nhất vì tính hợp lệ không đảm bảo sự tương đương về ngữ nghĩa.

Các kiểm tra ngữ nghĩa đọc câu lệnh đã biên dịch, khẳng định những điều như "một điều kiện cơ hội mang cả giai đoạn và số tiền," "một sự kiện email có loại là nhấp chuột, không phải mở," hoặc "một điều kiện hội thảo trực tuyến thay vì điều kiện chiến dịch tùy chỉnh."

Chạy một vòng lặp tối ưu hóa dựa trên đánh giá

Điểm chuẩn đã thay đổi cách chúng tôi có thể tiếp tục làm việc trên tính năng này. Thay vì yêu cầu một tác nhân mã hóa "cải thiện prompt" hoặc "triển khai một IR mới," chúng tôi có thể cung cấp cho nó một định nghĩa có thể thực thi về sự cải thiện.

Vòng lặp trông như thế này:

1. Chạy điểm chuẩn
2. Nhóm các lỗi theo nguyên nhân cơ bản của chúng
3. Kiểm tra quỹ đạo công cụ của tác nhân và IR đã gửi
4. Thay đổi prompt, công cụ, trình xác thực hoặc trình biên dịch
5. Chạy lại toàn bộ điểm chuẩn
6. Chỉ giữ lại thay đổi nếu nó cải thiện hệ thống mà không gây ra sự thoái lui

Các tác nhân mã hóa có thể sử dụng điểm chuẩn để so sánh các mô hình, thử nghiệm với IR, cải thiện mô tả công cụ và tinh chỉnh prompt một cách tự động. Chạy toàn bộ bộ kiểm tra sau mỗi thay đổi cũng giúp chúng tôi không bị quá khớp với các lỗi riêng lẻ, và chúng tôi đã giữ lại thêm 50 trường hợp để xác nhận điều đó.

Một vài thay đổi đã cải thiện kết quả nhiều nhất:

• Di chuyển đường dẫn, loại và cấu trúc vào trình biên dịch. IR đầu tiên của chúng tôi yêu cầu mô hình viết ra tất cả các mối quan hệ một cách rõ ràng: liên hệ đến công ty, công ty đến cơ hội. Siêu dữ liệu của trường đã ngụ ý đường dẫn đó, vì vậy trình biên dịch hiện suy luận nó. Chúng tôi đã làm điều tương tự cho ngày tháng, ép kiểu, vị trí phủ định và nhóm lồng nhau. Di chuyển các quy tắc vào trình biên dịch đã đơn giản hóa IR và giảm các lỗi lược đồ.
• Từ chối kèm giải thích và sửa lỗi. Mọi lần từ chối lược đồ và trình biên dịch đều cho biết nên viết gì thay thế (khi có sẵn): "không thể phủ định gt trên trường này; hãy sử dụng lte", "sao chép id từ campaign_list". Các mô hình nhỏ hội tụ sau một hoặc hai lần thử lại, và mô hình sản xuất bị từ chối trên một vài yêu cầu trên một trăm.
• Cấu trúc prompt cho các mô hình nhỏ. Việc tổ chức lại prompt không thay đổi độ chính xác, nhưng nó giảm một nửa số lần thử lại, điều này trực tiếp cải thiện độ trễ. Điều này được lấy cảm hứng từ Các phương pháp hay nhất về Prompt của Anthropic.
• Sử dụng ví dụ thay vì văn xuôi. Hai ví dụ bổ sung trong tài liệu tham khảo định dạng của chúng tôi đã giải quyết một loạt các thiếu sót mà các đoạn giải thích không làm được, cắt giảm khoảng một nửa số lần gửi bị từ chối.
• Cung cấp ngữ cảnh đầy đủ hoặc không có gì. Các mô hình với lấy những gì trong ngữ cảnh trước khi gọi một công cụ. Khi ngữ cảnh bao gồm một bộ trường một phần hoặc không được gắn nhãn, mô hình sử dụng trường gần nhất thay vì tìm kiếm, tạo ra các câu lệnh không chính xác về mặt ngữ nghĩa. Bằng cách giảm ngữ cảnh một phần để ưu tiên các cuộc gọi công cụ, chúng tôi đã tăng tỷ lệ xây dựng và cắt giảm một phần năm token đầu vào.

Cấu hình sản xuất cuối cùng, GLM 5.3 Flash, đã hoàn thành tất cả 100 trường hợp điểm chuẩn với độ trễ trung bình là 2,3 giây và phân vị thứ 95 là 7,1 giây. Và, 97 trong số 100 là đúng về mặt ngữ nghĩa. So với cách tiếp cận định dạng sản xuất ban đầu, các bộ lọc đơn giản đã giảm từ khoảng 45 giây xuống còn hơn một giây một chút với chi phí bằng 1/20.

So sánh các mô hình trên Statement Bench

Điểm chuẩn cũng cho chúng tôi một cách để so sánh các mô hình trên nhiệm vụ thực tế.

Vào ngày 2 tháng 9 năm 2026, chúng tôi đã chạy cùng 100 trường hợp trên tám mô hình. Mỗi mô hình nhận được cùng một prompt, công cụ, IR, trình biên dịch và thời gian chờ yêu cầu 30 giây.

Định tuyến nhà cung cấp, bộ nhớ đệm prompt và tải suy luận tạm thời đều ảnh hưởng đến độ trễ.

Mô hình

Bản dựng hợp lệ

Đúng ngữ nghĩa

Độ trễ P50

Độ trễ P95

Đọc bộ nhớ đệm

Cuộc gọi công cụ

Số lần gửi bị từ chối

Chi phí ước tính trên 1.000 yêu cầu

Claude Opus 5

100/100 (100%)

100/100 (100%)

3,16s

8,53s

91,1%

162

0

$27,51

GLM 5.2

100/100 (100%)

100/100 (100%)

4,38s

13,02s

93,5%

201

5

$14,94

Kimi K3

100/100 (100%)

100/100 (100%)

5,17s

11,84s

34,3%

157

0

$48,51

GLM 5.3 Flash

100/100 (100%)

97/100 (97%)

2,34s

7,07s

92,8%

163

2

$1,33

DeepSeek V4 Pro

96/100 (96%)

96/96 (100%)

5,53s

24,31s

47,8%

172

1

$12,00

Gemini 3.7 Flash

77/100 (77%)

77/77 (100%)

15,14s

30,01s

26,5%

228

1

$18,24

Gemini 3.8 Flash

76/100 (76%)

76/76 (100%)

14,29s

30,01s

35,4%

266

1

$27,44

DeepSeek V4 Flash

56/100 (56%)

55/56 (98%)

6,79s

30,00s

41,5%

100

1

$0,56

Chi phí ước tính trên 1.000 yêu cầu đã thử sử dụng các token đầu vào, đầu vào đã lưu trong bộ nhớ đệm và đầu ra quan sát được theo tỷ lệ không khuyến mại đã công bố của mỗi nhà cung cấp vào ngày 2 tháng 9 năm 2026. Đầu vào đã lưu trong bộ nhớ đệm được tính theo tỷ lệ đọc bộ nhớ đệm đã công bố nếu nhà cung cấp công bố tỷ lệ đó và theo tỷ lệ đầu vào đầy đủ nếu không.

Hình 1. Tính đúng đắn so với chi phí. GLM 5.3 Flash đạt 97 phần trăm với chi phí xấp xỉ một phần hai mươi so với Claude Opus 5.

Hình 2. Phân phối độ trễ, trung vị và phân vị thứ 95, được sắp xếp theo P95.

Một vài phát hiện nổi bật.

Cả kích thước mô hình lẫn giá cả đều không dự đoán được độ trễ. Mô hình nhanh nhất là mô hình nhỏ nhất và rẻ nhất. Mô hình nhanh thứ hai là mô hình lớn nhất và đắt nhất.

Lỗi đã chuyển từ câu trả lời sai sang câu trả lời chậm. Sáu trong số tám mô hình đều đúng về mặt ngữ nghĩa trên mọi câu lệnh chúng hoàn thành; sự khác biệt giữa chúng hầu như hoàn toàn nằm ở số lượng yêu cầu hoàn thành trong thời gian chờ. Trong các lần lặp đầu tiên của IR và prompt, hầu hết các mô hình nhỏ hơn đều thất bại trong điểm chuẩn ở bước xây dựng với độ chính xác ngữ nghĩa dưới 50%.

Token suy luận vượt xa các cuộc gọi công cụ. Gemini 3.8 Flash đã dành 180.000 trong số 192.000 token đầu ra của nó cho suy luận và thực hiện 266 cuộc gọi công cụ; Claude Opus 5 đã dành 813 token cho suy luận, thực hiện 162 cuộc gọi và hoàn thành mọi trường hợp. Các nỗ lực Global Search của chúng tôi đã giảm mỗi lần tra cứu công cụ xuống phạm vi mili giây, vì vậy chi phí còn lại là lượt của mô hình giữa chúng.

Kết luận

Các mô hình giỏi trong việc giải quyết sự mơ hồ, mã giỏi trong việc thực thi độ chính xác, và hầu hết các thất bại ban đầu của chúng tôi đến từ việc yêu cầu mô hình làm cả hai. Xây dựng tác nhân này là công việc quyết định cái nào trong hai cái nên sở hữu phần nào. Chúng tôi hy vọng điều tương tự cũng đúng với text-to-SQL và hầu hết các giao diện ngôn ngữ tự nhiên khác.

Nếu bạn quan tâm đến bất kỳ vấn đề nào trong số này, hãy liên hệ! Chúng tôi đang tuyển dụng.