Cải tiến cho mọi mức nỗ lực của Agent API

Các mức nỗ lực trong Perplexity Agent API cho phép nhà phát triển chọn sự cân bằng giữa chi phí, tốc độ và chiều sâu nghiên cứu cho từng tác vụ. Kể từ hôm nay, mọi mức nỗ lực đều có chi phí thấp hơn cho mỗi truy vấn, trong khi chất lượng nghiên cứu cao hơn hoặc không đổi. Mức ultra mới hiện đã có cho các tác vụ nghiên cứu toàn diện và có phạm vi rộng nhất. Bất kỳ yêu cầu nào chọn mức theo tên, chẳng hạn như effort="fast", đều tự động nhận cấu hình đã cập nhật.

Xây dựng một tác nhân nghiên cứu nghĩa là phải chọn sự cân bằng phù hợp giữa chi phí, tốc độ và chiều sâu cho từng tác vụ. Các mức nỗ lực trong Agent API đưa ra quyết định đó thay cho người dùng. Mỗi mức là một cấu hình trọn gói xác định mô hình, ngân sách bước, cài đặt tìm kiếm và công cụ cho một loại tác vụ cụ thể. Perplexity đánh giá và cập nhật từng mức theo thời gian để mang lại kết quả nghiên cứu tốt nhất với chi phí bằng hoặc thấp hơn chi phí hiện tại.

Những cải thiện này đến từ hai loại thay đổi. Ngân sách, cách xử lý ngữ cảnh và trích xuất giúp giảm chi phí của mỗi lượt chạy, còn Skill, lựa chọn mô hình và các tác nhân song song giúp nâng cao hoặc duy trì chất lượng câu trả lời.

Hiệu suất của medium đã tăng từ 55% lên 77% trên BrowseComp và DSQA, trong khi chi phí giảm gần 90%. BrowseComp và DSQA là các điểm chuẩn nghiên cứu công khai; WANDR là điểm chuẩn của Perplexity gồm các tác vụ nghiên cứu dài, liên quan đến nhiều thực thể. xhigh thực hiện các công việc mang tính tác nhân như thực thi mã trong Sandbox, duy trì các vòng lặp sử dụng công cụ dài và làm việc với nhiều nguồn cùng lúc. xhigh giữ nguyên điểm WANDR ở mức 76,5% trong khi chỉ tốn khoảng 25% chi phí so với cấu hình tháng 8 năm 2026.

Một yêu cầu Nghiên cứu chuyên sâu có thể chạy hàng chục lượt tìm kiếm, đọc hàng trăm trang và kiểm tra bằng chứng trước khi trả lời. Mỗi hành động đó đều thêm token vào ngữ cảnh và thêm tiền vào hóa đơn. Nếu không có giới hạn, tác nhân sẽ tiếp tục thực hiện các hành động làm tăng chi phí và làm chật ngữ cảnh mà không cải thiện câu trả lời. Năm yếu tố tạo nên phần lớn chi phí đó:

Phân bổ ngân sách. Tác nhân có ngân sách cố định có thể hết bước và kết thúc lượt chạy sớm trước khi hoàn thành tác vụ. Ngược lại, tác nhân không có ngân sách cố định có thể tiếp tục chạy, phát sinh chi phí mà không cải thiện câu trả lời cuối cùng.
Chi phí phụ trội của ngữ cảnh. Kết quả tìm kiếm và các trang được tìm nạp mang theo bằng chứng, nhưng nếu không được kiểm soát, cửa sổ ngữ cảnh có thể nhanh chóng bị lấp đầy bởi thông tin không liên quan. Cửa sổ ngữ cảnh mang theo chi phí từ bước này sang bước khác và cửa sổ bị quá tải có thể làm giảm hiệu suất của tác nhân.
Lựa chọn quy trình làm việc. Các tác vụ khác nhau cần những cách tiếp cận khác nhau. Một lượt tra cứu một dữ kiện đơn lẻ, một câu hỏi đa bước và một cuộc khảo sát rộng các nguồn đều đòi hỏi những quy trình làm việc khác nhau. Khi tự mình lựa chọn, mô hình thường chọn một quy trình kém hiệu quả. Việc mô tả chi tiết mọi chiến lược hiện có trong lời nhắc của tác nhân không giải quyết được vấn đề này. Các chỉ dẫn bổ sung được mang theo dưới dạng token ở mỗi bước và theo thời gian, mô hình tuân theo từng chỉ dẫn kém ổn định hơn.
Lựa chọn mô hình. Chuyển sang một mô hình lớn hơn có thể không mang lại mức cải thiện hiệu suất tương xứng với chi phí tăng thêm. Các mô hình mới ra mắt kèm theo những tiêu đề nổi bật và điểm chuẩn được công bố. Tuy nhiên, mức tăng điểm chuẩn có thể bị nhiễm dữ liệu hoặc phản ánh tình trạng mô hình quá khớp (overfitting). Nếu không đánh giá trên các tác vụ thực tế, việc thay đổi mô hình có thể làm tăng chi phí mà không nâng cao chất lượng.
Mở rộng quy mô đa tác nhân. Một tác nhân đơn lẻ chỉ có thể tìm kiếm, đọc và suy luận qua một số lượng nguồn hữu hạn trong mỗi lượt chạy. Chạy song song nhiều tác nhân giúp cải thiện chất lượng ở những tác vụ khắt khe nhất, nhưng cũng làm tăng chi phí và gây thêm phức tạp nếu không được xử lý đúng cách.

Việc giải quyết từng thách thức này đã giúp giảm chi phí cho mỗi mức nỗ lực mà không làm giảm hiệu suất.

Mỗi mức nỗ lực có một ngân sách nghiên cứu cố định gồm ba thành phần:

Giới hạn bước: số lượt mà tác nhân có thể thực hiện
Lệnh gọi công cụ: giới hạn tổng số lệnh gọi công cụ trong một yêu cầu. Một bước có thể đưa ra nhiều lệnh gọi trên nhiều công cụ cùng lúc, vì vậy chỉ giới hạn số bước thì không kiểm soát được số lượng hành động diễn ra trong một bước.
Lời nhắc ngân sách: thông báo định kỳ về số bước còn lại, để tác nhân có thể ưu tiên và chừa chỗ để viết câu trả lời thay vì hết ngân sách giữa chừng.

Ngân sách là yếu tố đánh đổi cốt lõi: nhiều bước hơn đồng nghĩa với câu trả lời tốt hơn và mỗi bước đều phát sinh chi phí. Với openai/gpt-6-luna, việc tăng giới hạn bước từ 1 lên 15 giúp nâng độ chính xác trên BrowseComp + DSQA từ 41% lên 80%, trong khi chi phí mỗi truy vấn tăng từ 0,0017 USD lên 0,0152 USD, tức là chi phí gấp khoảng 9 lần để có điểm số gấp khoảng 2 lần.

Chỉ giới hạn số bước thì không kiểm soát được chi phí nghiên cứu. Với cùng ngân sách năm bước, openai/gpt-6.1-terra thực hiện nhiều lệnh gọi công cụ hơn openai/gpt-6-luna, vì các mô hình có năng lực cao hơn thường đưa ra nhiều lệnh gọi trong một bước. Các mức nỗ lực giới hạn cả lệnh gọi công cụ lẫn số bước. Với những mô hình này, giới hạn lệnh gọi công cụ cũng quan trọng không kém giới hạn số bước.

Mỗi mức nỗ lực điều chỉnh các giới hạn này, nhưng tác nhân cũng cần biết mình còn bao nhiêu bước và hành động để hoàn thành yêu cầu. Nếu không có thông tin đó, tác nhân có thể hết bước hoặc hết hành động và buộc phải trả lời trước khi quá trình nghiên cứu hoàn tất. Ngân sách được nêu rõ khi bắt đầu lượt chạy và lời nhắc sẽ xuất hiện khi tác nhân gần chạm giới hạn, nhờ đó vẫn còn chỗ để xác minh và đưa ra kết quả. Với mức high, lời nhắc bao gồm cả ngân sách bước và ngân sách lệnh gọi công cụ.

Hai tác nhân, một tác nhân có lời nhắc ngân sách và một tác nhân không có, được thử nghiệm trên một tác vụ BrowseComp nhằm xác định một bộ phim truyền hình thập niên 1990 khi được cung cấp tiểu sử của ba diễn viên. Tác nhân có lời nhắc đã tìm ra câu trả lời đúng khi chỉ dùng 13 trong số 40 bước của ngân sách. Tác nhân không có lời nhắc ngân sách đã dùng hết cả 40 bước và không tìm ra câu trả lời đúng. Vòng lặp của tác nhân đó kết thúc đột ngột và mô hình không biết về ngân sách nghiên cứu còn lại. Lời nhắc giúp tác nhân tập trung và ưu tiên các tài nguyên còn lại một cách hiệu quả.

Các tác vụ nghiên cứu chạy dài lấp đầy cửa sổ ngữ cảnh của mô hình bằng kết quả tìm kiếm, các trang được tìm nạp và ghi chú trung gian. Khi cửa sổ đầy, tác nhân buộc phải dừng làm việc.

Nén ngữ cảnh giúp các lượt chạy dài tiếp tục hoạt động mà không làm đầy cửa sổ ngữ cảnh. Khi ngữ cảnh vượt quá một ngưỡng, tác nhân thay thế toàn bộ công việc đã làm bằng một bản tóm tắt ngắn hơn về những gì đã tìm thấy và những gì còn lại, rồi tiếp tục.

Quá trình nén ngữ cảnh luôn giữ lại ba thứ trong ngữ cảnh: lời nhắc hệ thống, yêu cầu ban đầu và mọi Skill mà tác nhân đã tải. Sau mỗi lần nén, tác nhân nhận được hai chỉ dẫn ngắn. Chỉ dẫn thứ nhất là: “Tiếp tục làm việc cho đến khi hoàn thành tác vụ.” Điều này ngăn tác nhân coi bản tóm tắt là điểm dừng. Chỉ dẫn thứ hai cho tác nhân biết đã có bao nhiêu lần nén diễn ra, để tác nhân có thể lên kế hoạch cho các tác vụ nghiên cứu còn lại. Các lượt chạy dài luôn bám sát mục tiêu và kế hoạch ban đầu, đồng thời chi phí của các vòng lặp dài giảm xuống mà chất lượng không bị suy giảm.

Mỗi trang mà tác nhân đọc đều được thêm vào ngữ cảnh và tác nhân mang theo nội dung đó ở mọi bước tiếp theo. Một trang web chứa cả thông tin không liên quan đến câu hỏi, chẳng hạn như thanh điều hướng, nội dung soạn sẵn và các nội dung khác.

Thay vì đưa cho tác nhân toàn bộ trang, fetch_url trước tiên sẽ chạy một lượt trích xuất. Văn bản của trang được gửi đến một mô hình nhỏ hơn cùng với tác vụ hiện tại của tác nhân. Mô hình chỉ trả về những đoạn liên quan, được trích dẫn nguyên văn để tác nhân có thể dẫn nguồn. Trong một lần đánh giá, một trang dài 5.561 token đã được rút gọn còn 293 token, giải phóng không gian cho thêm ngữ cảnh liên quan.

Sử dụng fetch_url kèm trích xuất ở mức nỗ lực high đã giảm khoảng 50% số token đầu vào cho mỗi truy vấn. Trích xuất cũng cải thiện hiệu suất trên điểm chuẩn, đạt 88,0% với 0,073 USD mỗi truy vấn, so với 83,5% với 0,094 USD khi không có trích xuất.

Tìm kiếm trên web là trọng tâm của mọi yêu cầu nghiên cứu của tác nhân. Có ba thay đổi trong cách tác nhân tìm kiếm:

Nhiều ngữ cảnh hơn cho mỗi lượt tìm kiếm: Mỗi lượt tìm kiếm giờ đây trả về tối đa 4K token kết quả thay vì 2K. Tác nhân tìm thấy thông tin cần thiết nhanh hơn, nhờ đó số lượt tìm kiếm ít hơn và chi phí thấp hơn.

Công cụ tạo đoạn trích mới: Kết quả tìm kiếm nhận được các đoạn trích khớp với truy vấn hơn, nhờ đó tác nhân không bị quá tải bởi văn bản không liên quan.
Tìm kiếm nhanh: Với mức giá 1,00 USD cho mỗi 1.000 yêu cầu, Fast Search giúp giảm cả chi phí lẫn độ trễ cho mỗi lệnh gọi tìm kiếm.

Nhóm Perplexity Search liên tục cải thiện chất lượng truy xuất trên nhiều loại tác vụ. Các bản cập nhật gần đây đã mang lại cải thiện cho mã nguồn, tài liệu dành cho nhà phát triển, trang tham khảo, nội dung pháp lý và quy định.

Một số tác vụ cần chạy song song nhiều lượt tìm kiếm; số khác lại cần đọc kỹ một vài tài liệu dài.

Tuy nhiên, việc tải mọi quy trình làm việc vào lời nhắc hệ thống của tác nhân sẽ làm tăng chi phí phụ trội của ngữ cảnh và có thể khiến mô hình hoạt động kém trên các tác vụ đơn giản. Thay vào đó, các Skill được tổ chức thành một cây với cơ chế tiết lộ dần. Mô hình tải các Skill và chỉ dẫn liên quan trong khi làm việc, giữ thông tin không liên quan ngoài ngữ cảnh. Mỗi Skill chỉ tốn phần tên và mô tả cho đến khi mô hình quyết định Skill đó phù hợp với tác vụ và tải nó; lúc đó, toàn bộ chỉ dẫn được thêm vào ngữ cảnh và mô hình làm theo quy trình làm việc đã được quy định.

Để đo lường mức đóng góp của từng Skill, mỗi Skill được loại bỏ lần lượt để so sánh chất lượng và chi phí trên các tác vụ mà tác nhân cơ sở đã tải Skill đó. Các thử nghiệm loại bỏ (ablation) này cho thấy quy trình làm việc nào giúp ích cho tác nhân và chúng ảnh hưởng thế nào đến hiệu quả nghiên cứu.

Các lượt chạy điểm chuẩn WANDR dưới đây cho thấy tác nhân chọn đúng quy trình làm việc cho từng tác vụ cụ thể. Hướng dẫn wide-search và fanout được tải cho mọi tác vụ, phản ánh nhu cầu điều tra nhiều thực thể. People-search chỉ được tải cho 6% số tác vụ và chỉ khi câu hỏi liên quan đến con người.

Khi thử nghiệm một tác vụ WANDR khác, tác nhân đã tải Skill people-search với mẫu fanout để tìm các kỹ sư inference ở London. Tác nhân mở rộng 39 thuật ngữ vai trò thành 117 truy vấn, sau đó hợp nhất kết quả của lượt đầu tiên thành 43 hồ sơ riêng biệt để sàng lọc thêm. Skill people-search đã hướng dẫn tác nhân thực hiện bước mở rộng này mà không thêm ngữ cảnh không liên quan. Đoạn trích dưới đây được điều chỉnh từ tập lệnh của tác nhân; tên các hàm trợ giúp chỉ mang tính minh họa.

code1

text

Python

# roles contains the 39 role variants selected by the agent.
queries = []
for role in roles:
    queries.extend([
        {"query": f"Google DeepMind {role} London"},
        {"query": f"Google {role} London"},
        {"query": role, "company": "Google", "location": "London"},
    ])

results = pplx_sdk.search.people_many(
    queries, limit_per_query=50, concurrency=8
)

profiles = {}
for result in results:
    if not result.ok:
        continue
    for profile in result.result:
        if "linkedin.com/in/" not in profile.url:
            continue
        url = profile.url.split("?")[0].rstrip("/")
        previous = profiles.get(url, {})
        if url not in profiles or len(profile.summary or "") > len(
            previous.get("summary") or ""
        ):
            profiles[url] = {
                "url": url,
                "title": profile.title,
                "summary": profile.summary,
            }

Lưu điểm kiểm tra (checkpointing) là một quy trình làm việc khác giúp tác nhân xử lý các tác vụ chạy dài. Mẫu lưu điểm kiểm tra bắt nguồn từ lập trình xử lý theo lô. Khi một tập lệnh xử lý một danh sách dài, tập lệnh sẽ ghi từng kết quả xuống đĩa ngay khi có, thay vì giữ mọi thứ trong bộ nhớ cho đến cuối. Nếu tập lệnh gặp sự cố hoặc lỗi giữa chừng, sẽ không có gì bị mất: lượt chạy tiếp theo đọc những gì đã được lưu và tiếp tục từ chỗ đã dừng, chỉ thử lại các mục bị lỗi.

Trong một tác vụ WANDR khác, tác nhân phải sàng lọc hồ sơ của 188 kỹ sư. Tác nhân đã tải mẫu điểm kiểm tra (checkpoint) để ghi lại từng kết quả trong quá trình làm việc. Lượt đầu tiên trích xuất được 160 hồ sơ nhưng thất bại ở 28 hồ sơ. Khi chạy lại tập lệnh, tác nhân bỏ qua các hồ sơ đã được ghi lại và chỉ thử lại 28 hồ sơ còn lại. Nếu không có điểm kiểm tra, chỉ một bản ghi lỗi cũng đồng nghĩa với việc phải tìm nạp lại toàn bộ 188 hồ sơ.Đoạn trích Python đã điều chỉnh; đã lược bỏ các trang đầu vào, chỉ dẫn sàng lọc, lược đồ và phần import; tên các hàm trợ giúp chỉ mang tính minh họa.

code 2

text

Python

checkpoint = Checkpoint("research/profile-screening")
config = instruction + json.dumps(schema)
config_id = hashlib.md5(config.encode()).hexdigest()[:6]

def checkpoint_key(page):
    url_id = hashlib.md5(page["url_in"].encode()).hexdigest()[:10]
    return config_id + url_id

pending = [
    page for page in pages if not checkpoint.has(checkpoint_key(page))
]
for offset in range(0, len(pending), 20):
    batch = pending[offset : offset + 20]
    inputs = [
        json.dumps({
            "url": page["url_in"], "content": page["content"][:30_000]
        })
        for page in batch
    ]
    results = pplx_sdk.llm.extract_many(
        inputs,
        instruction=instruction,
        output_schema=schema,
        chunk_size=5,
        concurrency=4,
    )
    for page, result in zip(batch, results):
        if not result.ok or result.result.error:
            continue
        checkpoint.record(
            checkpoint_key(page),
            [{"url": page["url_in"], **result.result.result}],
        )

Điểm kiểm tra ghi lại các kết quả thành công; nó không tự khởi chạy các lần thử lại. Việc đưa chỉ dẫn và lược đồ vào khóa đảm bảo rằng khi tiêu chí sàng lọc thay đổi, quá trình xử lý lại sẽ được kích hoạt.

Không phải thử nghiệm nào cũng mang lại cải thiện về chất lượng và hiệu quả. Việc tải trước toàn bộ Skill vào tác nhân trước khi bắt đầu tác vụ đã được đánh giá. Trên BrowseComp và DSQA, việc tải trước làm tăng chi phí thêm 13%. Trên WANDR, nơi các quỹ đạo nghiên cứu dài hơn khiến nội dung truy xuất chiếm tỷ trọng lớn hơn trong token đầu vào, việc tải trước còn làm giảm điểm số. Những kết quả này ủng hộ việc tiếp tục sử dụng cơ chế tiết lộ dần (progressive disclosure).

Khi năng lực của mô hình tiến bộ, mô hình tốt nhất cho từng mức nỗ lực cũng thay đổi theo. Perplexity sử dụng một vòng lặp nghiên cứu tự động để theo dõi các thông báo ra mắt và tình trạng khả dụng của mô hình mới. Quá trình đánh giá được kích hoạt ngay khi một mô hình có thể truy cập được.

Khi một mô hình mới được phát hành, một tác nhân tự động sẽ đưa mô hình đó qua harness đánh giá. Tác nhân này quét qua các mức Suy luận, ngân sách bước, ngân sách lệnh gọi công cụ và cấu hình công cụ, rồi chấm điểm mọi lượt chạy về chất lượng và chi phí so với các mức nỗ lực hiện tại. Khi một lượt chạy bị suy giảm, tác nhân sẽ tìm hiểu nguyên nhân, điều chỉnh cài đặt và chạy lại quá trình đánh giá. Mô hình ứng viên chỉ thay thế mô hình hiện tại khi vượt trội về chất lượng với chi phí bằng hoặc thấp hơn.

Các điểm chuẩn công khai rất hữu ích, nhưng điểm số của chúng không phải lúc nào cũng phản ánh đúng hiệu quả trên các tác vụ thực tế. Ví dụ: biểu đồ dưới đây cho thấy một mô hình ứng viên đạt điểm cao hơn mức cơ sở 13,3 điểm trên BrowseComp nhưng lại thấp hơn nhiều so với các mức cơ sở tương ứng trên các tác vụ nghiên cứu nội bộ trong lĩnh vực doanh nghiệp, pháp lý và tài chính.

Một tác nhân đơn lẻ chỉ có thể bao quát một số lượng nguồn nhất định trong một vòng lặp. Với các tác vụ phức tạp, nhiều tác nhân làm việc song song, mỗi tác nhân phụ trách một phần khác nhau của vấn đề.

Tác nhân chính là tác nhân điều phối. Tác nhân này gọi spawn_agent để tạo các tác nhân con và giao cho mỗi tác nhân một nhiệm vụ cụ thể, tập trung. Mỗi tác nhân con chạy vòng lặp nghiên cứu riêng với ngữ cảnh tách biệt, sử dụng mô hình, công cụ và ngân sách bước của riêng mình. Các tác nhân con báo cáo kết quả cho tác nhân cha; tác nhân cha có thể giao cho tác nhân con một nhiệm vụ tiếp theo hoặc kiểm tra tiến độ của nó. Tác nhân điều phối và các tác nhân con trao đổi tin nhắn để chia sẻ bằng chứng, báo hiệu các trở ngại và điều chỉnh các bước tiếp theo. Khi có thông tin mới, tác nhân điều phối tinh chỉnh các nhiệm vụ đã giao và khi công việc hoàn tất, sẽ tổng hợp các kết quả thành một câu trả lời duy nhất.

Agent API hỗ trợ các vai trò tác nhân được xác định trước và tác nhân điều phối có thể tạo các tác nhân con với chỉ dẫn tùy chỉnh.

Mức nỗ lực ultra chạy song song ba tác nhân trên một tác vụ. Mỗi tác nhân nghiên cứu toàn bộ tác vụ một cách độc lập, từ đó thu được các bằng chứng khác nhau. Một tác nhân thứ tư hợp nhất các phát hiện, loại bỏ trùng lặp và viết câu trả lời cuối cùng.

Trên WANDR, ultra đạt 85,9% với 21,71 USD mỗi tác vụ. Đây là điểm số cao nhất trong số các cấu hình được thử nghiệm.

Các mức nỗ lực liên tục được đánh giá và cải thiện. Mức mà người dùng chọn quyết định mức độ nghiên cứu dành cho một tác vụ và chi phí của tác vụ đó. Ngân sách bước và ngân sách lệnh gọi công cụ, cùng với lời nhắc khi ngân sách sắp cạn, giúp các yêu cầu nằm trong ngân sách. Nén ngữ cảnh, trích xuất và đoạn trích tốt hơn giúp ngữ cảnh tập trung vào bằng chứng. Skill giúp chọn quy trình làm việc phù hợp với tác vụ, còn các tác nhân song song mở rộng phạm vi mà một vòng lặp có thể bao quát. Một vòng lặp đánh giá tự động chỉ chấp nhận mô hình mới khi mô hình đó cải thiện chất lượng nghiên cứu với cùng mức chi phí.

Mỗi mức nỗ lực sẽ tiếp tục phát triển khi các mô hình và cấu hình mới chứng minh được hiệu quả qua đánh giá. Gọi một mức theo tên sẽ tự động nhận những cải tiến đó; ghim một phiên bản sẽ giữ cố định cấu hình.

Dùng thử Agent API và so sánh các mức nỗ lực trên khối lượng công việc của riêng bạn. Tìm thông tin chi tiết về các mức nỗ lực trong tài liệu về mức nỗ lực của Agent API của chúng tôi.

Chi phí của nghiên cứu

Kiểm soát ngân sách nghiên cứu

Quản lý ngữ cảnh

Nén ngữ cảnh

Chỉ tìm nạp những gì quan trọng

Tìm kiếm web tập trung

Chọn đúng quy trình làm việc

Lựa chọn mô hình

Mở rộng quy mô đa tác nhân

Tiếp theo là gì