지난 글에서는 검색을 개선하기 전에 평가셋부터 다시 짜야 했던 이유를 적었다. 이번 글은 RAG 구축 고려사항 중 질의 강화·키워드 추출에 해당한다. 결론부터 말하면, 질의를 키워드로 바꾸는 게 오히려 검색을 깎아먹었다.검색기를 의심했는데, 검색기 문제가 아니었다검색 품질이 아쉬우면 가장 먼저 검색기를 의심하게 된다. 나도 그랬다. 임베딩 모델을 바꿔보고, 인덱싱 방식을 손보고, 청크 크기를 조절하며 며칠을 보냈다. "검색이 약하니 검색기를 강하게 만들면 되겠지"라는 게 당연한 출발점이었다. 그런데 평가셋을 정리하고 나서, 검색기는 그대로 둔 채 질의를 넘기는 방식만 바꿔 같은 조건에서 비교해봤다. 원질의를 그대로 검색할 때, 키워드만 추출해 넘길 때, 추출한 키워드를 확장해 넘길 때. 결과는 예상과 정..
현재 온디바이스(On-Device) 환경에서 쓸 RAG 검색 시스템을 개선하고 있다. 그런데 막상 "검색을 개선하자"고 마음먹고 나니, 제일 먼저 막힌 건 알고리즘이 아니라 "개선됐는지 어떻게 아느냐" 였다. 개선이라는 건 결국 "전보다 나아졌다"를 보여야 하는데, 그 "전보다"를 재는 자가 흔들리면 무슨 짓을 해도 "좋아진 것 같다"는 느낌으로만 남는다. 이 글은 이전 글에서 정리한 'RAG 구축 시 고려할 것들' 중 검색 품질을 측정하는 기준에 해당한다. 결론부터 말하면, 검색을 건드리기 전에 평가셋부터 다시 짜야 했고, 그 과정에서 생각보다 고민할 게 많았다.1. 테스트 목적이 하나가 아니었다처음엔 단순하게 생각했다. "검색 평가셋 하나 잘 만들면 그걸로 다 재면 되지." 그런데 실제로 실험을 돌리..
- Total
- Today
- Yesterday
- ChatGPT
- Log
- terraform
- 람다
- AWS
- S3
- 질의처리
- 티스토리챌린지
- java
- Kotlin
- Spring
- 온디바이스 AI
- 오블완
- EKS
- cache
- 인프런
- CORS
- springboot
- rag
- elasticsearch
- 후쿠오카
- Redis
- lambda
- AWS EC2
- docker
- OpenAI
- 스프링부트
- serverless
- CloudFront
- GIT
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
