Nén ngữ cảnh nhận biết truy vấn cho các đoạn trích tốt hơn

Mọi câu trả lời đều bắt đầu từ bằng chứng. Trong hệ thống tìm kiếm, bằng chứng này thường đến từ các tài liệu: tiêu đề, phần tóm tắt, đoạn trích (chunks) và đoạn văn bản (snippets) được chuyển làm ngữ cảnh cho mô hình câu trả lời hoặc tác nhân (agent).

Ngữ cảnh thô này chứa nhiều nhiễu. Ví dụ, một trang web có thể chứa thông tin cần thiết cho yêu cầu của người dùng, nhưng nó cũng có thể chứa các yếu tố gây xao nhãng. Các yếu tố gây xao nhãng này có thể xuất hiện cả ở phần thân chính và trong các thành phần phụ trợ, chẳng hạn như các phần văn bản điều hướng, quảng cáo không liên quan, siêu dữ liệu (metadata), v.v. Việc chuyển các yếu tố gây xao nhãng này sang một tác nhân ở hạ nguồn sẽ tạo ra ba vấn đề.

Thứ nhất, nó làm giảm độ chính xác. Ngay cả những mô hình mạnh mẽ nhất cũng có dung lượng hữu hạn. Các chuỗi thông tin dài không liên quan làm lãng phí dung lượng mô hình, dẫn đến hiện tượng “thối rữa ngữ cảnh” (context rot) làm suy giảm khả năng xử lý yêu cầu thực tế của người dùng. Kết quả là, câu trả lời cuối cùng có nhiều khả năng bỏ sót các sự kiện quan trọng, đánh giá quá cao thông tin kém chất lượng, hoặc đưa ra các khẳng định khó có cơ sở vững chắc từ nguồn.

Thứ hai, nó làm tăng độ trễ. Ngữ cảnh dài hơn đồng nghĩa với nhiều token hơn để mô hình hạ nguồn xử lý, đặc biệt là khi một truy vấn cần bằng chứng từ nhiều trang ứng viên. Mặc dù một phần chi phí độ trễ này phải gánh chịu ở giai đoạn điền trước (prefill), một chi phí đáng kể hơn nhiều lại nằm ở quá trình suy luận, khi các mô hình yêu cầu nhiều token suy luận hơn để xử lý ngữ cảnh không liên quan.

Thứ ba, nó làm tăng chi phí. Mọi token không cần thiết được chuyển đến mô hình đều khiến việc phục vụ yêu cầu của người dùng trở nên tốn kém hơn, vì cả việc sử dụng token đầu vào và token suy luận đều tăng lên cùng với ngữ cảnh chứa nhiều nhiễu. Các yếu tố gây xao nhãng không chỉ làm giảm chất lượng; chúng cuối cùng buộc bạn phải trả nhiều tiền hơn cho chất lượng kém đó.

Phóng to

Để đồng thời nâng cao độ chính xác, tốc độ và hiệu quả chi phí trên các ứng dụng của Perplexity và Nền tảng API, chúng tôi đầu tư mạnh mẽ vào việc cải thiện độ chính xác của ngữ cảnh. Một cách chúng tôi làm điều đó là thông qua việc tinh chỉnh các thuật toán tạo đoạn trích của mình. Chúng tôi coi việc tạo đoạn trích là một bài toán nén ngữ cảnh. Các mô hình tìm kiếm thông tin cụ thể không nhận được lợi ích từ các bản tóm tắt tổng quát hoặc các đoạn trích dẫn của tài liệu. Thay vào đó, chúng tôi cần phần thông tin nguồn nhỏ nhất, được trích xuất chính xác nhất để phản hồi yêu cầu của người dùng. Mọi thứ khác có thể và phải được loại bỏ.

Do đó, một đoạn trích tốt nên thực hiện ba điều sau:

Thúc đẩy độ chính xác bằng cách trình bày bằng chứng chính xác cần thiết để làm cơ sở cho phản hồi của mô hình.

Giảm độ trễ và chi phí bằng cách loại bỏ ngữ cảnh không liên quan trước lệnh gọi LLM.

Đảm bảo khả năng truy xuất nguồn gốc bằng cách duy trì độ trung thực của trích dẫn và giữ nguyên văn bản nguồn.

Tháng này, chúng tôi đã triển khai một trình tạo đoạn trích tiên tiến mới trong các ứng dụng và Nền tảng API của mình. Cốt lõi của mô-đun này là một mô hình nén ngữ cảnh nhận biết truy vấn (query-aware context compression model), mô hình này quyết định, đối với mỗi truy vấn và kết quả ứng viên, tập hợp con các khoảng (spans) cần được bảo tồn. Bài viết này mô tả cách tiếp cận của chúng tôi trong việc xây dựng và đào tạo mô hình nhằm đạt được hiệu suất hàng đầu cho tác vụ quan trọng này.

Đoạn trích dưới dạng nén nhận biết truy vấn

Nhiệm vụ đầu tiên là xác định chính xác tác vụ đó. Chúng tôi muốn mô hình này làm gì, và chúng tôi nên định nghĩa lược đồ đầu vào và đầu ra như thế nào?

Các phương pháp tạo đoạn trích thuộc về hai họ chính. Thứ nhất là dựa trên lựa chọn: tìm một cửa sổ, khối, câu hoặc đoạn văn có liên quan và chuyển nó xuống hạ nguồn. Thứ hai là dựa trên tạo sinh: yêu cầu mô hình viết một bản tóm tắt tập trung vào truy vấn từ trang.

Sự tập trung của chúng tôi vào độ chính xác, độ trễ và chi phí khiến lựa chọn thiết kế trở nên rõ ràng. Chúng tôi có thể loại trừ việc tạo sinh, vì việc tạo một bản tóm tắt mới cho mỗi trang làm giảm hiệu suất trên cả ba trọng tâm. Việc tóm tắt không phù hợp với lớp bằng chứng mà chúng tôi quan tâm. Nó có thể diễn giải lại nguồn, khiến việc căn chỉnh trích dẫn trở nên khó khăn hơn. Nó cũng có thể giới thiệu các từ ngữ không có sẵn trên trang, điều này rất rủi ro khi đoạn trích được sử dụng làm bằng chứng thay vì câu trả lời cuối cùng. Độ trễ và chi phí liên quan càng làm cho việc tạo sinh trở nên kém hấp dẫn hơn.

Thay vào đó, chúng tôi định nghĩa tác vụ của mình là nén trích xuất nhận biết truy vấn: tách các phần hữu ích của ngữ cảnh được truy xuất khỏi các phần gây xao nhãng. Cụ thể, mô hình của chúng tôi phải chấp nhận một truy vấn và kết quả ứng viên, đồng thời quyết định khoảng nào cần giữ lại (những khoảng hỗ trợ tốt nhất cho truy vấn) và khoảng nào cần loại bỏ (phần còn lại). Đầu ra của mô hình bảo tồn văn bản nguồn thay vì viết lại nó. Điều này giúp kết quả dễ trích dẫn hơn, dễ xác minh hơn và rẻ hơn khi chuyển xuống hạ nguồn.

Ví dụ, hãy xem xét truy vấn này và kết quả được truy xuất:

Phóng to

Đầu ra mô hình hợp lý có thể là chọn câu được in đậm: “Trong Comet, trợ lý có thể ...”.

Cách tiếp cận của chúng tôi tuân theo cùng một ý tưởng lớn như công việc nén ngữ cảnh trước đây như FliCo, Provence và LooComp, được điều chỉnh để tạo đoạn trích trong hệ thống tìm kiếm sản xuất. Quan trọng là, mô hình hoạt động như một giai đoạn chính xác sau giai đoạn truy xuất thô của chúng tôi. Như đã thảo luận trong bài viết Nghiên cứu Perplexity trước đây của chúng tôi, Giới thiệu API Tìm kiếm Perplexity, chúng tôi thiết kế các hệ thống truy xuất của mình hoạt động tự nhiên ở cấp độ dưới tài liệu (sub-document) hoặc đoạn trích, điều này đã cho phép chúng tôi cân bằng khá tốt giữa độ chính xác (precision) và độ thu hồi (recall). Việc giới thiệu mô hình nén ngữ cảnh nhận biết truy vấn thậm chí còn đẩy đường biên Pareto về độ chính xác - độ thu hồi ra xa hơn nữa.

Xây dựng và Đào tạo Mô hình Nén Ngữ cảnh

Chúng tôi phát triển mô hình của mình với ba cân nhắc chính: hiểu biết chung về truy vấn và ngữ cảnh, lựa chọn ở cấp độ câu chi tiết (fine-grained), và hiệu quả để phù hợp với ngân sách độ trễ cực kỳ khắt khe.

Kiến trúc mô hình

Chúng tôi sử dụng mô hình khuếch tán pplx (pplx-diffusion model) làm xương sống. Đây là cùng một dòng mô hình đằng sau pplx-embed-v1, và cả công việc học thuật trước đây của chúng tôi, Diffusion-Pretrained Dense and Contextual Embeddings, cùng với các điểm chuẩn sản xuất của chúng tôi đều xác nhận đây là một bộ mã hóa hai chiều mạnh mẽ cho các cặp truy vấn-ngữ cảnh. Một trong những thuộc tính quan trọng từ dòng mô hình này là ngữ cảnh hai chiều: mỗi biểu diễn token có thể tham chiếu toàn bộ truy vấn và toàn bộ ngữ cảnh ứng viên trước khi mô hình quyết định những gì nên được giữ lại.

Trên nền tảng xương sống này, chúng tôi đào tạo một phần đầu nén nhẹ (lightweight compression head) dự đoán phần nào của ngữ cảnh nên được giữ lại. Do không có quá trình tạo sinh nào liên quan, các dự đoán này được thực hiện song song trên toàn bộ ngữ cảnh. Tại thời điểm phục vụ, công cụ đoạn trích sẽ tổng hợp các dự đoán này ở cấp độ câu, áp dụng ngưỡng và cắt kết quả theo ngân sách token được yêu cầu.

Đường ống giám sát (Supervision pipeline)

Việc đào tạo bộ nén này đòi hỏi sự giám sát ở mức độ chi tiết phù hợp. Nhãn liên quan ở cấp độ tài liệu rõ ràng không phù hợp cho tác vụ nén trích xuất của chúng tôi. Để tạo ra dữ liệu đủ chi tiết cho học có giám sát, chúng tôi đã xây dựng một đường ống dán nhãn khoảng (span labeling pipeline) đánh dấu các khoảng bằng chứng có liên quan đến truy vấn, cùng với các khoảng gây xao nhãng cần được loại bỏ.

Đường ống của chúng tôi sử dụng thiết lập LLM-làm-trọng tài (LLM-as-a-judge). Cho trước truy vấn của người dùng và một trang web ứng viên kèm theo liên kết, tiêu đề và phần tóm tắt của nó, trọng tài trước tiên thực hiện việc hiểu truy vấn, phân tích truy vấn và tạo ra một danh sách các ý định có thể có của người dùng. Dựa trên các ý định này, trọng tài sau đó xử lý ngữ cảnh ứng viên và trả về các khoảng được sao chép nguyên văn từ văn bản, với một danh mục cho mỗi khoảng để làm cho các nhãn dễ kiểm tra hơn.

Sau đó, chúng tôi khớp các khoảng được trả về trở lại văn bản nguồn. Không có gì ngạc nhiên khi hầu hết các đầu ra của trọng tài đã là các bản sao chính xác: khớp chuỗi đơn giản đã thu hồi được 98% các khoảng. Việc bổ sung một bước khớp dựa trên biểu thức chính quy (regex) đơn giản đã nâng tỷ lệ thu hồi khoảng lên 100%. Điều này cung cấp cho chúng tôi các khoảng chi tiết, đáng tin cậy có thể được chuyển đổi thành sự giám sát giữ/loại bỏ ở cấp độ token.

Chúng tôi đã đánh giá đường ống giám sát này bằng cách sử dụng một tập dữ liệu nhỏ được tuyển chọn với các khoảng được dán nhãn thủ công, so sánh các mô hình trọng tài nhỏ hơn, các lời nhắc (prompts) khác nhau và các cấu hình bước khác nhau. Thiết lập có hiệu suất tốt nhất là đường ống hai giai đoạn: hiểu truy vấn trước, tiếp theo là dán nhãn khoảng có phân loại. Chúng tôi cũng đã xác thực tập hợp các khoảng được trích xuất thông qua các đánh giá có thể xác minh ở hạ nguồn như BrowseComp và SimpleQA, trong đó việc chỉ sử dụng các khoảng bằng chứng được giữ lại vẫn duy trì điểm số cao đồng thời giảm đáng kể các token đầu vào.

Sử dụng đường ống này, chúng tôi đã dán nhãn 750k cặp truy vấn-tài liệu và sử dụng các khoảng kết quả để đào tạo phần đầu nén với hàm mất mát cross-entropy nhị phân (binary cross-entropy). Quá trình này cho phép mô hình nén nhận biết truy vấn của chúng tôi giữ nguyên văn bản nguồn trong khi loại bỏ ngữ cảnh khó có khả năng giúp mô hình hạ nguồn phục vụ yêu cầu của người dùng.

Đảm bảo độ trễ thời gian thực

Nén ngữ cảnh nằm trước mô hình hạ nguồn, biến nó thành một thao tác chặn (blocking operation). Hơn nữa, mỗi lần nén phụ thuộc vào truy vấn. Do đó, đường dẫn trực tuyến phải chấm điểm các cặp truy vấn-ngữ cảnh cho mọi tài liệu ứng viên trong một giới hạn độ trễ khắt khe. Một mô hình nén chậm sẽ tự phản tác dụng, vì lợi ích độ trễ từ độ chính xác cao hơn bị xóa sổ bởi chính độ trễ nén. Đồng thời, một mô hình nén kém thông minh hơn sẽ đưa ra các quyết định kém hơn về những gì cần cắt và giữ lại.

Câu hỏi thực tế là chúng ta có thể loại bỏ bao nhiêu dung lượng mô hình một cách an toàn trước khi chất lượng nén bắt đầu suy giảm. Chúng tôi so sánh mô hình xương sống pplx-diffusion 28 lớp đầy đủ với các biến thể 11 lớp và 17 lớp được tạo ra bằng cách tỉa lớp (layer pruning) và nhắm mục tiêu vào đường dẫn tìm kiếm. Đối với mỗi biến thể, chúng tôi quét qua ngưỡng nén và đo lường hai đại lượng: số lượng token ngữ cảnh trung bình được gửi xuống hạ nguồn cho mỗi truy vấn, và tỷ lệ phần trăm bằng chứng hữu ích được bảo tồn sau khi nén.

Hình 2 hiển thị đường biên chất lượng - hiệu quả. Một mô hình tốt hơn khi nó di chuyển về phía trên bên trái: ít token hạ nguồn hơn với nhiều bằng chứng hữu ích hơn được bảo tồn. Mô hình 28 lớp cung cấp tham chiếu chất lượng. Mô hình 11 lớp thể hiện rủi ro của việc nén mô hình quá mức. Mô hình 17 lớp đã được tỉa đại diện cho một điểm trung gian: nó theo sát mô hình 28 lớp trong chế độ bão hòa, nhưng một khoảng cách nhỏ xuất hiện ở phần dốc của đường cong nơi hầu hết lưu lượng truy cập sản xuất hoạt động.

Để thu hẹp khoảng cách đó, chúng tôi áp dụng phương pháp chưng cất kiến thức cấp độ token (token-level knowledge distillation). Cách tiếp cận của chúng tôi là thông thường: chúng tôi bổ sung hàm mất mát tiêu chuẩn bằng một thuật ngữ cross-entropy mềm trên các dự đoán của mô hình giáo viên (teacher model), được trọng số bởi một hệ số chưng cất. Điều này là đủ để đưa mô hình học viên (student model) đạt mức tương đương, cho phép chúng tôi chuyển đổi hoàn toàn sang mô hình 17 lớp đã chưng cất trong môi trường sản xuất. Mô hình sản xuất mới này mang lại mức giảm 35-40% về độ trễ suy luận và giảm 40-45% về tổng lượng tính toán GPU mà không làm giảm chất lượng so với giáo viên 28 lớp. Độ trễ sản xuất đạt dưới 20 ms (p99): đủ nhỏ để thêm vào đường dẫn phục vụ trong khi giảm đáng kể tổng số token được chuyển đến mô hình câu trả lời.

Phóng to

Chất lượng và Hiệu quả Token

Chúng tôi sử dụng API Tác nhân (Agent API) của Perplexity làm nền tảng thử nghiệm để phân tích hiệu quả của việc nén ngữ cảnh. Chúng tôi đánh giá ba cài đặt sẵn (presets) của API Tác nhân:

Cài đặt sẵn ngữ cảnh “thấp” (low) giới hạn ngân sách token cho mỗi tập kết quả ở mức 1000 token.

Cài đặt sẵn ngữ cảnh “trung bình” (medium) giới hạn ngân sách token cho mỗi tập kết quả ở mức 4000 token.

Cài đặt sẵn ngữ cảnh “cao” (high) giới hạn ngân sách token cho mỗi tập kết quả ở mức 10000 token.

Cả cài đặt tiêu chuẩn, không nén và cài đặt nén đều được cấu hình để tôn trọng các ngân sách token này.

Tìm kiếm đa bước dựa trên tác nhân (BrowseComp)

Trước tiên, chúng tôi xem xét tác động của nén lên các quy trình làm việc tìm kiếm đa bước mang tính tác tử trên benchmark BrowseComp. Chúng tôi thực hiện đánh giá này bằng harness search_evals mã nguồn mở của mình. Việc chấm điểm là giống nhau trong tất cả các lần chạy, sử dụng prompt giám khảo LLM BrowseComp chuẩn của OpenAI BrowseComp LLM judge prompt.

Hai chiều quan tâm là độ chính xác của điểm chuẩn và việc sử dụng token. Quan trọng là, chúng tôi đo lường việc sử dụng token ở cấp độ truy vấn thay vì cấp độ bước riêng lẻ để đo lường tải token thực tế phát sinh trong vòng đời yêu cầu. Hình 3 cho thấy đường biên “điểm số - token”, điểm độ chính xác so với việc sử dụng token.

Phóng to

Nén mang lại một đường biên Pareto mới trên toàn diện. Đối với mỗi thiết lập, việc giới thiệu nén làm giảm mức sử dụng token ở cấp độ truy vấn từ 10% đến 70%, với mức tăng độ chính xác đạt từ 4 đến 4,81 điểm phần trăm. Việc giới thiệu nén cho phép ngay cả cài đặt sẵn “thấp” của chúng tôi vượt trội hơn so với cài đặt sẵn “cao” không nén, đồng thời giảm mức sử dụng token hơn ba lần.

Chúng tôi quan sát thấy rằng với việc nén, cài đặt “cao” mang lại độ chính xác cao hơn “trung bình” như chúng ta có thể mong đợi. Tuy nhiên, điều thú vị là nó đạt được điều đó với mức sử dụng token thấp hơn. Điều này tiết lộ một hiệu ứng tinh tế nhưng quan trọng của việc nén: với việc nén, ngay cả việc tăng kích thước ngữ cảnh cho mỗi bước cũng có thể cho phép mô hình thực hiện ít bước hơn để đi đến kết quả chính xác. Việc khám phá tính không đơn điệu này là một hướng đi đầy hứa hẹn cho công việc trong tương lai.

SimpleQA: tính thực tế đơn bước (single-step factuality)

BrowseComp nhấn mạnh nghiên cứu đa bước, nhưng nhiều quy trình làm việc trong sản xuất liên quan đến việc tra cứu thực tế đơn bước. Để xác định xem việc nén có giúp ích trong chế độ đơn bước hay không, chúng tôi cũng kiểm tra hiệu suất trên SimpleQA, một điểm chuẩn bao gồm 4.326 câu hỏi được trả lời trong một bước tìm kiếm duy nhất, thay vì một vòng lặp tác nhân.

Như trước đây, chúng tôi vẽ biểu đồ độ chính xác so với tổng số token trung bình cho mỗi tác vụ bằng cách sử dụng lời nhắc trọng tài chuẩn. Hình 4 hiển thị đường biên điểm số - token trong thiết lập đơn bước này. Mặc dù quy mô hiệu ứng được nén nhiều hơn trong thiết lập đơn bước, chúng tôi lại quan sát thấy rằng việc nén đồng thời cải thiện độ chính xác và hiệu quả trên tất cả các cài đặt sẵn, do đó giới thiệu một đường biên Pareto mới. Khi bật nén, cài đặt sẵn trung bình đạt độ chính xác 95% với mức trung bình chỉ 200 token cho mỗi tài liệu. Với độ dài tài liệu trung bình hơn 10.000 token, điều này thể hiện hiệu suất cấp độ biên với tỷ lệ nén lớn hơn 50.

Phóng to

Điều gì kết thúc trong các đoạn trích?

Những lợi ích ở hạ nguồn trong Mục 4.1 và 4.2 là từ đầu đến cuối (end-to-end). Để hiểu cách nén thay đổi các đoạn trích riêng lẻ, chúng tôi chạy một đánh giá riêng biệt sử dụng trọng tài LLM để phân loại mọi token của mọi đoạn trích được truy xuất vào một trong sáu danh mục:

Quan trọng (Vital): bằng chứng thiết yếu để trả lời truy vấn của người dùng.

Lạc đề (Off-topic): thông tin có thể hữu ích cho một mục đích khác nhưng không liên quan đến truy vấn hiện tại.

Quảng cáo (Ads): quảng cáo không liên quan làm xao nhãng việc trả lời truy vấn của người dùng.

Siêu dữ liệu (Metadata): siêu dữ liệu về nội dung của tài liệu.

Giao diện & điều hướng (UI & navigation): các phần tử hiển thị giao diện người dùng và điều hướng.

Trùng lặp (Duplicate): sự lặp lại của thông tin đã được kết hợp trước đó.

Đánh giá của chúng tôi chạy trên 1.000 truy vấn miền hỗn hợp từ tập xác thực của chúng tôi, so sánh ngăn xếp sản xuất với đường cơ sở giống hệt nhưng đã tắt tính năng nén. Như được hiển thị trong Hình 5, nén làm tăng tỷ lệ token quan trọng cho mỗi đoạn trích trung bình 63% so với đường cơ sở không nén. Chúng tôi quan sát thấy mức giảm tương ứng 29% các token không liên quan, với mức giảm đặc biệt mạnh ở giao diện/điều hướng (-58%), siêu dữ liệu (-46%) và quảng cáo (-43%). Những kết quả này xác nhận cơ chế cho các cải tiến chất lượng - hiệu quả được thảo luận ở trên: nén cải thiện hiệu suất trên cả hai chiều bằng cách tăng mạnh tỷ lệ tín hiệu trên nhiễu của từng đoạn trích riêng lẻ.

Phóng to

Hình 6 minh họa sự thay đổi này cho một truy vấn riêng lẻ. Đối với truy vấn “6 day old newborn milk intake per feeding” (lượng sữa trẻ sơ sinh 6 ngày tuổi bú mỗi lần), chúng tôi hiển thị cả đoạn trích cơ sở chưa nén và đoạn trích đã nén. Nén loại bỏ các danh mục nội dung không quan trọng và chỉ giữ lại thông tin cho ăn liên quan đến trẻ sơ sinh. Quan trọng là, nén loại bỏ thành công nội dung có thể nói chung là đúng chủ đề cho trang, nhưng lại lạc đề đối với truy vấn tập trung vào trẻ sơ sinh cụ thể này.

Phóng to

Kết luận

Các hệ thống AI dựa vào thông tin tín hiệu cao để phục vụ các yêu cầu của người dùng một cách thông minh và hiệu quả. Thông tin này phải được trình bày một cách chính xác nhất có thể để tối đa hóa mức độ liên quan đến từng yêu cầu. Các mô hình nén nhận biết truy vấn mới của chúng tôi thực hiện chính xác điều này bằng cách tối đa hóa bằng chứng đúng chủ đề cho mỗi đoạn trích và tích cực loại bỏ các yếu tố gây xao nhãng không liên quan.

Bằng cách triển khai các mô hình mới này trong ngăn xếp tìm kiếm của mình, chúng tôi có thể cung cấp các phản hồi nhanh hơn và tốt hơn cho những người phụ thuộc vào các sản phẩm và API của chúng tôi. Cách tiếp cận của chúng tôi tạo ra một bề mặt kiểm soát đơn giản, cho phép hệ thống của chúng tôi và khách hàng API tinh chỉnh mức độ nén để cân bằng giữa độ thu hồi, độ trễ và chi phí.

Tuyển chọn ngữ cảnh là một lĩnh vực đang phát triển, và còn rất nhiều việc phải làm để tối ưu hóa giá trị của từng token được sử dụng trong các hệ thống thông tin biên ngày nay. Chúng tôi đang tích cực làm việc để làm cho các kỹ thuật tuyển chọn ngữ cảnh của mình trở nên tốt hơn nữa thông qua cả cải tiến mô hình và kiến trúc hệ thống nhằm tận dụng mạnh mẽ hơn nữa các mô hình này.

Tài liệu tham khảo

N. Chirkova, T. Formal, V. Nikoulina, và S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. Được chấp nhận tại ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, và D. Kim. LooComp: Leverage Leave-One-Out Strategy to Encoder-only Transformer for Efficient Query-Aware Context Compression, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang, và D. Bykov. Diffusion-Pretrained Dense and Contextual Embeddings, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez, và G. Neubig. Learning to Filter Context for Retrieval-Augmented Generation, 2023. arXiv:2311.08377.

Trích dẫn

@online{perplexity2026QueryAwareContextCompressionForBetterSnippets,
  author = {{Perplexity} and Bo Wang and Hao Zhang and Ismail Gadzhiev and Kirill Priemko and Markus Krimmel and Nandor Licker and Vitalii Polshkov and Sarah Eslami and Louis Milliken and Maksim Gaiduk and Nikita Kireev and Jerry Ma},
  title = {{Query-aware context compression for better snippets}},
  date = {2026-05-14},
  url = {https://perplexity.coolkeypoint.com/hub/blog/query-aware-context-compression-for-better-snippets}
}