Photon: Xây dựng Công cụ Truy xuất và Xếp hạng từ Đầu

Giới thiệu

Ngăn xếp tìm kiếm gốc AI của Perplexity truy xuất và xếp hạng các trang ứng viên, đưa ra nội dung có liên quan nhất để mô hình căn cứ câu trả lời của mình. Ban đầu, giai đoạn này chạy trên một công cụ mã nguồn mở mà chúng tôi đã điều chỉnh cho hệ thống của mình. Tuy nhiên, khi chỉ mục và khối lượng công việc của chúng tôi phát triển, chúng tôi đã gặp phải các giới hạn cứng về chi phí, độ trễ đuôi và thời gian phục hồi nút mà chúng tôi không thể giải quyết trong nền tảng bên thứ ba hiện có.

Để vượt qua những thách thức này, chúng tôi đã xây dựng Photon, một công cụ truy xuất và xếp hạng nội bộ mới. Điều này tiếp tục cách tiếp cận của chúng tôi trong việc xây dựng cơ sở hạ tầng tìm kiếm hỗ trợ AI từ đầu, giống như chúng tôi đã làm với CobbleDB, kho lưu trữ khóa-giá trị phân tán của chúng tôi để phục vụ các bản ghi trang và Search API của chúng tôi.

Photon sử dụng các định dạng dữ liệu nhỏ gọn để chỉ đọc và giải mã những gì mỗi truy vấn cần, với tính năng bộ đệm nhận biết lô và đọc bất đồng bộ để giảm quyền truy cập đĩa và thời gian chờ chồng chéo. Việc xây dựng chỉ mục chạy tách biệt với việc phục vụ truy vấn, cập nhật một nhóm phục vụ tại một thời điểm và làm nóng các bộ đệm của nó trước khi định tuyến các truy vấn trực tiếp đến đó.

Photon hiện cung cấp năng lượng cho chuỗi tìm kiếm của chúng tôi và cũng là nền tảng cho cài đặt sẵn nhanh mới cho API Tìm kiếm của chúng tôi, với độ trễ cho một lệnh gọi tìm kiếm duy nhất là 160 ms ở p50 và 230 ms ở p95. Trên sáu tiêu chuẩn công khai, cài đặt sẵn nhanh đã giảm chi phí ước tính cho mỗi tác vụ gồm mô hình cộng tìm kiếm xuống 68% trong khi vẫn duy trì chất lượng tác vụ tổng hợp tương đương với cài đặt sẵn mặc định. Chúng tôi phát hành nó hôm nay để các nhà phát triển có thể tiếp cận những cải tiến này.

Phóng to

Phóng to

Những gì công cụ truy xuất và xếp hạng yêu cầu

Đối với mỗi truy vấn, công cụ truy xuất và xếp hạng tìm kiếm một chỉ mục lớn, phân tán để chọn và sắp xếp một tập hợp nhỏ các trang có liên quan trong ngân sách độ trễ của ngăn xếp tìm kiếm. Hệ thống cũng phải giữ cho chỉ mục được cập nhật khi các trang mới đến và các trang hiệnมี thay đổi, mà không để công việc đó làm chậm các truy vấn trực tiếp.

Chúng tôi đã đánh giá một số tùy chọn mã nguồn mở và chọn một công cụ truy xuất và xếp hạng đa năng, trưởng thành đáp ứng các nhu cầu ban đầu của chúng tôi. Sau đó, chúng tôi đã điều chỉnh nó cho kiến trúc và khối lượng công việc của mình, duy trì độ trễ và thông lượng ổn định ở quy mô sản xuất.

Nơi hệ thống trước đây của chúng tôi còn thiếu sót

Chúng tôi đã duy trì nhánh của riêng mình để điều chỉnh công cụ cho chỉ mục đang phát triển của mình, nhưng việc giải quyết các hạn chế chính ngày càng đòi hỏi phải thiết kế lại các phần lớn của nền tảng. Một số ràng buộc tỏ ra khó giải quyết nếu không có những thay đổi cơ bản về kiến trúc:

1. Chi phí mở rộng quy mô. Cả số lượng tài liệu chúng tôi lưu trữ và lượng dữ liệu trên mỗi tài liệu mà chúng tôi cần truy xuất và xếp hạng đều tăng lên theo thời gian. Việc mở rộng quy mô này gây áp lực lên phần cứng của chúng tôi, đặc biệt là lượng RAM khả dụng. Để kiểm soát chi phí, chúng tôi cần các biểu diễn dữ liệu nhỏ gọn hơn và kiểm soát tốt hơn những gì ở lại trong bộ nhớ và những gì được đọc từ đĩa theo yêu cầu.

2. Độ trễ đuôi kém. Trên lưu lượng truy cập sản xuất, thời gian phản hồi p99 của hệ thống cũ là khoảng 800 ms. Tập dữ liệu vượt quá RAM khả dụng, vì vậy chúng tôi không thể sử dụng mlock để giữ hoàn toàn trong bộ nhớ. Truy cập dữ liệu không thường trú có thể kích hoạt các lỗi trang lớn, làm đình trệ quá trình thực thi truy vấn trong khi hệ điều hành đọc từ đĩa.

Công cụ này cũng định kỳ hợp nhất chỉ mục đĩa chính của nó với các chỉ mục nhỏ hơn được xả từ bộ nhớ. Trong quá trình hợp nhất chỉ mục đĩa này, số lượng lỗi trang thậm chí còn tăng cao hơn, với độ trễ p99 đạt khoảng 1,2 s trong 10-15 phút. Khi bộ đệm ấm dần lên, tần suất lỗi trang và độ trễ đều giảm, cho thấy rằng các lần đọc lạnh là nguyên nhân chính gây ra các đỉnh. Việc tải trước dữ liệu và làm ấm chỉ mục đã làm giảm các đỉnh nhưng chưa giải quyết thỏa đáng độ trễ đuôi cao.

3. Phục hồi và đồng bộ hóa kéo dài. Trong hệ thống trước đây, việc triển khai một cụm bổ sung và đồng bộ hóa dữ liệu của nó có thể mất hơn một tuần. Việc đồng bộ hóa cũng được yêu cầu khi thêm các nhóm nút để giữ các bản sao dữ liệu bổ sung hoặc phục hồi sau sự cố nút. Trong quá trình phục hồi, phần lớn các phản hồi tìm kiếm là một phần, điều này làm giảm điểm chất lượng câu trả lời cuối cùng.

Cuối cùng, chúng tôi kết luận rằng việc xây dựng từ đầu sẽ đơn giản và tiết kiệm chi phí hơn là tiếp tục điều chỉnh và duy trì bản nhánh của mình. Dựa trên kinh nghiệm vận hành hệ thống trước đây, một nhóm kỹ thuật nhỏ đã làm việc cùng với một nhóm các tác nhân mã hóa liên tục để xây dựng Photon.

Vị trí của Photon trong ngăn xếp tìm kiếm

Photon được thiết kế cho hai quy trình làm việc chính: phục vụ các yêu cầu tìm kiếm và tiếp thu các bản cập nhật từ quy trình xử lý.

Yêu cầu từ dịch vụ tìm kiếm cấp cao hơn đến với môi giới Photon thông qua bộ cân bằng tải. Môi giới chọn một nhóm phân mảnh và chuyển tiếp yêu cầu đến từng phân mảnh, theo dõi thời gian chờ và đưa ra các yêu cầu bổ sung khi cần.

Mỗi phân mảnh thực hiện truy xuất, xếp hạng ban đầu và xếp hạng giai đoạn thứ hai, sau đó trả lại các ứng viên tốt nhất của nó cho môi giới. Môi giới kết hợp các ứng viên này thành một danh sách được xếp hạng duy nhất và tìm nạp các trường tài liệu quan trọng cho các trang đã chọn từ các phân mảnh có liên quan. Sau đó, nó trả lại các kết quả này cho dịch vụ tìm kiếm cấp cao hơn, thu thập nội dung trang cần thiết để tác nhân tạo ra một câu trả lời có căn cứ.

Các bản cập nhật chỉ mục tuân theo một đường dẫn riêng biệt. Pillar, lớp xuất bản của chúng tôi, chuẩn bị dữ liệu và lưu trữ trong các bảng YTsaurus. Trình tạo chỉ mục chuyển đổi các bảng này thành các cấu trúc chỉ mục mà các phân mảnh có thể tải để tìm kiếm. Bộ điều khiển điều phối việc chuẩn bị dữ liệu, xây dựng chỉ mục và triển khai các phiên bản chỉ mục mới cho các nhóm phục vụ. Trước khi xử lý lưu lượng truy cập trực tiếp, mỗi phân mảnh phát lại các truy vấn tìm kiếm thực tế để làm ấm bộ đệm của nó.

Phóng to

Thiết kế Photon cho quy trình làm việc của chúng tôi

Ba lựa chọn thiết kế làm cho Photon phù hợp với khối lượng công việc của chúng tôi: biểu diễn dữ liệu nhỏ gọn, bộ đệm và đọc đĩa bất đồng bộ, và tách các bản cập nhật chỉ mục khỏi việc phục vụ truy vấn.

Biểu diễn dữ liệu cho việc truy xuất và xếp hạng

Việc truy xuất và xếp hạng truy cập dữ liệu tài liệu theo các cách khác nhau. Truy xuất từ vựng bắt đầu bằng các chuỗi truy vấn và tìm các tài liệu chứa chúng. Sau đó, việc xếp hạng cần thông tin chi tiết về từng tài liệu được chọn, bao gồm tần suất chuỗi và vị trí.

Photon sử dụng hai biểu diễn bổ sung để hỗ trợ các mẫu truy cập này. Một chỉ mục đảo ngược lưu trữ danh sách các tài liệu khớp cho mỗi chuỗi, được gọi là danh sách đăng bài, để hỗ trợ việc lựa chọn ứng viên. Các bản ghi trên mỗi tài liệu riêng biệt cung cấp dữ liệu cần thiết để xếp hạng. Chúng tôi cũng tối ưu hóa cách lưu trữ và duyệt qua danh sách đăng bài để cải thiện việc lựa chọn trong một ngân sách công việc cố định.

Các biểu diễn dữ liệu chuyên biệt cho phép chúng tôi lưu trữ dữ liệu khóa hiệu quả hơn. Một chỉ mục đảo ngược nhỏ gọn hơn làm giảm lượng dữ liệu được đọc hoặc di chuyển cho mỗi truy vấn, cải thiện độ trễ bằng cách loại bỏ các thao tác I/O không cần thiết. Các định dạng này cũng giúp kiểm tra xem một tài liệu có xuất hiện trong danh sách hay không mà không cần giải mã hoàn toàn, một thuộc tính mà logic duyệt của chúng tôi dựa vào để kiểm soát lượng công việc mà một truy vấn thực hiện dưới một ngân sách cố định. Việc tối ưu hóa các bản ghi trên mỗi tài liệu cho phép chúng tôi lưu trữ nhiều dữ liệu hơn trên mỗi tài liệu để xếp hạng, đồng thời giảm chi phí mở rộng quy mô liên quan đến hệ thống trước đó của chúng tôi.

Chỉ mục đảo ngược

Đối với mỗi chuỗi, chỉ mục đảo ngược lưu trữ một danh sách đăng bài. Các danh sách này có thể dao động từ một vài tài liệu đến hàng triệu, vì vậy không có định dạng đơn lẻ nào hoạt động tốt cho mọi danh sách. Photon chọn định dạng dựa trên số lượng tài liệu chứa chuỗi.

Danh sách ngắn sử dụng bản biểu diễn nội tuyến phù hợp trong một trang duy nhất và không yêu cầu bảng khối. Các danh sách dài hơn không khớp với định dạng nội tuyến được chia thành các khối bao gồm các phạm vi định danh tài liệu cố định. Biểu diễn của mỗi khối phụ thuộc vào mật độ của nó: các khối thưa thớt lưu trữ các mảng bù trừ định danh tài liệu được sắp xếp, trong khi các khối dày đặc sử dụng bitmap. Các khối thưa thớt sử dụng tìm kiếm phi nước đại, tiến bước theo các bước ngày càng lớn để bỏ qua các vùng của danh sách. Các khối dày đặc cho phép kiểm tra thành viên bằng cách tra cứu bit tương ứng với tài liệu.

Tần suất truy vấn của một chuỗi xác định vị trí danh sách đăng bài của nó được đặt trên đĩa. Các danh sách được truy vấn thường xuyên được lưu trữ gần nhau, tập trung dữ liệu nóng ở vùng lưu trữ nhỏ hơn. Trong mỗi danh sách, các tài liệu được sắp xếp theo tín hiệu hữu ích riêng để các ứng viên có triển vọng hơn xuất hiện sớm hơn.

Phóng to

Duyệt qua các danh sách trong ngân sách công việc

Việc lựa chọn ứng viên đòi hỏi phải duyệt qua các danh sách đăng bài để tìm các tài liệu có khả năng liên quan. Việc quét toàn bộ mọi danh sách rất tốn kém, vì vậy Photon sử dụng thuật toán giống WAND chỉ duyệt qua một số danh sách trong khi vẫn tính đến các kết quả khớp ở các danh sách khác.

Thuật toán chia danh sách thành hai nhóm. Các danh sách dẫn dắt tiến trình duyệt và đề xuất các tài liệu ứng viên. Các danh sách thăm dò đóng góp vào điểm số của những ứng viên đó nhưng bản thân chúng không tạo ra ứng viên.

Điểm số ứng cử viên kết hợp độ phủ chuỗi truy vấn có trọng số và đóng góp tần suất, với việc chuẩn hóa độ dài tài liệu và giới hạn mức tăng từ các chuỗi lặp lại. Photon trước tiên kiểm tra sự hiện diện của chuỗi trong các mảng và bitmap để giới hạn điểm số tối đa có thể của mỗi ứng cử viên. Nó chỉ đọc tần suất chuỗi chính xác cho các ứng cử viên vẫn có thể đáp ứng ngưỡng lựa chọn.

Quá trình lựa chọn sau đó tiến hành theo ba bước:

• Duyệt qua: Bắt đầu với yêu cầu nghiêm ngặt về độ phủ truy vấn. Nếu tìm thấy quá ít ứng viên, hãy lặp lại với yêu cầu được nới lỏng.
• Giữ lại: Các ứng viên được giữ trong một tập hợp có giới hạn sử dụng điểm số kết hợp độ phủ và tần suất. Khi các ứng viên hàng đầu được thu thập cải thiện, ngưỡng tiếp nhận tăng lên.
• Lựa chọn cuối cùng: Kết quả cuối cùng cho lần vượt qua được chọn từ tập hợp được giữ lại dựa trên điểm số tần suất. Mỗi trường chạy lượt vượt qua riêng và kết quả được hợp nhất bằng trọng số trường.

Thuật toán tạo ra một tập hợp ứng viên gồm các tài liệu có liên quan để được sử dụng trong việc xếp hạng thêm.

Phóng to

Docblob

Sau khi các trang ứng viên được chọn, giai đoạn xếp hạng cần tần suất chuỗi, độ phủ trường, cũng như vị trí và sự gần gũi của các lần xuất hiện. Việc lấy dữ liệu này thông qua chỉ mục đảo ngược sẽ yêu cầu các quyền truy cập rải rác trên nhiều cặp chuỗi-tài liệu. Trong Photon, chúng tôi lưu trữ một bản ghi nhỏ gọn cho mỗi tài liệu có tên là docblob chứa tần suất chuỗi, các trường mà một chuỗi xuất hiện và vị trí nó xuất hiện trong tài liệu. Do đó, việc xếp hạng một ứng viên chỉ yêu cầu một lần tra cứu cho mỗi tài liệu.

Định dạng được xây dựng để tránh giải mã nhiều hơn mức cần thiết. Trong docblob, các trường được nhóm theo trình phân tích văn bản. Mỗi nhóm lưu trữ một danh sách chuỗi được sắp xếp được mã hóa bằng Elias-Fano, do đó một chuỗi truy vấn có thể được tra cứu trực tiếp mà không cần mở rộng toàn bộ danh sách trước. Mặt nạ trường đánh dấu vị trí chuỗi xuất hiện, bộ đếm tần suất theo dõi tần suất và các vị trí thực tế nằm trong các biệt lập cho mỗi cặp chuỗi-trường được mã hóa dưới dạng độ lệch vị trí. Chỉ các khối cho các chuỗi thực sự khớp mới được giải mã, trong khi mọi thứ khác trong bản ghi vẫn ở định dạng nén.

Việc giải mã chọn lọc đó cho phép docblob hỗ trợ lưu trữ nhiều dữ liệu hơn cho mỗi tài liệu mà không làm tăng chi phí tương ứng. Việc tăng bản ghi không buộc phải thực hiện nhiều công việc hơn cho mỗi lần tra cứu, bởi vì việc xếp hạng chỉ chạm vào các phần liên quan đến các chuỗi khớp thay vì toàn bộ bản ghi.

Phóng to

Đọc theo lô và làm việc với bộ nhớ

Ngay cả với các biểu diễn dữ liệu hiệu quả hơn, RAM vẫn cạn kiệt trước các tài nguyên khác, vì vậy chúng tôi thường xuyên cần truy cập dữ liệu được lưu trữ trên đĩa. Photon sử dụng các lần đọc đĩa bất đồng bộ và bộ đệm được tối ưu hóa cho các lần đọc theo lô để tăng tốc các quyền truy cập này, cắt giảm thời gian chờ cho mỗi yêu cầu. Điều này góp phần cải thiện đáng kể độ trễ đuôi so với hệ thống trước đó.

Phóng to

Thời gian chờ đĩa chồng chéo

Xếp hạng đòi hỏi phải lấy được các đặc điểm của một trăm tài liệu nằm ở các phần khác nhau của tệp. Hệ thống trước đây của chúng tôi đã sử dụng mmap để ánh xạ tệp vào không gian địa chỉ ảo để nó có thể được đọc thông qua các con trỏ bộ nhớ. Tuy nhiên, việc truy cập một trang vắng mặt trong bộ nhớ vẫn yêu cầu đọc đĩa. Chuỗi phải đợi dữ liệu trước khi tiếp tục tính toán và thời gian chờ này cộng dồn khi quá trình cần đọc các bản ghi lạnh tuần tự.

Photon tận dụng thực tế là các offset của bản ghi được biết trước, do đó chúng ta có thể gửi nhiều lệnh đọc cùng một lúc. Quá trình này được quản lý bởi reactor: các chuỗi công việc chuyên dụng sẽ gửi các lô thông qua io_uring và chuyển dữ liệu chúng đọc được sang mã gọi. Mỗi chuỗi duy trì io_uring của riêng nó; các lô được gửi đến reactor ít tải nhất. Các bộ mô tả tệp được đăng ký trước và bộ đệm giúp giảm chi phí đọc lặp lại. Việc thực thi bất đồng bộ này cho phép thời gian chờ của một số thao tác chồng lên nhau, làm giảm độ trễ đuôi.

Giảm số lần truy cập ổ đĩa

Trước khi gửi các lệnh đọc, Photon kiểm tra toàn bộ lô trong bộ đệm trong bộ nhớ. Chỉ các yêu cầu cho các bản ghi bị thiếu mới chuyển đến đĩa; dữ liệu đọc sau đó điền vào bộ đệm.

Bộ đệm được thiết kế cho các lần đọc theo lô. Cụ thể:

• Không có phân bổ riêng biệt khi truy cập thành công. Thay vào đó, dữ liệu được sao chép vào bộ đệm được chuẩn bị trước bởi mã gọi.
• Không có việc mua khóa bởi trình đọc. Thay vào đó, nó kiểm tra phiên bản dữ liệu và thử lại nếu xung đột với một ghi.
• Nó sử dụng việc loại bỏ CLOCK, thay vì yêu cầu cập nhật danh sách LRU được chia sẻ cho mọi lần đọc.
• Nó sử dụng tính năng nạp trước bộ nhớ đệm CPU, trong đó siêu dữ liệu và dữ liệu cho các bản ghi sắp tới được yêu cầu trước.

Những tối ưu hóa này làm giảm độ trễ mà không làm giảm hiệu suất đối với khối lượng công việc mà chúng ta quan tâm.

Xây dựng và cập nhật chỉ mục tách biệt với việc phục vụ

Trong Photon, việc xây dựng chỉ mục và phục vụ truy vấn chạy trên các nút khác nhau. Các trình tạo chỉ mục chuyển đổi dữ liệu thành các cấu trúc lưu trữ sẵn sàng, trong khi các nút phục vụ đọc chúng và thực hiện truy xuất và xếp hạng. Kết quả là, việc xây dựng chỉ mục không cạnh tranh với các truy vấn tìm kiếm về CPU và các tài nguyên cho các tác vụ này có thể được mở rộng độc lập.

Sự tách biệt này giải quyết các nút thắt cổ chai về phục hồi và đồng bộ hóa hiện diện trong việc triển khai trước đó. Do việc xây dựng chỉ mục chạy bên trong cùng một cụm phục vụ các truy vấn, việc khôi phục một nút bị lỗi hoặc thêm một bản sao dữ liệu mới có thể có nghĩa là lập chỉ mục lại các tài liệu tại chỗ, một quá trình mất vài ngày và làm tăng các phản hồi một phần trong quá trình khôi phục. Photon loại bỏ sự kết hợp đó; các trình tạo chỉ mục chạy dưới dạng các tác vụ phân tán tạo ra các cấu trúc chỉ mục có phiên bản, sẵn sàng phục vụ độc lập với các nút phục vụ, do đó việc xây dựng phiên bản tiếp theo của chỉ mục không còn cạnh tranh với lưu lượng truy cập trực tiếp.

Phóng to

Chuẩn bị và xây dựng phân tán

Quá trình xây dựng bắt đầu bằng việc chọn các tài liệu cho chỉ mục hoạt động và tạo bản xuất nguồn. Bộ điều khiển ghi lại phiên bản nguồn, bảng đầu vào và số lượng phân mảnh dự kiến. Các tác vụ MapReduce trong YTsaurus chuẩn bị văn bản, siêu dữ liệu, phân đoạn, đặc điểm và các embedding được tính toán trước thành các bảng được tạo phiên bản được phân vùng theo phân mảnh. Mỗi trình tạo chỉ mục truyền trực tuyến bảng đã chuẩn bị, xây dựng các cấu trúc cho phân mảnh của nó và hợp nhất các phân đoạn văn bản. Chỉ mục sẵn sàng, cùng với mô tả về các thành phần của nó, được tải lên bộ lưu trữ đối tượng.

Số lượng phân mảnh và số lượng trình tạo chỉ mục chạy đồng thời được định cấu hình độc lập, vì vậy một bản dựng có thể chạy trong một vài đợt, hoặc nhiều máy có thể được phân bổ để làm việc song song. Việc chuẩn bị phân tán và các trình tạo chỉ mục song song cho phép xây dựng toàn bộ chỉ mục web trong một con số duy nhất tính bằng giờ, một cải tiến đáng kể so với hệ thống trước đó.

Triển khai phiên bản mới

Trước khi triển khai, bộ điều khiển kiểm tra xem chỉ mục mới đã sẵn sàng chưa. Nếu dữ liệu không đầy đủ, việc triển khai sẽ tự động bị chặn.

Khi có nhiều nhóm phục vụ, bộ điều khiển cập nhật từng nhóm một. Đầu tiên, nó loại bỏ một nhóm khỏi định tuyến môi giới và bắt đầu trên phiên bản chỉ mục mới. Trước khi phục vụ các yêu cầu, các phân mảnh trải qua một giai đoạn khởi động riêng dựa trên nhật ký tìm kiếm, giúp điền trước trạng thái ban đầu và làm cho việc chuyển sang lưu lượng truy cập thực tế mượt mà hơn. Sau khi khởi động, bộ điều khiển kiểm tra trạng thái chỉ mục và mức độ sẵn sàng, sau đó trả lại nhóm về định tuyến. Các nhóm khác tiếp tục phục vụ các yêu cầu trong thời gian này. Do trạng thái hoạt động được duy trì, việc khởi động lại không buộc bản dựng phải bắt đầu lại; bộ điều khiển có thể đính kèm lại vào quá trình chuẩn bị đang diễn ra, sử dụng lại kết quả sẵn sàng hoặc tiếp tục quá trình quay vòng bị gián đoạn từ bước đã lưu.

Thời gian cập nhật dữ liệu khác nhau giữa các lĩnh vực tìm kiếm. Đối với các lĩnh vực có yêu cầu độ tươi cao, việc phân phối tài liệu mất một số phút duy nhất. Một bản sao bổ sung của dữ liệu có thể được triển khai trong khoảng nửa giờ; các chỉ mục sẵn sàng được tải và đính kèm vào các phân mảnh mà không cần lập chỉ mục lại các tài liệu nguồn.

Phóng to

Di chuyển và xác thực trong ngăn xếp tìm kiếm của chúng tôi

Mục tiêu đầu tiên của chúng tôi là thay thế hệ thống cũ bằng một công cụ bảo tồn chức năng và chất lượng tìm kiếm đồng thời giảm thời gian phản hồi. Chúng tôi đã xác thực Photon theo các giai đoạn, bắt đầu bằng các bài kiểm tra tải có thể tái tạo và đánh giá chất lượng ngoại tuyến trước khi chuyển sang lưu lượng truy cập trực tiếp. Photon hiện cung cấp năng lượng cho việc truy xuất và xếp hạng trong ngăn xếp tìm kiếm sản xuất của chúng tôi, với thời gian phản hồi thấp hơn đáng kể so với hệ thống cũ.

Kiểm tra tải và đánh giá

Để kiểm tra hiệu suất, chúng tôi đã xây dựng một công cụ kiểm tra tải để phát lại các truy vấn từ nhật ký tìm kiếm của chúng tôi ở các tốc độ đến có thể định cấu hình. Nó so sánh các kết quả giữa các lần chạy và áp dụng các bài kiểm tra thống kê để đánh giá xem sự khác biệt hiệu suất được quan sát có nhất quán hay không. Riêng biệt, chúng tôi đã đánh giá Photon và hệ thống cũ trên cùng một tập dữ liệu trong hệ thống đánh giá ngoại tuyến nội bộ của mình để kiểm tra các sự suy giảm chất lượng.

Sau các bước kiểm tra này, chúng tôi đã gửi các truy vấn trực tiếp đến cả hai công cụ đồng thời bằng cách sử dụng lưu lượng truy cập ảo (shadow traffic). Điều này cho phép chúng tôi so sánh hiệu suất và kết quả của chúng trên khối lượng công việc sản xuất trước khi thay đổi công cụ nào phục vụ người dùng. Sau đó, chúng tôi đã bật Photon cho các tập hợp con nhỏ người dùng và dần dần mở rộng việc triển khai, theo dõi chất lượng và hiệu suất trong suốt quá trình. Phiên bản đầu tiên đã vượt qua quá trình kiểm tra chấp nhận mà không bị giảm sút chất lượng và chúng tôi tiếp tục triển khai cho đến khi Photon phục vụ toàn bộ lưu lượng sản xuất.

Các cải tiến được đo lường trong sản xuất

Trong quy trình làm việc sản xuất của chúng tôi, thời gian phản hồi p99 giảm từ khoảng 800 ms trong hệ thống cũ xuống khoảng 65 ms trong Photon. Phép đo này bao gồm tất cả các giai đoạn bên trong Photon, nhưng loại trừ các giai đoạn tiếp theo trong ngăn xếp tìm kiếm cấp cao hơn. Chúng tôi cũng không còn quan sát thấy các đỉnh độ trễ trước đây liên quan đến việc chuyển đổi các phiên bản chỉ mục.

Photon sử dụng ít hơn khoảng 20% máy chủ tương đương so với các nút nội dung của hệ thống cũ trong khi lưu trữ lượng dữ liệu gấp khoảng 2,5 lần trên mỗi tài liệu. Sau quá trình di chuyển, chúng tôi đã sử dụng dữ liệu bổ sung này để cải thiện chất lượng xếp hạng vượt ra ngoài hệ thống cũ.

Photon cũng làm giảm lượng dữ liệu phải duy trì trong bộ nhớ. Ghim cùng một tập dữ liệu Photon vào RAM bằng mlock sẽ yêu cầu lượng bộ nhớ thường trú gấp khoảng 4,6 lần so với lượng Photon hiện đang sử dụng.

Đánh giá cài đặt sẵn Search API nhanh

Chúng tôi cũng đã sử dụng Photon làm cơ sở cho một cài đặt sẵn nhanh mới cho API Tìm kiếm của chúng tôi, được thiết kế cho khối lượng công việc nhạy cảm với độ trễ. Theo các phép đo của chúng tôi, độ trễ cho một lệnh gọi tìm kiếm duy nhất đối với cài đặt sẵn nhanh là 160 ms ở p50 và 230 ms ở p95, thấp hơn hoặc tương đương với các con số tự báo cáo của các nhà cung cấp API Tìm kiếm khác, mặc dù các phân vị đuôi được báo cáo khác nhau.

Chúng tôi đã đánh giá cài đặt sẵn nhanh trên sáu điểm chuẩn tác nhân: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 và SEAL-Hard. Qua các đánh giá này, nó có chi phí mô hình cộng tìm kiếm tổng ước tính thấp nhất và điểm số tác vụ tổng hợp cao nhất trong số các cấu hình được thử nghiệm.

Cài đặt sẵn nhanh kết hợp Photon với việc xếp hạng được tối ưu hóa cho quy trình làm việc của tác nhân, mang lại hiệu suất tương đương với cài đặt sẵn mặc định với chi phí thấp hơn đáng kể. Tuy nhiên, nó đi kèm với sự đánh đổi về chất lượng tìm kiếm rộng hơn. Cài đặt sẵn nhanh sử dụng ít tính toán hơn để xếp hạng so với cài đặt sẵn mặc định. Trên các điểm chuẩn nội bộ bao gồm các truy vấn đuôi dài, độ phủ rộng và sự đa dạng kết quả, nó đạt điểm thấp hơn 0,24 điểm về mức độ liên quan và thấp hơn khoảng 3 điểm phần trăm về tính sẵn có của câu trả lời. Chúng tôi tin rằng đây là một sự đánh đổi hợp lý cho quy trình làm việc của tác nhân, vì lý luận và kiến thức của mô hình có thể giúp bù đắp cho sự khác biệt.

Phóng to

Chúng tôi khuyên dùng cài đặt sẵn nhanh cho các tác vụ tác nhân hàng ngày. Đối với các câu hỏi thách thức hơn hoặc mơ hồ ít nhạy cảm về thời gian hơn, cài đặt sẵn mặc định cung cấp chất lượng mạnh mẽ hơn, biện minh cho độ trễ và chi phí cao hơn của nó.

Kết luận

Chúng tôi đang đều đặn chuyển ngăn xếp tìm kiếm của mình sang cơ sở hạ tầng nội bộ dựa trên Rust. Việc thay thế công cụ mã nguồn mở bằng Photon, công cụ truy xuất và xếp hạng tùy chỉnh của chúng tôi, là bước mới nhất. Photon cung cấp cho chúng tôi quyền kiểm soát hoàn toàn đối với các biểu diễn dữ liệu, cách tổ chức các lần đọc và cách triển khai các chỉ mục mới, cho phép chúng tôi tối ưu hóa từng lớp cho khối lượng công việc của mình.

Photon đã cho phép tìm kiếm nhanh hơn trên các sản phẩm của Perplexity và cung cấp nền tảng cho cài đặt sẵn nhanh mới của chúng tôi trong API Tìm kiếm. Sau quá trình di chuyển, độ trễ truy xuất và xếp hạng p99 giảm từ khoảng 800 ms xuống 65 ms. Các định dạng dữ liệu nhỏ gọn của chúng tôi cũng cho phép chúng tôi lưu trữ lượng dữ liệu gấp 2,5 lần trên mỗi tài liệu, mang lại cho việc truy xuất và xếp hạng quyền truy cập vào thông tin tài liệu phong phú hơn.

Cài đặt sẵn nhanh mang lại độ trễ cho một lệnh gọi tìm kiếm duy nhất là 160 ms ở p50 và 230 ms ở p95. Trên sáu điểm chuẩn tác nhân được đánh giá, nó đã giảm chi phí ước tính cho mỗi tác vụ gồm mô hình cộng tìm kiếm xuống 68% so với cài đặt sẵn mặc định trong khi vẫn duy trì chất lượng tác vụ tổng hợp tương đương. Những kết quả này chứng minh lợi ích thực tế của cơ sở hạ tầng được thiết kế xoay quanh khối lượng công việc tìm kiếm của chúng tôi, cả cho các sản phẩm của Perplexity và cho các nhà phát triển xây dựng bằng API của chúng tôi.

Chúng tôi tiếp tục cải thiện hiệu suất và hiệu quả lưu trữ của Photon. Mục tiêu của chúng tôi là hỗ trợ chỉ mục lớn hơn và dữ liệu tài liệu phong phú hơn trên cùng một phần cứng trong khi vẫn giữ cho việc tìm kiếm nhanh chóng khi khối lượng công việc của chúng tôi tăng lên.

Trích dẫn

@online{perplexity2026Photon,
  author = {{Perplexity} and Maksim Morozov and Bogdan Savko and Ruslan Kovalev and Aleksei Bykov and Artur Zayats and Denis Bykov and Nikita Kireev and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Photon: Building a retrieval and ranking engine from scratch}},
  date = {2026-09-24},
  url = {https://www.perplexity.ai/hub/blog/photon}
}