Cần thêm phản hồi LLM có liên quan? Giải quyết những thách thức về thế hệ tăng cường truy xuất này (Phần 1)

Trong phần đầu tiên của loạt bài gồm hai phần này, chúng ta sẽ xem xét các mô hình nhúng dưới mức tối ưu, chiến lược phân đoạn không hiệu quả và việc thiếu tính năng lọc siêu dữ liệu có thể khiến bạn khó nhận được phản hồi phù hợp từ LLM của mình như thế nào. Đây là cách để vượt qua những thách thức này.

Xây dựng các ứng dụng AI tổng quát sử dụng thế hệ tăng cường truy xuất (RAG) có thể đặt ra nhiều thách thức. Hãy xem xét cách khắc phục sự cố khi triển khai RAG dựa trên cơ sở dữ liệu vectơ để truy xuất ngữ cảnh có liên quan, sau đó đưa vào lời nhắc đến mô hình ngôn ngữ lớn để cung cấp kết quả phù hợp hơn.

Chúng tôi sẽ chia quá trình này thành hai phần chính. Vấn đề đầu tiên mà chúng ta sẽ đề cập đến trong bài viết đầu tiên của loạt bài này là đường dẫn nhúng, chứa trong cơ sở dữ liệu vector với các phần nhúng:

Ở đây, chúng ta sẽ xem xét ba lĩnh vực chính có thể dẫn đến kết quả kém: mô hình nhúng dưới mức tối ưu, chiến lược phân đoạn không hiệu quả và thiếu tính năng lọc siêu dữ liệu. (Trong bài viết sắp tới, chúng ta sẽ xem xét sự tương tác thực tế với LLM và xem xét một số vấn đề phổ biến nảy sinh ở đó và có thể dẫn đến kết quả kém.)

Chọn mô hình nhúng phù hợp

Việc bạn lựa chọn mô hình nhúng sẽ có tác động đáng kể đến mức độ liên quan và khả năng sử dụng tổng thể của ứng dụng RAG của bạn. Do đó, nó đòi hỏi sự hiểu biết sâu sắc về khả năng của từng mô hình và phân tích xem những khả năng đó phù hợp với yêu cầu ứng dụng của bạn như thế nào.

Nếu bạn chưa quen với RAG và các phần nhúng nói chung, một trong những tài nguyên tốt nhất bạn nên biết là Bảng xếp hạng nhúng MTEB (Điểm chuẩn nhúng văn bản lớn) . Chúng tôi tập trung vào các trường hợp sử dụng truy xuất trong bài đăng này, nhưng tất nhiên, phần nhúng có thể được sử dụng cho nhiều ứng dụng khác, bao gồm phân loại, phân cụm và tóm tắt.

Bảng xếp hạng có thể giúp bạn xác định các mô hình sẽ hoạt động tốt nhất cho trường hợp sử dụng cụ thể của bạn.

Một trong những lý do phổ biến nhất dẫn đến hiệu suất RAG kém là do các nhà phát triển mới tham gia vào lĩnh vực này thực hiện tìm kiếm trên Google để tìm các ví dụ về thế hệ nhúng. Họ thường thấy các mẫu sử dụng các mô hình nhúng như Word2Vec, sBERT và RoBERTa là những lựa chọn không phù hợp cho các trường hợp sử dụng truy xuất.

Nếu bạn tìm thấy bài viết này vì bạn đang gỡ lỗi cho các kết quả có mức độ liên quan kém và bạn đã sử dụng thứ gì đó như sBERT để tạo các nội dung nhúng thì có thể chúng tôi đã xác định được nguyên nhân gây ra vấn đề liên quan của bạn.

Nếu vậy, câu hỏi tiếp theo bạn có thể sẽ có là bạn có thể sử dụng mô hình nhúng nào để cải thiện kết quả tìm kiếm tương tự của mình. Nếu không biết chi tiết về trường hợp sử dụng của bạn, ba trường hợp chúng tôi khuyên dùng là:

nhúng văn bản-ada-002 (Ada v2)

Ada v2 từ OpenAI có lẽ là điểm khởi đầu phổ biến nhất cho hầu hết các ứng dụng RAG đơn giản vì rất nhiều nhà phát triển bắt đầu với API của Open AI. Ada v2 hoạt động rất tốt trong các trường hợp sử dụng truy xuất và được xây dựng để xử lý các loại nội dung khác nhau, bao gồm cả văn bản và mã.

Với độ dài chuỗi đầu vào tối đa lên tới 8.192 mã thông báo, nó cũng cho phép bạn tạo phần nhúng cho các đoạn văn bản dài hơn nhiều so với các mô hình thay thế. Đây là cả một phước lành và một lời nguyền.

Việc có kích thước chuỗi lớn giúp đơn giản hóa quá trình tạo phần nhúng cho nhiều nội dung văn bản hơn và cho phép mô hình nhúng xác định mối quan hệ giữa các từ và câu trong nội dung văn bản lớn hơn.

Tuy nhiên, điều này cũng dẫn đến các tìm kiếm tương tự có thể trở nên mờ nhạt hơn khi so sánh sự giống nhau của hai tài liệu dài khi nội dung bạn đang tìm kiếm là các đoạn ngữ cảnh có liên quan để hỗ trợ quá trình tạo.

Có hai nhược điểm lớn của Ada v2. Đầu tiên là nó không thể chạy cục bộ. Bạn phải sử dụng API của OpenAI để tạo phần nhúng. Điều này không chỉ có thể gây ra tắc nghẽn trong trường hợp bạn muốn tạo phần nhúng cho nhiều phần nội dung mà còn tăng thêm chi phí 0,0001 USD cho mỗi 1.000 mã thông báo.

Thứ hai là các phần nhúng được tạo từ mô hình AI mở có kích thước 1.536 mỗi phần. Nếu bạn đang sử dụng cơ sở dữ liệu vectơ đám mây, điều này có thể làm tăng đáng kể chi phí lưu trữ vectơ của bạn.

Khi nào nên chọn: Bạn muốn một giải pháp đơn giản chỉ yêu cầu lệnh gọi API, bạn có thể cần phải vector hóa các tài liệu lớn và chi phí không phải là vấn đề.

jina-nhúng-v2 (Jina v2)

Jina v2 là một mô hình nhúng nguồn mở mới cung cấp cho bạn khả năng hỗ trợ 8.000 chuỗi đầu vào tương tự như Ada v2 và thực sự đạt điểm cao hơn một chút trong các trường hợp sử dụng truy xuất.

Jina v2 cung cấp giải pháp giải quyết các vấn đề của Ada v2. Đó là nguồn mở theo Giấy phép Apache 2.0 và có thể chạy cục bộ, tất nhiên, đây cũng là một nhược điểm nếu bạn không muốn chạy mã của riêng mình để thực hiện việc này. Nó cũng tạo ra một vectơ nhúng có kích thước bằng một nửa Ada v2.

Vì vậy, bạn không chỉ nhận được hiệu suất truy xuất tốt hơn một chút trong các trường hợp sử dụng điểm chuẩn mà còn nhận được những kết quả được cải thiện đó với yêu cầu tính toán và lưu trữ thấp hơn từ góc độ cơ sở dữ liệu vectơ.

Khi nào nên chọn: Bạn muốn sử dụng giải pháp nguồn mở và có khả năng cần vector hóa các tài liệu lớn và cảm thấy thoải mái khi chạy các quy trình nhúng cục bộ. Bạn muốn giảm chi phí cơ sở dữ liệu vectơ bằng các phần nhúng có kích thước thấp hơn.

bge-large-en-v1.5

bge-large-en-v1.5 có nguồn mở theo giấy phép MIT và hiện là mô hình nhúng được xếp hạng hàng đầu trên bảng xếp hạng MTEB cho các trường hợp sử dụng truy xuất. Với chuỗi đầu vào nhỏ hơn, điều này sẽ yêu cầu bạn phải suy nghĩ nhiều hơn về chiến lược phân nhóm của mình nhưng cuối cùng vẫn mang lại hiệu suất tổng thể tốt nhất cho các trường hợp sử dụng truy xuất.

Khi nào nên chọn: Bạn muốn sử dụng giải pháp nguồn mở và sẵn sàng dành nhiều thời gian hơn cho các chiến lược phân đoạn để duy trì giới hạn kích thước đầu vào. Bạn cảm thấy thoải mái khi chạy các đường ống nhúng cục bộ. Bạn muốn mô hình nhúng hoạt động tốt nhất cho các trường hợp sử dụng truy xuất.

Mặc dù nằm ngoài phạm vi của bài viết này, nhưng bạn có thể muốn tìm hiểu sâu hơn về 15 điểm chuẩn trong bảng xếp hạng MTEB để xác định điểm chuẩn gần giống nhất với tình huống cụ thể của bạn.

Mặc dù chắc chắn có những mô hình khác nhau về mức độ hoạt động của các mô hình nhúng khác nhau trên các điểm chuẩn khác nhau, nhưng thường có những mô hình cụ thể nổi bật trong mỗi mô hình. Nếu bạn cần tinh chỉnh thêm lựa chọn nhúng của mình thì đây có thể là lĩnh vực cần điều tra thêm.

Tối ưu hóa chiến lược phân đoạn của bạn

Việc phân đoạn hoặc “phân đoạn” văn bản đầu vào là yếu tố then chốt ảnh hưởng đáng kể đến mức độ liên quan và độ chính xác của đầu ra được tạo ra. Các chiến lược phân chia khác nhau mang lại những lợi thế độc đáo và phù hợp với các loại nhiệm vụ cụ thể. Ở đây, chúng tôi đi sâu vào các phương pháp này và cung cấp hướng dẫn áp dụng, kết hợp một số cân nhắc chính:

1. Phân đoạn có độ dài cố định

   • Khi nào nên sử dụng - Trừ khi bản thân nội dung của bạn có cấu trúc chặt chẽ và có độ dài cố định, bạn thường muốn dựa vào chiến lược phân đoạn hữu ích hơn như những chiến lược tiếp theo.

     
     

   • Cân nhắc về mặt kỹ thuật - Mặc dù thực hiện rất đơn giản nhưng chiến lược phân chia này thường dẫn đến kết quả kém trong các ứng dụng RAG.

     
     

   • Thông tin chi tiết bổ sung Nếu bạn đang sử dụng chiến lược có độ dài cố định với ứng dụng RAG của mình và gặp khó khăn khi truy xuất ngữ cảnh có liên quan, bạn nên xem xét chuyển sang một cách tiếp cận phân đoạn khác.

     
     

2. Phân chia cấp độ câu

   • Khi nào nên sử dụng - Chiến lược này hiệu quả khi mỗi câu trong văn bản đầu vào đều giàu ý nghĩa và ngữ cảnh. Nó cho phép mô hình tập trung vào những điểm phức tạp trong mỗi câu, từ đó tạo ra các phản hồi mạch lạc và phù hợp với ngữ cảnh hơn. Bạn sẽ hiếm khi dựa vào phân đoạn cấp độ câu cho các trường hợp sử dụng RAG.

     
     

   • Cân nhắc về mặt kỹ thuật - Việc phân chia cấp độ câu thường liên quan đến việc mã hóa dựa trên ranh giới câu, điều này có thể đạt được bằng cách sử dụng thư viện xử lý ngôn ngữ tự nhiên (NLP).

     
     

   • Thông tin chi tiết bổ sung - Phân chia cấp độ câu có thể đặc biệt hữu ích khi bạn đang tìm kiếm các tuyên bố cụ thể, chẳng hạn như trong bản ghi của một cuộc họp mà bạn đang cố gắng tìm các tuyên bố tương tự về mặt ngữ nghĩa với một đoạn văn bản nhất định.

     
     

3. Phân đoạn cấp độ đoạn văn

   • Khi nào nên sử dụng - Sử dụng chiến lược này khi văn bản đầu vào được sắp xếp thành các phần hoặc đoạn riêng biệt, mỗi phần tóm tắt một ý tưởng hoặc chủ đề riêng biệt. Điều này cho phép mô hình tập trung vào thông tin liên quan trong mỗi đoạn văn.

     
     

   • Xem xét về mặt kỹ thuật - Việc xác định ranh giới đoạn văn thường liên quan đến việc phát hiện các ký tự dòng mới hoặc các dấu phân cách khác biểu thị sự kết thúc của đoạn văn.

     
     

   • Thông tin chi tiết bổ sung - Phân chia cấp độ đoạn văn có thể hữu ích khi bạn có tài liệu đề cập đến nhiều khía cạnh khác nhau của cùng một chủ đề. Ví dụ: một trang tài liệu sản phẩm có thể giới thiệu tính năng sản phẩm, giải thích thời điểm sử dụng tính năng đó, nói về cách định cấu hình tính năng đó và đưa ra ví dụ về các cấu hình khác nhau.

     
     

     Việc sử dụng phân đoạn cấp độ đoạn văn có thể giúp bạn xác định phần có liên quan nhất của tài liệu để cung cấp cho LLM làm ngữ cảnh.

     
     

4. Phân đoạn nhận biết nội dung

   • Khi nào nên sử dụng - Chọn chiến lược này khi mức độ liên quan của các phần cụ thể trong văn bản là tối quan trọng. Ví dụ: trong các văn bản pháp luật, việc phân đoạn văn bản dựa trên các điều khoản hoặc phần có thể mang lại nhiều phản hồi theo ngữ cảnh cụ thể hơn.

     
     

   • Xem xét kỹ thuật - Cách tiếp cận này có thể yêu cầu các kỹ thuật NLP nâng cao để hiểu ranh giới ngữ nghĩa trong văn bản.

     
     

   • Thông tin chi tiết bổ sung - Phân đoạn nhận biết nội dung đặc biệt hữu ích khi xử lý dữ liệu có cấu trúc hoặc bán cấu trúc, vì các khối cụ thể có thể được kết hợp với tính năng lọc siêu dữ liệu để truy xuất chính xác hơn.

     
     

     Ví dụ: trong một tài liệu pháp lý, bạn có thể muốn trích xuất tất cả các điều khoản bảo hành hoặc bồi thường và khi bạn lưu trữ các phần nhúng cho các khối trong cơ sở dữ liệu vectơ, bạn có thể sử dụng siêu dữ liệu để giúp tìm kiếm nội dung của một loại nhất định dễ dàng hơn khi xây dựng một Trường hợp sử dụng RAG.

     
     

5. Phân đoạn đệ quy

   • Khi nào nên sử dụng - Phân đoạn đệ quy chia dữ liệu thành các phần ngày càng nhỏ hơn bằng cách sử dụng phương pháp phân cấp. Ví dụ: khi phân đoạn một tài liệu văn bản, trước tiên bạn có thể chia văn bản thành các đoạn văn, sau đó thành các câu và cuối cùng là các từ.

     
     

     Sau khi dữ liệu đã được chia thành nhóm khối đầu tiên, bạn có thể áp dụng đệ quy quy trình phân khối cho từng khối nhỏ hơn, lặp lại cho đến khi đạt được kích thước khối nhỏ nhất mà bạn quan tâm.

     
     

   • Xem xét kỹ thuật - Việc triển khai phân đoạn đệ quy có thể liên quan đến chiến lược phân tích cú pháp đa cấp trong đó các khối được chia thành các khối phụ dựa trên các tiêu chí bổ sung. Nếu bạn đang sử dụng LangChain , việc triển khai đệ quy của nó đơn giản hơn một chút so với những gì được mô tả ở đây.

     
     

   • Thông tin chi tiết bổ sung - Cách tiếp cận này cho phép mô hình hiểu bối cảnh ở nhiều cấp độ, từ các chủ đề cấp cao đến các sắc thái chi tiết, khiến nó đặc biệt hữu ích đối với các tài liệu phức tạp như tài liệu học thuật, sổ tay kỹ thuật hoặc hợp đồng pháp lý. Điều này mang lại lợi ích linh hoạt vì các tìm kiếm tương tự có thể xác định văn bản tương tự cho cả truy vấn rộng hơn và ngắn hơn.

     
     

     Tuy nhiên, điều này cũng có nghĩa là có khả năng các đoạn tương tự từ cùng một tài liệu nguồn cuối cùng cũng có thể được thể hiện quá mức trong các tìm kiếm tương tự, đặc biệt nếu bạn chọn cách chồng chéo dài hơn giữa các đoạn trong cấu hình bộ tách văn bản của mình.

Theo cách tiếp cận chung, trước khi thử chia nhỏ một kho văn bản lớn và vector hóa nó, bạn nên cân nhắc thực hiện một số thử nghiệm đặc biệt với dữ liệu của mình.

Kiểm tra thủ công các tài liệu bạn muốn truy xuất cho một truy vấn nhất định, xác định các khối đại diện cho ngữ cảnh lý tưởng mà bạn muốn cung cấp LLM, sau đó thử nghiệm các chiến lược phân khối để xem cái nào mang lại cho bạn các khối mà bạn cảm thấy phù hợp nhất để LLM có.

Xem xét cửa sổ ngữ cảnh

Cửa sổ ngữ cảnh có sẵn của LLM là một yếu tố quan trọng trong việc lựa chọn chiến lược phân đoạn. Nếu cửa sổ ngữ cảnh nhỏ, bạn sẽ cần chọn lọc hơn các phần bạn đưa vào mô hình để đảm bảo đưa vào thông tin phù hợp nhất.

Ngược lại, cửa sổ ngữ cảnh lớn hơn cho phép linh hoạt hơn, cho phép đưa vào ngữ cảnh bổ sung có thể nâng cao kết quả đầu ra của mô hình, ngay cả khi không phải tất cả ngữ cảnh đó đều thực sự cần thiết.

Bằng cách thử nghiệm các chiến lược phân chia này và tính đến những cân nhắc này, bạn có thể đánh giá tác động của chúng đối với mức độ liên quan của kết quả đầu ra được tạo ra. Điều quan trọng là điều chỉnh chiến lược đã chọn với các yêu cầu cụ thể của ứng dụng RAG của bạn, duy trì tính toàn vẹn ngữ nghĩa của đầu vào và cung cấp sự hiểu biết toàn diện về ngữ cảnh.

Điều này sẽ cho phép bạn tìm ra quy trình phân đoạn phù hợp để có hiệu suất tối ưu.

Lọc siêu dữ liệu

Khi số lượng nội dung nhúng trong chỉ mục tìm kiếm của bạn tăng lên, những người hàng xóm gần nhất (ANN) gần đúng sẽ trở nên ít hữu ích hơn khi tìm kiếm ngữ cảnh có liên quan để đưa vào lời nhắc của bạn. Giả sử bạn đã lập chỉ mục các phần nhúng cho 200 bài viết trong cơ sở kiến thức của mình.

Nếu bạn có thể xác định người hàng xóm gần nhất với độ chính xác 1%, bạn có thể tìm thấy kết quả khá phù hợp vì 1% đại diện cho hai bài viết hàng đầu trong số 200 bài viết đó và bạn sẽ nhận được một trong hai bài viết đó.

Bây giờ, hãy xem xét chỉ mục tìm kiếm chứa mọi bài viết trên Wikipedia. Con số đó sẽ lên tới khoảng 6,7 triệu bài báo. Nếu người hàng xóm gần nhất của bạn nằm trong top 1% các bài viết tương tự nhất, điều đó có nghĩa là bạn đang nhận được một trong 67.000 bài viết tương tự nhất.

Với một kho văn bản như Wikipedia, điều này có nghĩa là bạn vẫn có thể đi quá xa mục tiêu.

Lọc siêu dữ liệu cung cấp cho bạn cách thu hẹp các phần nội dung bằng cách lọc tài liệu trước tiên, sau đó áp dụng thuật toán lân cận gần nhất. Trong trường hợp bạn đang xử lý một số lượng lớn các kết quả phù hợp có thể xảy ra, quá trình lọc trước ban đầu này có thể giúp bạn thu hẹp các tùy chọn có thể có trước khi truy xuất các kết quả lân cận gần nhất.

Tiếp theo, chúng ta sẽ đi sâu vào tương tác với LLM và xem xét một số vấn đề phổ biến có thể dẫn đến kết quả kém.

Thử DataStax Astra DB , cơ sở dữ liệu vectơ duy nhất để xây dựng các ứng dụng AI cấp sản xuất trên dữ liệu thời gian thực .

Bởi Chris Latimer, DataStax

Cũng được xuất bản ở đây