자세히 읽어보니까 아이디어는 꽤 훌륭함
사용자가 질문을 주면 그 질문에 가장 가까운 문서를 찾아서
그 문서를 사용자의 질문과 함께 llm에게 질문하는 전형적인 RAG 구현인데
벡터 검색과 키워드 매칭을 같이 쓰는 부분이 좀 ㄱㅊ은 듯
보통은 벡터검색 정도만 하는데 BM25(TF-IDF변형판)도 써서키워드 매칭까지 하네
소싯적에 워드클라우드 좀 만들어봤나보지?
전체적으로 구현 대부분이 잘 되어있어서 후배들에게 매우 큰 도움이 될 수 있는 레포 같음
근데 문제가 몇 개 있음
첫째로, 라이프 사이클 관리가 거의 전무함
예를 들어
store_instance = ChromaVectorStore() 이렇게 해놓고 매번 이 인스턴스를 호출하고 있는데
이런 건 싱글톤이 아님
실제로 싱글톤인지도 알기 어렵기 때문에 생명주기 관리가 안됨 (관례도 아님)
컨피그도 문제인 게, 누가 컨피그 리로드하면 db연결 늘어나서 메모리도 폭파되고
심하면 파일 핸들링 os 리밋 넘어가서 시스템도 멈출 수 있음
파일와쳐도 그렇고 벡터스토어 자체도 그렇고 close(), 리소스 정리하는 부분이 없음.
즉, 총체적으로 라이프 사이클 관리가 안되고 있음
그리고 두번째 문제
사실 이게 더 심각함
커밋 메세지가 대체 이게 뭐냐???
1. 사실 순전히 개인 프로젝트라서 크게 신경을 안썼음 2. 파일 와쳐는 그냥 아이디어 구현이고 실제 적용 안되있음 3. 사실 싱글톤 구현한게 아니고 DI 컨테이너 방식이라 이게 좀 더 나은 방식임
사실 나는 DI컨테이너 방식을 쓴 거 자체가 잘못됐다고 생각함
@에이도비 음
@에이도비 왜 이렇게 했냐면 최종족으로 하나의 에이전트가 아니라 복수의 에이전트를 그래프 노드화 해서 연결시키는 걸 실행하려고 한거라 싱글톤으로 데이터 접근하는게 아니라, DI로 해야해요
@에이도비 그리고 라이프 사이클 부분은 사실 FastAPI에서 자체 관리하는거라 억지로 관리하면 안된다고 문서에 있음
@에이도비
https://gall.dcinside.com/board/view/?id=programming&no=2898415&page=1
이런 글이 진짜 엔지니어 다운 저격인듯 ㅇㅅㅇ
수정중
아무래도 저 124.48한테 신상정보 안 주는게 좋을듯... 저 사람 좀 무서움 ㅇㅅㅇ
싸우면 내가 이김 ㅋㅋ - dc App
칼이나 무슨 이상한 무기 같은거 들고 나타나도??
@chironpractor ㅇㅇ - dc App