Feature/46 retrieve 성능 향상

[ehddnr301]

#️⃣ Issue Number

• Retrieve 성능 향상 #46

📝 요약(Summary)

• retrieve 할때 reranking을 쓸수 있도록 streamlit에 버튼을 추가했습니다.
• reranking시 Dongjin-kr/ko-reranker 모델을 통해 reranking 합니다.
• 당장 머지하려는 코드는 아니고 @DShomin 님 혹은 @anjaaaaeeeellll 님 코드가 머지되면 변경에 맞추어 streamlit을 변경 후에 머지를 하려고 합니다.

💬 To Reviewers (선택)

• 추후에 다른 retrieve 방법을 고려하여 우선 retrieve 하는 코드를 retrieve.py로 분리하였는데 적절한지 리뷰 부탁드립니다.

PR Checklist

• TBD

reference) How to Code Review

• 따봉(👍): 리뷰어가 리뷰이의 코드에서 칭찬의 의견을 남기고 싶을 때 사용합니다.
• 느낌표(❗): 리뷰어가 리뷰이에게 필수적으로 코드 수정을 요청할 때 사용합니다.
• 물음표 (❓): 리뷰어가 리뷰이에게 의견을 물어보고 싶을 때 사용합니다.
• 알약 (💊): 리뷰어가 리뷰이의 코드에서 개선된 방법을 제안하지만 그것의 반영이 필수까지는 아닐 때 사용합니다.

[DShomin]

• 👍 retrieve 기능을 별도로 분리 되는 것이 좋은 것 같아요
• 💊 rerank 도입 전후 성능이 어떻게 달라지는지 궁금하네요 검색되는 Table와 SQL 차이점 비교해보면 좋을 것 같네요(SQL 생성 시간도 비교하면 좋겠네요)

[ehddnr301]

• 👍 retrieve 기능을 별도로 분리 되는 것이 좋은 것 같아요
• 💊 rerank 도입 전후 성능이 어떻게 달라지는지 궁금하네요 검색되는 Table와 SQL 차이점 비교해보면 좋을 것 같네요(SQL 생성 시간도 비교하면 좋겠네요)

회사에 실험적으로 도입했을때 체감으로는 rerank 도입후에 좀 더 정확한 테이블검색이 이루어지는것 같습니다. 어떻게 그걸 정량적으로 비교할지는 아직 잘 감이 안오네요...! SQL생성시간이 전체적인 시간을 의미하는것이라면 30초대로 기존 10초 아래로 걸리던것에 비해 좀 느려지긴했습니다. (대부분 reranker에서 소요)

[seyoung4503]

👍 리랭킹을 유저가 선택적으로 적용할 수 있는 옵션으로 남겨두는 것이 좋은 것 같아요.
💬 아쉬운점은 정량적으로 얼마나 개선되었는지 평가할 방법이 없다는 점이 어려운 것 같아요.

💬 참고로 M1 맥에서 돌려봤을 때는 이런 메시지가 뜨더라고요:

[ParkGyeongTae]

👍 도입해서 먼저 사용해보고 부족한부분 채우면 될 것 같아요!!

[ehddnr301]

#76 duplicated