@hieult0603 Mình nghĩ với các document mà bạn có thể phân tách thành cấu trúc rõ ràng thì nên sử dụng hybrid search. Các dịch vụ như Azure AI Search hỗ trợ rất tốt việc này. Ngoài ra bạn nên đào sâu hơn vào data đê tìm cách chia chunk cho hợp lý tuỳ thuộc vào loại dữ liệu. Dữ liệu đầu vào sẽ ảnh hưởng rất nhiều đến cách bạn retrieval ra thông tin trong pipeline RAG.
@huukimit thế nó dùng chủ yếu trong mấy mô hình microservice hàng triệu người dùng thôi , chứ với kiểu dự án 1 source fe + 1 source be + 1 db thì chắt không cần thiết bạn nhỉ
Bạn có thể hiểu là nháp bằng FE rồi paste
Do trước đó lập trình viên BE đã có giao diện FE (tự code hoặc được lập trình viên FE đưa), họ đã biết cần truyền dữ liệu gì vào vị trí nào rồi nên có thể build html chính xác
Cơ bản thì useQuery đã là 1 hook rồi bạn. nên theo quy tắc thì không thể gọi useQuery trong 1 hook khác. ngoài ra thì key nếu nói dễ hiểu chính là dependencies của call back mà bạn truyền vào useQuery.
@Huyennv Trong trường hợp hệ thống chạy bt thì cũng khó kiếm ra lý do để clear cache. Xét với 3 cách thiết kế ở trên:
1. Redis đơn thuần là cache. Cache có expire time được cài đặt theo 3 cách:
Absolute - đặt thời gian tồn tại cố định cho cache, cache sẽ tự clear sau khi đến hạn.
Sliding - đặt thời gian clear cache nếu cache không được truy cập nữa, hay mỗi lần cache được truy cập thì thời gian hết hạn của cache được đặt lại về số ban đầu. Đối với sliding thì có vấn đề là nếu cache được truy cập liên tục thì sẽ không bao giờ được clear => nhu cầu clear cache thủ công
Cache validation: cài đặt một callback xử lý việc clear cache khi đạt một điều kiện nào đấy. Cái này thường được kết hợp cùng expire time. Đối với tính lượt view, một dependency để invalidate cache có thể là khi số view đạt đến hàng nghìn thì clear cache, hoặc một trick là rand trong range 100, 1000, nếu bằng 1 thì clear.
2. Redis chạy song song
Về cơ bản thì phương án này vẫn là cache, nhưng cái khác là số đếm được cập nhật song song giữa redis và lưu trữ trong DB. Do Redis được cập nhật trực tiếp như DB nên không cần validate cache. Redis bị xóa thì có thể do mất điện, shutdown hệ thống để maitain hay update.
3. Lưu Redis trước rồi backup lại trên DB sau
Trường hợp này thì không có lý do gì để xóa redis cả (xóa là mất dữ liệu). Chỉ có 1 trường hợp cần là khi hệ thống gián đoạn (maitainance, update ...), Redis sẽ mất hết dữ liệu và cần reload lại từ DB. (Redis lưu dữ liệu trong RAM nên mất điện là mất hết).
Tất nhiên là nếu dùng Kafka, thay vì xử lý trực tiếp phía API thì bạn có thể đẩy một số task vào Kafka chạy background. Tuy nhiên theo mình, nếu mục đích của bạn là muốn giảm độ trễ của REST API thì bạn nên cân nhắc tối ưu lại source code và dùng các công cụ như là memcache, redis để thực hiện caching và dựng queue trước. Dựa trên quy mô của dự án để quyết định có nên dùng Kafka hay không tránh giết gà dùng dao mổ trâu.
Hi tác giả, không biết env và ide của bạn đang chạy như thế nào ạ, mình có thử implement code của bạn ở env trên Jupyter và gặp một số lỗi về runningtimeerror cụ thể là: asyncio.run() cannot be called from a running event loop ạ
nếu document là 1 kiểu report có nhiều thông tin giá trị, kích thước document nhỏ, mỗi dòng trong document sẽ là 1 chunk (sẽ khoảng <30 word cho 1 dòng). Và yêu cầu là ta cần LLM chỉ tìm kiếm thông tin được yêu cầu và gửi kết quả về thôi (không diễn giải, gợi ý hay giải thích gì thêm), thì nên dùng phương pháp nào vậy anh ơi
THẢO LUẬN
@hieult0603 Mình nghĩ với các document mà bạn có thể phân tách thành cấu trúc rõ ràng thì nên sử dụng hybrid search. Các dịch vụ như Azure AI Search hỗ trợ rất tốt việc này. Ngoài ra bạn nên đào sâu hơn vào data đê tìm cách chia chunk cho hợp lý tuỳ thuộc vào loại dữ liệu. Dữ liệu đầu vào sẽ ảnh hưởng rất nhiều đến cách bạn retrieval ra thông tin trong pipeline RAG.
@huukimit thế nó dùng chủ yếu trong mấy mô hình microservice hàng triệu người dùng thôi , chứ với kiểu dự án 1 source fe + 1 source be + 1 db thì chắt không cần thiết bạn nhỉ
👍️
ServBay chỉ support MacOS, mình thì đang dùng nvm cũng khá là ổn
Bạn có thể hiểu là nháp bằng FE rồi paste Do trước đó lập trình viên BE đã có giao diện FE (tự code hoặc được lập trình viên FE đưa), họ đã biết cần truyền dữ liệu gì vào vị trí nào rồi nên có thể build html chính xác
Có QueryCache. Class này chứa toàn bộ cache của react-query. Cơ bản thì nó sẽ cung cấp các phương thức CRUD để giúp thao tác với cache.
Cơ bản thì useQuery đã là 1 hook rồi bạn. nên theo quy tắc thì không thể gọi useQuery trong 1 hook khác. ngoài ra thì key nếu nói dễ hiểu chính là dependencies của call back mà bạn truyền vào useQuery.
Mình có đoạn mã như thế này thì áp dụng deltatime ở đâu vậy ad?
let position = 0 let velocity = 10
function loop() { velocity *= 0.95 position += velocity
requestAnimationFrame(loop) }
Nếu mình làm như này thì lại rất chậm: position += velocity * deltatime
Vì trong repo có chứa cả thông tin nhạy cảm nên anh chưa tạo repo mẫu. Em copy code mẫu theo hướng dẫn trong bài chắc chắn sẽ thực hiện được nhé.
@refacore Mình hiểu rồi, cám ơn bạn đã đóng góp cho cộng đồng, mình tin là bài viết này sẽ còn có giá trị cho nhiều người khác sau này nữa.
@Huyennv Trong trường hợp hệ thống chạy bt thì cũng khó kiếm ra lý do để clear cache. Xét với 3 cách thiết kế ở trên:
1. Redis đơn thuần là cache. Cache có expire time được cài đặt theo 3 cách:
2. Redis chạy song song
Về cơ bản thì phương án này vẫn là cache, nhưng cái khác là số đếm được cập nhật song song giữa redis và lưu trữ trong DB. Do Redis được cập nhật trực tiếp như DB nên không cần validate cache. Redis bị xóa thì có thể do mất điện, shutdown hệ thống để maitain hay update.
3. Lưu Redis trước rồi backup lại trên DB sau
Trường hợp này thì không có lý do gì để xóa redis cả (xóa là mất dữ liệu). Chỉ có 1 trường hợp cần là khi hệ thống gián đoạn (maitainance, update ...), Redis sẽ mất hết dữ liệu và cần reload lại từ DB. (Redis lưu dữ liệu trong RAM nên mất điện là mất hết).
@refacore Sorry bạn, mình giờ mới rep được, Bạn giải thích khá dễ hiểu. Mình đã hiểu các ý bạn nói, mình muốn làm rõ thêm ý nữa là:
Cám ơn bạn nhiều
Mình đang bị lỗi chatbox không có hồi đáp từ rasa, Hãy chỉ cách giúp mình với. Thanks
Tất nhiên là nếu dùng Kafka, thay vì xử lý trực tiếp phía API thì bạn có thể đẩy một số task vào Kafka chạy background. Tuy nhiên theo mình, nếu mục đích của bạn là muốn giảm độ trễ của REST API thì bạn nên cân nhắc tối ưu lại source code và dùng các công cụ như là memcache, redis để thực hiện caching và dựng queue trước. Dựa trên quy mô của dự án để quyết định có nên dùng Kafka hay không tránh giết gà dùng dao mổ trâu.
Với một Dev quèn như em code chạy được là tốt rồi, để mà code được theo nguyên tắc SOLID thật sự khá khó.
Bài viết rất hay !
bạn ơi cho hỏi thu thập thông tin khóa học từ các trang web như coursera, udemy, edx,... nó toàn trả về kết quả là {'course_info': 'NA'} nhỉ 😅
Hi tác giả, không biết env và ide của bạn đang chạy như thế nào ạ, mình có thử implement code của bạn ở env trên Jupyter và gặp một số lỗi về runningtimeerror cụ thể là: asyncio.run() cannot be called from a running event loop ạ
nếu document là 1 kiểu report có nhiều thông tin giá trị, kích thước document nhỏ, mỗi dòng trong document sẽ là 1 chunk (sẽ khoảng <30 word cho 1 dòng). Và yêu cầu là ta cần LLM chỉ tìm kiếm thông tin được yêu cầu và gửi kết quả về thôi (không diễn giải, gợi ý hay giải thích gì thêm), thì nên dùng phương pháp nào vậy anh ơi
Cái này sinh ra để giúp giảm tải độ trễ của RestAPI không bạn