댓글 4
-
-
피드백 감사합니다!
1번은 바로 반영했습니다. 에이전트가 여러 개니까 Redis를 깔아야 하나 막연히 고민했는데, 지금 규모에선 과하다는 말씀이 맞더라고요.
다만 하나 절충한 게 있는데, "지금 상담이 어느 단계까지 왔는지" 같은 값은 자주 찾아볼 것 같아서 그건 따로 컬럼을 두고, 에이전트가 만들어낸 결과물만 JSONB에 담았습니다. 이 정도 나누는 게 적당할까요? 아니면 그냥 다 JSONB에 넣고 가도 괜찮을지 궁금합니다.
2번 청킹도 말씀하신 방향으로 가려고 합니다. 마침 어제 원문을 괘별·효별로 다 쪼개둔 상태라, 길이로 자르지 않고 그 나눈 그대로 쓰면 될 것 같아요.
여기서 한 가지 여쭙고 싶은 게 있습니다. 원문은 검색할 것 없이 그냥 끌어오면 되고(형식이 괘모양, 괘사, 효사로 동일하게 구성되니까요), 검색이 필요한 건 오히려 주석이나 해설 쪽이라고 생각했습니다. 그래서 원문은 단순 조회로, 해설만 RAG로 분리하려고 하는데 이런 식으로 나누는 게 보통인가요? 아니면 그냥 다 같이 넣고 검색하는 게 나을까요?
키워드 추출 방식은 일단 미뤄둘 생각입니다. 아직 만들지도 않아서 실제로 느린지 아닌지 모르는 상태인데, 먼저 만들어보고 느리면 그때 붙이는 게 나을 것 같아서요. 지금부터 넣으면 나중에 문제 생겼을 때 어디가 원인인지 못 찾을 것 같기도 하고요.
관리자 화면도 결국 필요해질 것 같은데, 지금은 뭘 관리해야 할지도 안 보이는 상태라 나중에 만들려고 합니다.
좋은 조언 감사합니다!
-
주역이라고 해서 처음엔 운세 봐주는 서비스인가 했는데 생각보다 훨씬 깊게 들어가셨네요 ㅎㅎ
특히 이전 상담을 기억하면서 대화가 이어지는 방식이 재미있었습니다.
한 가지 궁금한 건 로컬 모델을 사용하신 부분인데요. 아무래도 복잡한 맥락이나 미묘한 해석에서는 상용 모델 대비 한계가 있을 것 같은데, 이 부분은 어느 정도 감안하고 가시는 건지 궁금합니다.
특히 주역처럼 같은 괘도 질문이나 상황에 따라 해석이 달라질 수 있는 분야라 모델 차이가 결과에 꽤 영향을 줄 것 같아서요.
기존 코드 갈아엎고 다시 시작하셨다는 부분은 괜히 공감됐습니다 ㅋㅋ
-
가장 큰 이유는 비용입니다. 만약, 제가 혼자쓸게 아니라(이 책을 읽고 아이디어가 떠올라서 https://product.kyobobook.co.kr/detail/S000000406990 ) 상용화 할 경우, api 값및 클라우드 비용을 감당하기 어려울거라 봤어요. 그래서 비용극소화 차원서 어느정도 성능이 나오는 젬마4 26b 로 일단 세팅했습니다. 개발단계서 돌려본 후 영 퀄리티가 아니라면 그땐 클로드 소네트 정도로 api를 넣어야 할듯 합니다.(마침 지금 개발중이라 바로바로 피드백이 가능하네요.ㅋㅋ)
구성은 좋은 것 같아용. ' -')
1. 상태 관리 부분은 포스트그레스에 JSONB 컬럼 하나 두고 각 에이전트가 끝날 때마다 업데이트해서 상태값 index 로 쓰는게 가장 가벼울 것 같아요. 로컬이면 구지 Redis 를 띄울 필요는 없을 것 같고, 시스템 자체가 워낙 가벼워서 ' -')... DB 상태값 필드를 하나 쓰는게 가장 깔끔하게 할 수 있는 방법입니당. 디버깅도 그렇고. ~_~
2. RAG 부분은 저는 보통 구조와 내용 기반으로 저는 청킹합니당.
근데 이미 주역 원문이 책처럼 딱 괘 도출 방식으로 처리 되어있으니까. 제목 + 전체설명(요약) 부분을 이미 만들어진 구분 선대로 그냥 짜르는게 가장 의미가 전달이 잘 되지 않을까 합니다. 인프라 속도에서 이슈가 있다면 각 내용에 대해서 키워드 추출을 통해서 MoE 모델에서 키워드값에 대한 프롬프트를 가져오면 좋지 않을까요? 모컬 모델이 26B정도면 토큰을 너무 길게 하는 것보다 짧은 모델링으로 그리고 관련 키 포인트 키워드를 (문맥단위)에서 기ㅏ져오는 것..? 또는 아니면 각 괘 마다 요약 index를 미리 선행 데이터로 해서 관리자 화면에서 indexing 하는 것도 좋을 것 같아요 : )
수고하세욤