Perplexity dùng hàng trăm tác tử AI để hỗ trợ hai kỹ sư xây CobbleDB trong hai tháng. Công ty không cho các tác tử vận hành hệ thống chứa dữ liệu sản xuất. Kho khóa giá trị viết bằng Rust này giúp Perplexity giảm độ trễ đọc theo lô. Công ty dự kiến tiết kiệm ít nhất 20% so với DynamoDB, chưa tính chi phí nhân sự bảo trì.
Theo bài viết gốc của The New Stack, CobbleDB có khoảng 40.000 dòng mã. Sau khi chuyển đổi, Perplexity ghi nhận độ trễ trung vị khi đọc theo lô là 5,6 mili giây, so với 31,4 mili giây trên DynamoDB trước đó. Độ trễ p99 giảm từ 123 mili giây xuống 24,2 mili giây.
Các kết quả này phản ánh hệ thống của Perplexity trước và sau khi chuyển đổi. Đây không phải một thử nghiệm đối chứng trực tiếp giữa hai cơ sở dữ liệu. Hàng trăm tác tử AI tham gia viết mã và kiểm thử, còn hai kỹ sư vẫn kiểm soát kiến trúc, cấu hình vận hành và dữ liệu thực tế. Perplexity có kế hoạch công bố mã nguồn CobbleDB nhưng chưa xác định thời điểm.
Vì sao DynamoDB không còn phù hợp
Chi phí DynamoDB tăng theo luồng đọc và ghi của tải tìm kiếm tại Perplexity. Công ty cũng có ít quyền kiểm soát cách các bản sao xử lý lượt đọc theo lô. Một bản sao phản hồi chậm có thể khiến cả lô dữ liệu phải chờ.
Mỗi lượt tìm kiếm cần lấy các đoạn nội dung đã được chia sẵn cùng biểu diễn vectơ. Theo số liệu Perplexity cung cấp cho The New Stack, một lệnh gọi giao diện tìm kiếm lấy từ 100 đến 120 khóa trang, chia thành các lô từ 10 đến 20 khóa. Mỗi mục có dung lượng trung bình khoảng 50 KB.
DynamoDB cũng tính phí đối với luồng đọc và ghi lớn phát sinh liên tục từ hoạt động tìm kiếm, thu thập dữ liệu và xử lý lại nội dung. Khi lưu lượng và kho tài liệu tăng, Perplexity khó tiếp tục biện minh cho mức chi phí đó.
Công ty quyết định tách nơi lưu tài liệu dài hạn khỏi cơ sở dữ liệu phục vụ truy vấn trực tiếp. Đây là một ví dụ về cách doanh nghiệp điều chỉnh hạ tầng AI và quy trình vận hành theo tải công việc thực tế thay vì phụ thuộc hoàn toàn vào một dịch vụ được quản lý.
Ba tầng lưu trữ nội dung và dữ liệu phục vụ tìm kiếm
Ngăn xếp lưu trữ của Perplexity chia nhiệm vụ giữa Pillar, Lorry và CobbleDB. Pillar giữ trạng thái tài liệu lâu dài, Lorry đóng gói và chuyển các bản cập nhật, còn CobbleDB phục vụ những lượt đọc trực tiếp cần độ trễ thấp.
Pillar lưu dữ liệu trong YTsaurus trên ổ cứng, bao gồm siêu dữ liệu có phiên bản, các đoạn nội dung và biểu diễn vectơ. Lorry đóng gói bản cập nhật thành từng lô theo phân vùng, sau đó chuyển chúng qua S3 tới CobbleDB.
Theo mô tả kỹ thuật được The New Stack dẫn lại từ Perplexity, dữ liệu trang đã xử lý được phân bổ trên ba bản sao cho mỗi phân vùng. Địa chỉ trang sau khi băm được dùng làm khóa. RocksDB giữ dữ liệu thường xuyên được truy cập trong bộ nhớ, còn phần dữ liệu khác nằm trên thiết bị NVMe cục bộ.
Hệ thống ưu tiên giữ lượt đọc trong cùng một vùng sẵn sàng. Nếu một bản sao phản hồi chậm, bộ định tuyến có thể thử bản sao khác thay vì giữ toàn bộ lô chờ đợi. Các bản cập nhật đi qua S3 và được áp dụng độc lập, nên một bản sao có thể chậm hơn rồi tự bắt kịp mà không chặn hai bản sao còn lại.
Độ trễ đọc theo lô giảm xấp xỉ năm lần
Trong hệ thống của Perplexity, độ trễ trung vị khi đọc theo lô giảm từ 31,4 mili giây trên DynamoDB xuống 5,6 mili giây trên CobbleDB. Độ trễ p99 giảm từ 123 mili giây xuống 24,2 mili giây. Hai hệ thống không được đo đồng thời với cùng một lưu lượng.
Khi đo CobbleDB, Perplexity đang xử lý khoảng 200.000 yêu cầu mỗi giây. Trong thử nghiệm tải sau đó, công ty cho biết CobbleDB đạt 500.000 yêu cầu mỗi giây trước khi hiệu năng bắt đầu suy giảm.
Perplexity cũng chạy các phép thử tổng hợp với lô từ 10 đến 15 khóa, trong đó kích thước giá trị dao động từ 100 byte đến 100 KiB. Các số liệu này mô tả tải và cấu hình thử nghiệm của công ty, không phải mức hiệu năng áp dụng cho mọi hệ thống.
Số liệu DynamoDB được ghi nhận trước khi chuyển đổi, còn số liệu CobbleDB được đo sau đó. Vì vậy, kết quả cho thấy mức cải thiện trong hệ thống của Perplexity nhưng không phải một phép đối chiếu có kiểm soát giữa hai cơ sở dữ liệu.
Mô hình chi phí của Perplexity đặt CobbleDB thấp hơn DynamoDB ít nhất 20% trong các phương án cam kết được đánh giá. Ước tính này chưa bao gồm chi phí nhân sự để duy trì cơ sở dữ liệu tự xây. Các nhóm triển khai tác tử AI viết mã vì thế vẫn phải tách năng suất phát triển khỏi tổng chi phí sở hữu dài hạn.
Tác tử xây dựng, kỹ sư giữ quyền kiểm soát
Các tác tử AI hỗ trợ sửa mã, viết kiểm thử và duy trì ngữ cảnh qua nhiều phiên, nhưng không trực tiếp vận hành CobbleDB. Hai kỹ sư của Perplexity vẫn quyết định kiến trúc và kiểm soát hệ thống sản xuất vì sai sót liên quan đến dữ liệu thực tế có thể khó đảo ngược.
Trong quá trình sửa mã và viết kiểm thử, các tác tử phát hiện vấn đề liên quan đến giả định khôi phục dữ liệu và cấu hình khi chạy. Khả năng duy trì ngữ cảnh giúp chúng tiếp tục công việc qua nhiều phiên thay vì xử lý từng yêu cầu tách biệt.
Giáo sư Andy Pavlo tại Đại học Carnegie Mellon xem cơ sở dữ liệu là một trong những thử thách khó và quan trọng nhất đối với tác tử AI. Sai sót liên quan đến dữ liệu sản xuất có thể khó hoặc không thể đảo ngược. Cảnh báo này giải thích vì sao Perplexity giới hạn vai trò của tác tử ở khâu phát triển và kiểm thử.
CobbleDB đặt ra một ranh giới cụ thể: tác tử có thể hỗ trợ viết mã, duy trì ngữ cảnh, tìm lỗi và xây dựng kiểm thử; quyền thay đổi kiến trúc, cấu hình vận hành và dữ liệu thực tế vẫn thuộc về con người. Câu hỏi về mức quyền nên cấp cho AI cũng xuất hiện trong nhiều hệ thống nhạy cảm khác, từ cơ sở dữ liệu đến hoạt động an ninh và trung tâm điều hành bảo mật.
Quyền sở hữu đi kèm chi phí dài hạn
CobbleDB giải quyết nút thắt độ trễ trước mắt và được kỳ vọng giảm chi phí, nhưng chuyển trách nhiệm bảo trì từ nhà cung cấp dịch vụ sang Perplexity. Công ty phải tự xử lý sự cố, cập nhật hệ thống và duy trì đội ngũ kỹ sư trong suốt vòng đời của cơ sở dữ liệu.
Perplexity đưa CobbleDB vào sử dụng sau tám tuần. Theo The New Stack, mức tiết kiệm dự kiến ít nhất 20% chưa bao gồm nhân sự hỗ trợ hệ thống. Kết quả độ trễ cũng không đến từ một thử nghiệm đối chứng trực tiếp. Hai giới hạn này khiến lợi ích kỹ thuật ban đầu chưa thể đại diện cho toàn bộ chi phí sở hữu.
Perplexity vẫn sử dụng hạ tầng đám mây nhưng thay một dịch vụ được quản lý bằng hệ thống thiết kế riêng cho tải tìm kiếm. Trường hợp CobbleDB cho thấy phát triển có AI hỗ trợ có thể giúp một nhóm kỹ sư nhỏ xây hạ tầng chuyên biệt nhanh hơn. Nó không loại bỏ trách nhiệm vận hành và không trao cho tác tử quyền quyết định đối với dữ liệu sản xuất.
Hãy tiếp tục theo dõi Sine để xem các nhóm kỹ thuật phân chia công việc và quyền kiểm soát giữa kỹ sư với tác tử AI như thế nào.
