직업으로서의 개발자 직업으로서의 개발자

허깅페이스에서 zero-shot 모델을 파인튜닝 해봤는데, cpu만 있는 개발 서버에서는 성능이 좀 안 나온다. 개발 장비 내에서 zero-shot-classification model의 성능을 올려보자. 추가 파인튜닝 zero-shot-classification fine-turning '유저 질의 의도(도메인)를 파악할 수 있는 모델을 파인튜닝 해 볼 수 있을까?' 🫤 zero-shot-classification 모델이 레이블이 지정된 예제 세트에 대해 훈련된 다음 이전에 볼 수 없었던 클래스의 새로 developer-as-job.tistory.com 이전 글에서 파인튜닝한 모델의 레이블을 6개로 나누어 추가 파인튜닝을 함 - 방송, 인물, 주식, 환율, 장소, 영화 서비스에 붙여보려고 했는데 응답속도..

'유저 질의 의도(도메인)를 파악할 수 있는 모델을 파인튜닝 해 볼 수 있을까?' 🫤 zero-shot-classification 모델이 레이블이 지정된 예제 세트에 대해 훈련된 다음 이전에 볼 수 없었던 클래스의 새로운 예제를 분류할 수 있는 자연어처리 작업 - 훈련 중에 모델에서 볼 수 없는 클래스를 예측하는 작업 하지만 다양한 라벨링 데이터를 확보하는 것은 어려운 일 GPT-3와 같은 거대 규모로 학습된 언어 모델은 라벨링을 거의 사용하지 않고도 태스크를 수행할 수 있음을 보여줌 하지만 GPT-3와 같은 모델을 활용해야만 가능한 작업이 나고 묻는다면 꼭 그렇지는 않다. 거대모델을 사용하지 않고 문장의 도메인을 분류해 보자. 1. Sentence Similarity task, sentence-tran..

Rate Limit(처리율 제한) 서버가 임계치까지만 클라이언트의 요청을 허용하는 정책 Throttling이라고도 표현 필요한 이유 과도한 트래픽으로부터 서비스 보호 공정성 합리성 - 특정 클라이언트가 서버자원 독점 막기 위해 운영비용 Rate에 따라 과금을 위한 Business Model Rate limiter의 위치 서버, 클라이언트 모두 가능하겠지만, 클라이언트는 위변조가 가능하기 때문에 servier side application server에 직접 구현하거나, 미들 웨어로 rate limiter를 두어서 요청을 제한 일반적으로 rate limiter는 API gateway에 구축하는 편 - API gateway = 클라이언트의 API 요청을 적절한 서비스로 라우팅 - API Gateway가 고유..

안타깝지만 세상을 바꿀 수 있는 힘을 가지고 있는 사람들의 거의 대부분은 세상을 바꿀 필요를 느끼지 못하는 사람들이다. 그중 어떤 무리는 자기들만을 위한 견고한 벽을 만들어 놓고 견제받지 않는 권력의 보호를 최우선으로 생각한다. 그것이 잘못되었고 변화가 필요하다고 이야기하였을 때, 그것을 지키려고 하는 사람들과의 갈등은 불가피하고, 그것이 충분히 위협적으로 그들에게 다가올 경우 단단한 벽에 던져진 달걀과 같은 존재로 만들어 버리기도 한다. 그럼에도 불구하고 현실적으로 효율적으로 생각했을 때 쉽게 이해하기 힘든 '바보' 같은 사람들도 있다. 모른 척 지나갈 수도 있고 현실과 타협하며 편하게 살 수 있지만 자신들이 옳다고 믿는 일을 위해 무모해 보이고, 자신에게 또는 가족들에게도 어려움이 될 수 있는 가능성..

혁신은 새로 일어났을 때가 아니라 누구나 다 사용을 할 때가 혁신이다. 피터 드러커 chatGPT가 출시 한지 1년.. 세상이 하루가 다르게 변하고 있지만, 아직까지는 모든 사람의 일상에 자리 잡진 못한 것 같습니다. - https://www.aitimes.com/news/articleView.html?idxno=152957 IT 역사의 3개의 터닝포인트(제 생각..) PC, Smartphone 그리고 LLM - 위에서 이야기한 것처럼 PC, Smartphone은 누구나 다 사용을 하고 있지만, 아직 LLM은 모두가 다 사용을 하고 있다고 이야기 하긴 어려울 것 같다. 그럼 LLM의 혁신은 언제 어떻게 올까?? 주관적인 생각이 많이 들어있기 때문에, 가볍게 봐주시고 다른 의견도 많이 주시면 좋을 듯. ㅎ..

평가 면담 연말이 되니 평가의 시즌이 왔고, 평가가 끝나자, 파트원과의 평가 면담의 시간이 되었습니다. 그런데 얼마 전 파트장이 된 저에게는 파트원들과의 면담 시간을 잡는 것도 일이더군요. 우선 저의 이미 예약된 회의시간을 면담 가능시간에서 제거해야 하고, 파트원들이 각자 가능한 시간 안에서, 다른 파트원들의 면담 시간이 겹치지 않도록 예약이 가능해야 했습니다. 저희 회사는 google workspace를 사용하기 때문에, 대부분의 이미 예약된 회의 시간은 google calendar에 등록되어 있습니다. 그렇기에 파트원들이 면담 일정을 추가할 때 google calendar에서 '시간 찾기' 기능을 사용하면 회의 가능한 시간을 찾아 주기도 하지만, 뭔가 좀 더 편한 방법이 없을까 고민했습니다. (생각..