Ngăn xếp nhúng của bạn buộc phải tái lập chỉ mục 100% chỉ để thay đổi mô hình. Và hầu hết các nhóm coi đó là điều không thể tránh khỏi. Hãy tưởng tượng bạn đã xây dựng một pipeline RAG với một mô hình nhúng lớn để có chất lượng truy xuất cao, và nó được đưa vào sản xuất. Sau sáu tháng, lưu lượng truy cập ứng dụng của bạn và chi phí mô hình nhúng của bạn đang tăng vọt trong khi pipeline của bạn gặp khó khăn trong việc mở rộng. Bạn muốn chuyển sang một mô hình ưu tiên chi phí và độ trễ để đáp ứng nhu cầu mới này. Nhưng các nhúng hiện tại của bạn sống trong một không gian vector, trong khi mô hình mới tạo ra các nhúng trong một không gian khác, điều này khiến chúng không tương thích. Việc chuyển đổi mô hình bây giờ có nghĩa là phải xây dựng lại chỉ mục: - Mỗi tài liệu cần được nhúng lại - Mỗi khối phải được tính toán lại - Hàng triệu vector phải được tái tạo trước khi các truy vấn hoạt động trở lại Hầu hết các nhóm nhìn vào điều này và quyết định hấp thụ chi phí thay vì chuyển đổi. Theo thời gian, điều này trở thành một quy tắc không được nói ra. Bạn hoặc tối ưu hóa cho chất lượng hoặc bạn tối ưu hóa cho chi phí, và bạn sống với quyết định mà bạn đã đưa ra sớm. Nhưng đây không phải là một giới hạn cơ bản của các nhúng. Đó là một lựa chọn thiết kế. Điều gì sẽ xảy ra nếu các mô hình nhúng chia sẻ cùng một không gian vector? Trong thiết lập đó, bạn có thể lập chỉ mục tài liệu bằng cách sử dụng một mô hình lớn và truy vấn chúng bằng một mô hình nhẹ hơn, mà không cần xây dựng lại bất cứ điều gì. ...