이미지 + GPT로 여러가지를 시도해보던 중, 겪었던 어려움을 공유드립니다 :)그림에서 보듯이, GPT는 큰 글자나 명확한 글자도 인식하는 데 어려움을 겪을 수 있습니다."덖음"이라는 조리법에 해당하는 단어를 "더움"으로 완전히 오판하고있죠.이번 글에서는 왜 이런 현상이 나타나는지에 대해 포스팅 해보려 합니다. (w/ GPT)혹시 틀린 내용이 있다면, 댓글 부탁드립니다 :)1. GPT는 무엇을 "읽는다"고 하는가?GPT는 AI 언어 모델로, 실제로 이미지를 보고 "읽는" 능력은 제한적입니다. 여기서 "읽는다" 는 것은 사람이 글을 읽는 것과는 다른 방식입니다.GPT는 OCR을 이용하기도 하지만, 사람처럼 글자를 시각적으로 읽는 것이 아니라 텍스트를 확률적 패턴과 기계 학습을 기반으로 "예측" 합니다.즉, 주어진 텍스트 나 이미지를 보고 가능한 단어의 조합을 예측하는 방식인거죠. 따라서, 사람이 인지하는 '읽는다'와는 다릅니다.그래서 학습할때 잘 나오지 않은 단어이거나 (학습 편향) 화면상에서 텍스트가 잘린 경우 등에는 특히 잘못 읽을 수 있습니다.2. GPT가 인식하지 못하는 UI의 문제들GPT는 텍스트 오버플로우(텍스트 잘림)와 같은 시각적 문제를 잘 인식하지 못합니다.텍스트가 화면에서 잘리거나 일부만 표시되는 상황을 사람은 쉽게 인 식하지만, GPT는 이를 텍스트의 완전한 형태로 인식할 수도 있는거죠.아래는 그 예시 화면입니다.저는 GPT에게 글자가 잘린 결함을 식별해보라고 시켰습니다.파란 박스를 보시면, [전체글]의 "글", [공지사항]의 "사항"이 잘려 보입니다.이것을 GPT는 어떻게 판단했을까요?[전체글]의 "글"은 반만 잘렸으니 인식한걸수도 있다 치더라도, [공지사항]의 "항"은 어디에서도 찾아볼 수 없는 글자입니다.하지만 GPT는 이미지 안에 "공지사항"이라는 글자가 있다고 인식을 했습니다.글자가 잘린 걸 확인하고 싶었던건데, GPT는 없는 글자를 만들어서 읽어버린거죠.또 다른 예시로 첫번째 사진이었던, [덖음]으로 돌아가봅니다.사람이 보기에는 명백히 덖음으로 읽혀야 하지만, GPT는 이를 "더운"으로 잘못 읽는 경우가 생겼었죠?GPT에게 물어보니 이유는 다음과 같습니다.이런 이유로, GPT는 단어를 문자 그대로 읽지 못하고, 오히려 자주 접한 패턴을 기반으로 잘못된 결과를 반환할 수도 있습니다.GPT의 강점인 맥락의 이해가, 이런 형태의 아쉬움이 될 수도 있겠네요.예시로 드린 두 가지의 문제에 대하여, 원하는 수준에 달성하기 위해 여러가지로 시도를 해보고 있습니다.• None 자음+ 모음을 별도로 인식 후 조합• None 글자가 잘렸다는 가정하에 GPT에게 질의OCR을 활용하는 방법이 그나마 정확도가 높았으나, 세 방법 모두 완전히 원하는 수준에 Meet하지는 못했습니다.계속 방법을 찾고 있는 중입니다 ^^;현재 GPT와 같은 AI 언어 모델은 텍스트 인식과 해석에서 몇 가지 중요한 한계를 가지고 있습니다.예를 들어, "덕음"을 더움"으로 잘못 읽는 사례처럼 AI는 단순히 글자를 문자 그대로 읽지 않고, 패턴과 확률 기반으

A.(에이닷)과 같은 대규모 사용자 시스템에서는 접속 중인 사용자의 정보를 실시간으로 파악하는 것이 매우 중요합니다.이러한 정보는 사용자에게 적절한 추천을 제공하거나 필요한 조치를 취할 때 지연을 최소화하는 데 필수적입니다.이 글에서는 실시간 접속자 관리를 위한 데이터 구조 설계 방법을 소개하고, 특히 확률형 자료구조인 Cuckoo Filter를 활용한 접근법을 알아보도록 하겠습니다.A.(에이닷)과 같은 서비스에서는 수많은 사용자가 동시에 접속해 있으며, 이들을 효율적으로 관리하는 것은 시스템 성능에 중요한 영향을 미칩니다.모든 사용자의 접속 정보를 저장하고 관리하기 위해서는 상당한 메모리와 자원이 필요하며, 이 과정에서 성능 저하를 초래할 수 있습니다.• None 메모리 사용량 증가: 사용자가 늘어남에 따라 접속 여부를 확인하고 이를 저장하는 데 필요한 메모리 사용량이 급격히 증가합니다. 이 경우, 메모리 사용량은 O(n)으로 증가하며, 이는 작은 규모에서는 문제가 없을 수 있지만 대규모 사용자 기반에서는 심각한 성능 저하를 야기할 수 있습니다.• None 실시간 처리의 부하: 사용자의 접속 여부를 실시간으로 처리하려면 지속적인 계산과 데이터 업데이트가 필요합니다. 이 과정에서 시스템은 상당한 계산 자원과 처리 능력을 요구하게 되며, 특히 피크 시간대에는 서버의 부하가 급격히 증가할 수 있습니다. 이는 결국 시스템의 응답 속도 저하와 전체적인 성능 저하로 이어질 수 있습니다.확률형 자료구조의 도입: Bloom Filter와 그 한계이러한 문제를 해결하기 위해 확률형 자료구조의 도입을 고려할 수 있습니다.확률형 자료구조란 대용량 데이터를 효율적으로 처리하기 위해 정확성을 일부 희생하는 자료구조입니다. 어떻게 동작하는 것일까요?대표적인 확률형 자료구조인 Bloom Filter의 작동원리를 통해 알 수 있습니다.집합 내에 특정 원소가 존재하는지를 검사하는데 사용할 수 있는 자료구조입니다. 구조를 도식화 해보면 다음과 같습니다.저장할 값인 value를 n개의 Hash Function을 거치게 하고, 각각의 Hash Function의 결과로 나온 인덱스의 bitmap값을 1로 설정해줍니다.모든 값에 대해 이 과정을 거치면 원소들의 존재유무를 저장하고 있는 bitmap이 만들어집니다.데이터를 확인하는 과정은 저장하는 과정과 비슷합니다.존재유무를 확인할 value를 동일한 Hash Function에 넣어주고, bitmap의 인덱스 값이 모두 1이면 집합 내에 존재한다고 판단하는 구조입니다.많은 데이터가 있어도 bitmap으로 값을 저장할 수 있기 때문에 저장공간을 엄청나게 아낄 수 있습니다.하지만 Hash Function의 특성상 다른 value임에도 동일한 bitmap 인덱스를 반환할 수 있습니다.즉, hash collision이 일어나 없는 값을 있다고 말하는 경우도 발생합니다. 이는 False Positive(거짓 양성)의 원인이 됩니다.하지만, 곧 설명드릴 특성으로 인해 삭제가 불가능하므로, False Negative(거짓 음성) 오류가 발

geuru.geon DevSecOps에서 Sonarqube가 어떤 역할을 하는지 쉽게 파악할 수 있는 글입니다! 평소 Sonarqube 도입에 대해 고민하고 계셨다면, 이번 기회에 안전한 코드로 서비스를 운영해 보시는 건 어떨까요? 😀owen.kh DevSecOps 환경 구성을 위해 카카오페이는 어떤 방향성를 가지고 있는지 알기 좋은 글입니다. 관련해 비슷한 고민을 하는 많은 담당자 분들께 도움이 되었으면 좋겠습니다~안녕하세요, 카카오페이 SRE팀 RE파트 데이빗입니다. 오늘은 DevSecOps와 Sonarqube에 대해 깊이 있게 알아보려고 해요. 어렵게 들리시나요? 걱정 마세요. 차근차근 설명해 드릴게요.DevSecOps가 뭔가요?DevSecOps는 Development(개발), Security(보안), Operations(운영)을 하나로 뭉친 말인데요. 쉽게 말해 “우리 처음부터 끝까지 보안에 신경 쓰면서 개발하자!”라는 뜻이에요. 예전에는 개발을 다 하고 나서 “자, 이제 보안 점검 좀 해볼까?” 하는 식이었어요. 마치 집을 다 짓고 나서 “앗, 도둑이 들어올 수 있겠네. 자물쇠를 달아야겠다!”라고 하는 것과 비슷하죠. DevSecOps는 집을 설계할 때부터 보안을 고려하는 거예요. “이 창문은 좀 위험해 보이니 특수 유리를 쓰자”, “현관문은 이중잠금장치로 하자” 이런 식으로요. 개발할 때도 코드 한 줄 쓸 때마다 “이 로직은 안전한가? 보안에 문제없나?” 생각하면서 만드는 거죠.DevOps와의 차이“그럼 DevOps랑 뭐가 다른데요?”라고 물으실 수 있어요. DevOps가 개발과 운영을 하나로 묶었다면, DevSecOps는 여기에 보안을 더한 거예요. DevOps를 맛있는 케이크를 만드는 과정이라고 생각해 볼까요? 개발팀이 케이크를 구워서 운영팀에게 건네주는 거죠. DevSecOps는 여기에 “케이크에 유해 성분은 없는지, 알러지 유발 물질은 없는지” 확인하는 과정을 추가한 거예요. 더 안전하고 믿을 수 있는 케이크를 만드는 거죠!• 보안을 핵심 요소로 강조• 보안 팀과의 긴밀한 협업전통적인 개발 방식과의 차이전통적인 개발은 마치 릴레이 경주 같았어요. 개발팀이 달리고, 그다음 보안팀이 달리고, 마지막으로 운영팀이 달리는 식이었죠. DevSecOps는 달라요. 세 팀이 손을 잡고 같이 달리는 거예요. 시작부터 끝까지 함께 가는 거죠. 이러면 중간에 실수가 생겨도 빨리 발견할 수 있고, 서로 도와가며 더 빠르고 안전하게 목표에 도달할 수 있어요.DevSecOps를 실제로 구현하려면 어떻게 해야 할까요? 세 가지 핵심 요소가 있어요.자동화와 보안 통합은 DevSecOps의 핵심 요소예요! 자동화는 수동으로 수행하던 많은 보안 관련 작업들을 자동화함으로써 효율성을 높이고 인적 오류를 줄일 수 있어요. 예를 들어 볼까요? 여러분이 매일 아침 100개 이상의 보안점검을 한다고 생각해 보세요. 끔찍하죠? 하지만 보안점검을 진행하고 리포트해 주는 서비스가 있다면 어떨까요? 버튼 하나만 누르면 카테고리와 점검 요약 정보들로 알려주니 훨씬 편

안녕하세요. Security R&D 팀에서 FIDO2 클라이언트 개발을 담당하고 있는 김도연, 김영현입니다.공개 키 암호화를 기반으로 한 FIDO는 패스워드나 SMS OTP 인증과 비교했을 때 사용자 관점에서는 사용하기 쉽고 안전하며 서비스 관점에서는 배포 및 유지 보수하기 쉬운 인증 표준입니다. FIDO 관련 자격 증명은 사용자의 기기를 벗어나지 않고 서버에도 저장되지 않기 때문에 피싱(phishing)이나 모든 형태의 패스워드 도용 및 재전송 공격의 위험에서 벗 어날 수 있습니다.저희 회사는 2017년 FIDO 얼라이언스 이사진에 가입한 것을 시작으로 FIDO 서버의 상호 운용성 테스트 행사에 참여하는 등 FIDO와 관련한 여러 가지 이벤트에 참여했습니다. 그리고 2021년에는 서비스 제공 업체로서 전 세계 최초로 FIDO Universal Server 인증을 획득한 FIDO2 서버를 오픈소스로 공개했습니다. 이전에 패스워드 없는 세상으로의 첫 발걸음과 FIDO2 서버를 오픈 소스로 공개했습니다라는 글로 이와 관련된 내용을 소개했는데요. 이번 글에서는 새롭게 오픈소스로 공개하는, WebAuthn 표준을 따르는 FIDO2 클라이언트 SDK를 소개하려고 합니다. 클라이언트 측에서 FIDO2 인증을 구현할 때 이 SDK를 사용하면 더욱 쉽게 FIDO2 인증을 구현할 수 있습니다.패스워드 등의 지식 기반 인증(knowledge-based authentication)을 사용하는 기존 인증 기술을 대체하기 위한 새로운 인증 표준인 FIDO(Fast Identity Online)는 소유 기반 인증(possession-based authentication)을 활용한 인증 방식을 제안합니다.전통적인 인증 방식인 지식 기반 인증은 사용자와 서버가 사전에 설정해 공유한 지식을 기반으로 하는 인증 방식입니다. 사용자 입장에서는 패스워드와 같은 지식을 외우고 있어야 한다는 불편함이 있으며, 공격자가 사용자의 패스워드를 유추하거나 서버에 저장된 패스워드가 유출될 가능성이 있어 보안 사고에 매우 취약합니다.소유 기반 인증은 사용자가 소유하고 있는 기기를 기반으로 인증을 수행하는 방식입니다. FIDO의 인증 기술은 사용자의 기기를 인증기(authenticator)로 활용합니다. 사용자의 인증 정보(예: 생체 정보)는 기기에만 저장되고 서버에는 전달되지 않기 때문에 서버 입장에서는 보안을 한층 더 강화할 수 있습니다. 사용자는 패스워드를 기억할 필요가 없으며, 사용자만이 가지고 있는 정보를 통해 안전하고 쉽게 인증할 수 있습니다.FIDO1과 FIDO2의 차이는 다음과 같습니다.• FIDO1: FIDO1은 UAF(Universal Authentication Framework)와 U2F(Universal 2nd Factor)라는 두 가지 프로토콜을 포함합니다. UAF는 패스워드 없는 인증을 제공하는 프로토콜이고, U2F는 기존 패스워드 기반 인증에 보안 요소를 추가한 프로토콜입니다.• FIDO2: FIDO2는 FIDO1이 확장된 버전으로, WebAuthn(Web Au

안녕하세요. 여기어때컴퍼니 DevOps팀 루카스입니다. 저희 팀은 여기어때컴퍼니 Tech 조직내 개발자들의 업무 몰입을 위한 개발 환경과 체계를 만들어가는 조직으로 조직별로 상이한 개발 환경을 통합하고 운영하고 있습니다.Photo by Pankaj Patel on Unsplash이번에 다룰 주제는 팀에 합류하고 나서 첫 번째 작업이었던 GitLab 버전 업그레이드 과정입니다. GitLab은 소프트웨어 개발자에게 강력한 기능을 제공하는 형상 관리 플랫폼입니다. 하지만 최신 기능을 활용하고 보안 업데이트를 적용하기 위해서는 정기적으로 업그레이드를 해야 합니다. 우리 조직내 개발자들이 더욱 안전한 환경에서 신규 기능을 활용 할 수 있도록 저희팀은 GitLab을 업그레이드 하기로 결정하였습니다.1. 사전 준비1–1. Upgrade Path 확인GitLab의 현재 설치된 버전과 호환성을 확인합니다. 이런 경우에는 GitLab의 공식 문서에서 지원되는 업그레이드 경로를 확인하는 것이 좋습니다. https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/ 이 URL에서 현재 사용 버전, OS, 업그레이드 대상 버전 등을 선택하면 어떤 버전의 순서로 업그레이드를 해야하는지 알려 줍니다. 버전 변경에 대한 큰 변동사항에 대해서도 미리 경고해 줍니다.여기어때에서는 GitLab 15.1.6을 사용하고 있었으며, 16.9.4 버전으로 업그레이드를 진행하였습니다.15.1.6에서 16.9.4로 Upgrade Path는 다음과 같습니다.15.1.6 → 15.4.6 → 15.11.13 → 16.1.6 → 16.3.7 → 16.7.7 → 16.9.1Upgrade Path의 경고 마지막 부분에 Expiring Access Token 부분이 있었습니다. Gitlab PAT 관련 문서를 통해 추가로 확인해 보았습니다. https://docs.gitlab.com/ee/user/profile/personal_access_tokens.htmlNever Expire로 발급된 Personal Access Token은 모두 GitLab 16.0으로 업그레이드한 날짜로부터 1년 후에 만료 되도록 강제로 변경 됩니다. CI/CD Pipeline 자동화를 위해서 사용되는 토큰인 경우, 만료시 장애를 일으킬 수 있는 원인이 되기 때문에 사전 작업을 진행합니다.1) 기존 버전의 Personal Access Token의 만료일이 Never인 Token을 리스트업합니다.$ curl -s --header "PRIVATE-TOKEN: ${your_access_token}" "https://${gitlab url}/api/v4/personal_access_tokens" | jq '.[] | {id, expires_at}'결과 샘플은 다음과 같습니다.{ "id": 154, "name": "GITLAB-PAT", "expires_at": "2025-06-25"}your_access_token 은 admin 권한을 갖는 계정의 Personal Access

안녕하세요. 여기어때컴퍼니 SRE팀에서 클라우드 엔지니어링 업무를 하고 있는 제이슨입니다. 저는 오늘 조금은 특이했던 경험을 공유드리려고 하는데요, Docker를 이용해서 서비스하는 인스턴스의 CodeDeploy 배포 실패를 Troubleshooting하는 과정에서 겪은 일입니다.회사마다 다르긴 하지만 일반적으로 AWS 환경에서 배포할 때는 아래와 같은 방법으로 하게 됩니다.AWS 환경에서의 일반적인 배포 프로세스1. 사건의 시작평화로웠던 어느 오전… 갑자기 TargetGroup의 인스턴스가 unhealthy 상태로 되었다고 슬랙 모니터링 채널에 알림이 올라왔습니다. 이제 어떤 문제가 있는지 인스턴스를 확인해 봐야겠네요.2. 문제 해결을 위한 체크 리스트 확인인스턴스 확인우선 인스턴스가 On-Demand 혹은 Auto Scaling으로 구성되었는지를 확인 합니다. 문제의 인스턴스는 Auto Scaling으로 구성되어 있었고 TargetGroup의 Health Check 실패로 인해 Auto Scaling 정책에 따라 인스턴스 교체가 반복되는 상황이었습니다.2. CodeDeploy 상태 확인1번 확인으로 CodeDeploy에서 이력을 확인해보니 배포 실패가 반복되고 있었습니다.CodeDeploy의 배포 과정 중 어떤 부분에서 문제가 있었는지 자세히 확인해 보니 ValidateService 단계에서 TimeOut으로 실패했네요.CodeDeploy의 ValidateService 단계에서 발생한 문제를 확인하기 위해서는 CodeDeploy 배포 프로세스를 알아야 할 필요가 있습니다.담당 개발자에게 문의할 수도 있지만 Jenkins에서 Build 후 업로드된 xxxx.tar.gz 파일을 S3 버킷에서 다운로드하여 압축을 풀게되면 아래 그림에서 보는 것처럼 CodeDeploy 배포 프로세스를 정의하는 appspec.yml 파일을 확인할 수 있습니다.CodeDeploy 배포 프로세스CodeDeploy에서 확인한 것과 같이 AfterInstall 단계까지 정상적으로 수행 되었지만 ValidateService 단계에서 문제가 발생한 것으로 보입니다. 그렇다면 이전 단계에서 문제가 발생했을 가능성이 큽니다. AfterInstall 단계를 점검해 보니 Docker를 사용해서 Application을 서비스한다는 것이 확인되네요.[root@ip-xx-x-xx-xxx ~]# cat appspec.ymlversion: 0.0os: linuxfiles: - source: / destination: /home/xxxx/deploy/xxxxxx-api/temppermissions: - object: /home/xxxx owner: xxxx group: xxxx mode: 775hooks: BeforeInstall: - location: BeforeInstall.sh timeout: 60 AfterInstall: - location: AfterInstall.sh timeout: 60 ApplicationStart

오픈소스 AI Platform인 Kubeflow를 도입 후 Pipeline 쪽 기능을 주로 사용하면서 얻은 경험, 느낀점을 적어 보려고 합니다.Kubeflow는 Kubernetes 상에서 머신러닝(ML) 워크플로우를 구축하고 배포하기 위한 오픈소스 플랫폼입니다.이름에서 알 수 있듯이, Kubeflow는 'Kubernetes'와 'TensorFlow'를 결합하여 탄생했으며,원래는 Google이 Kubernetes에서 TensorFlow 작업을 원활하게 수행할 수 있도록 개발했습니다.현재는 다양한 머신러닝 프레임워크를 지원하며, Kubeflow는 ML 모델의 개발, 훈련, 배포 및 관리에 필요한 모든 요소를 통합하여 제공합니다.Kubernetes의 이점을 머신러닝에 통합Kubeflow는 Kubernetes의 확장성, 가용성, 관리 용이성을 활용하여 ML 워크플로우를 지원합니다.Kubernetes의 컨테이너 오케스트레이션 기능을 통해 ML 작업을 효율적으로 배포하고 관리할 수 있습니다.데이터 준비, 모델 training, 하이퍼파라미터 튜닝, 모델 serving 등 머신러닝의 전체 라이프사이클을 관리하는 통합 환경을 제공합니다.이를 통해 데이터 사이언티스트, 머신러닝 엔지니어, 데이터 엔지니어들이 협력하여 효율적으로 작업할 수 있습니다.모든 환경에서 일관된 운영Kubeflow는 클라우드, 온프레미스, 하이브리드 환경에서 모두 동일하게 동작하도록 설계되었습니다.이를 통해 특정 환경에 구애받지 않고, 동일한 ML 워크플로우를 구축하고 실행할 수 있습니다.다양한 머신러닝 프레임워크와 도구를 지원하여 사용자가 원하는 구성 요소를 선택하고 확장할 수 있도록 합니다.Kubeflow의 주요 구성 요소복잡한 머신러닝 워크플로우를 정의하고 자동화하기 위한 도구입니다.파이프라인을 구성하여 데이터 전처리, 모델 훈련, 검증 및 배포 등 일련의 작업을 순서대로 실행할 수 있습니다.파이프라인은 코드로 정의되며, 다양한 컴포넌트를 재사용할 수 있어 관리와 유지 보수가 용이합니다.학습된 모델을 Kubernetes 클러스터에서 실시간으로 서빙할 수 있는 기능을 제공합니다.이는 모델을 API 엔드포인트로 노출시켜 애플리케이션에서 쉽게 사용할 수 있도록 합니다.KFServing은 스케일링, 롤백, 모니터링 등의 기능을 통해 모델 서빙을 안정적으로 관리합니다.하이퍼파라미터 튜닝 및 자동 머신러닝(AutoML)을 위한 도구입니다.Katib을 사용하면 다양한 하이퍼파라미터 조합을 자동으로 탐색하여 최적의 모델 성능을 찾을 수 있습니다.TensorFlow 및 PyTorch와 같은 특정 머신러닝 프레임워크를 Kubernetes에서 실행할 수 있도록 지원합니다.이를 통해 대규모 분산 학습이 가능해지며, 클러스터 리소스를 효율적으로 사용할 수 있습니다.Jupyter Notebooks 환경을 Kubernetes에서 호스팅하여 데이터 사이언티스트가 브라우저를 통해 데이터를 탐색하고, 모델을 개발할 수 있도록 합니다.이러한 노트북 환경은 쉽게 확장 가능하며, Kubeflow의 다른 구성 요소

LLM-as-a-Judge는 생성된 데이터셋과 실제 데이터셋을 비교하여 평가하고, 이를 통해 모델의 응답 품질을 지속적으로 개선하는 평가방식입니다.LLM-as-a-judge로 Chatbot Arena를 MT-bench 방식으로 LLM 평가 결과논문에 따르면 MT-bench의 전문가 투표와 Chatbot Arena에서 수집된 크라우드 투표 결과를 비교했을 때GPT-4 judge와 사람의 선호의 일치도가 80% 이상으로, 사람간의 평가와 유사한 성능을 보여 관심을 갖게 되었습니다.(https://arxiv.org/abs/2306.05685)LLM-as-a-Judge는 대형 언어 모델(LLM)을 평가하고 개선하기 위한 방법으로, 사람이 평가하는 것처럼 LLM이 다른 모델의 출력을 평가하는 방식입니다.이 접근법은 다음과 같은 장점을 가지고 있습니다:• None 스케일러빌리티: 사람이 직접 평가하는 데 드는 시간과 비용을 절감할 수 있습니다. 이를 통해 대규모 평가 작업을 보다 효율적으로 수행할 수 있습니다• None 설명 가능성: LLM이 제공하는 평가 결과는 이유와 함께 설명될 수 있어, 평가 과정이 투명하고 이해하기 쉽게 됩니다• None 인간 선호도와의 일치: LLM을 사용한 평가가 인간의 평가와 높은 일치율을 보이므로, 신뢰할 수 있는 평가 결과를 얻을 수 있습니다LLM-as-a-Judge는 다음과 같은 과정을 거쳐 사용됩니다:• None 평가 기준 파악하기 - 먼저 hallucination, toxicity, accuracy 또는 기타 특성 등 무엇을 평가할지 결정합니다.• None 평가 프롬프트 작성 - 평가를 안내할 프롬프트 템플릿을 작성하세요. 이 템플릿은 출력을 효과적으로 평가하기 위해 초기 프롬프트와 LLM의 응답 모두에서 필요한 변수를 명확하게 정의해야 합니다.• None 평가 LLM 선택 - 특정 평가를 수행하기 위해 사용 가능한 옵션 중에서 가장 적합한 LLM을 선택합니다.• None 평가 생성 및 결과 보기 - 데이터 전체에서 평가를 실행합니다. 이 프로세스를 사용하면 수동으로 주석을 달 필요 없이 포괄적인 테스트를 수행할 수 있으므로 신속하게 반복하고 LLM의 프롬프트를 구체화할 수 있습니다.이 방법은 특히 RAG(질문 응답 생성) 시스템의 평가에도 유용하게 사용될 수 있습니다.https://huggingface.co/learn/cookbook/llm_judge를 따라 한번 적용해 봅니다.1. 사람의 평가 데이터 세트 생성첫 번째 단계는 30개 정도 예제에 대해 사람의 평가 데이터 세트를 만듭니다.각 질문/답변 커플에 대한 2개의 인간 평가와 점수를 포함하는 피드백QA 데이터 (https://huggingface.co/datasets/McGill-NLP/feedbackQA)를 사용합니다.두 사람의 평가자가 부여한 점수의 피어슨 상관관계로 측정한 두 평가자 간의 일치도를 보면 0.53이 나옵니다.이를 해결하기 위해 ratings.loc[ratings["score_1"] == ratings["score_2"]] 인 동일한

yun.cheese 코틀린 매력에 푹 빠진 개발자의 생생한 경험을 통해, 실제 서비스 개발에 바로 적용할 수 있는 코틀린 활용 꿀팁들을 얻어가세요!noah.you 복잡한 보험의 요구사항들을 해결하기 위한 이유 있는 코틀린 사용 사례! 좋은 사례들 많으니 많이 보고 가세요!ari.a 카카오페이에서는 왜 서비스의 백엔드를 개발할 때 코틀린을 사용하는 걸까요? 궁금하신 분들에게 카펀의 코틀린 사용 사례를 추천드립니다!안녕하세요. 카카오페이 보험마켓파티에서 보험 비교 추천, 내 차 관리 서비스 등을 개발하고 운영하는 카펀입니다.여러분은 어떤 언어를 사용하여 개발을 하고 계신가요? 카카오페이에서는 저희 보험 서비스를 비롯한 다양한 서비스의 백엔드 서비스 개발에 코틀린을 사용하고 있습니다.카카오페이에 합류하기 전에는 코틀린을 경험해 본 적이 없었지만, 실제로 사용하면서 코틀린의 다양한 장점과 편리함에 매료되었습니다. 예를 들면 다음과 같은 코틀린의 매력이 있습니다.• 코틀린을 사용함으로써 서비스를 보다 견고하고 안정적이며, 효율적으로 운영하고 있습니다.• 특정 도메인에 대한 내용을 쉽게 모아서 관리하거나, 저희 서비스만을 위한 라이브러리를 간편하게 만들었습니다.• 목적과 대상이 명확한 테스트 코드 작성 역시 코틀린을 통해 손쉽게 작성하였습니다.카카오페이에 합류해 코틀린으로 여러 서비스를 개발하고 운영하면서 직접 경험한 코틀린의 매력을 소개해 보고자 합니다. 여러 매력 포인트 중 코틀린의 4가지 매력 포인트를 정리했습니다. 저와 마찬가지로 안정적인 웹 서비스 개발에 관심 있는 백엔드 개발자 분들이 읽어 보시면 좋습니다.생성 시 값이 검증되는 객체 만들기어떤 값을 나타내는 VO1를 만들 때, 이따금 입력 값을 변환하거나 검증이 필요한 경우가 있습니다. 검증 로직을 별도 클래스로 분리할 수도 있지만, 매번 별도로 검증 로직을 호출해야 한다면 실수로 검증을 누락할 가능성이 있습니다. 코틀린의 다양한 기능을 활용하여 간결하면서도, 검증을 통과하였음이 보장되도록 작성하는 예시를 소개합니다.자동차 번호를 나타내는 VO가 있습니다. 코틀린의 Value Class를 사용합니다.Value Class는 코틀린에서 값을 나타내기 위한 wrapper 클래스입니다. 단 하나의 불변 필드만을 가질 수 있고, JVM 환경에서 컴파일 시 class를 벗겨 내고 내부의 값으로 대체합니다. 덕분에 primitive 타입의 값을 객체와 같이 다룰 수 있으며, 동시에 wrapper 클래스 사용 시의 오버헤드 문제를 해결할 수 있습니다. 자세한 내용은 Reference의 Project Valhalla 내용을 확인해 주세요.자동차 번호에는 아래와 같은 규칙이 있다고 가정하겠습니다.• 자동차 번호 형식은 아래 중 하나여야 함인스턴스 생성 시, 아래 과정을 거치고 싶습니다.• 지역명은 주어진 목록 내에서만 사용 가능(서울, 경기, 대전 등등), 아닐 경우 예외 발생• 지역명이 없는 경우 앞 숫자는 2~3자리, 뒤 숫자는 4자리• 지역명이 있는 경우 앞 숫자는 1~2자리, 뒤 숫자는 4자리이를

이 글은 Perplexity(https://www.perplexity.ai/)와 함께 작성하였습니다.SKT고객은 Perplexicy Pro를 1년간 무료로 이용할 수 있습니다.: https://perplexity.sktadotevent.com/Elasticsearch는 오픈소스 프로젝트로 시작했으며, 그동안 여러 번의 라이선스 정책 변경을 겪었습니다.처음에는 Apache 2.0 라이선스 하에 배포되었지만, 2021년 Elastic은 Elastic License 2.0과 Server Side Public License로 라이선스를 변경했습니다.이후 2024년 8월 30일에는 다시 AGPL-3.0을 추가하는 발표(Elasticsearch is Open Source, Again)를 하면서 주목을 받고 있습니다.이러한 변화는 오픈소스 커뮤니티뿐만 아니라 이를 사용하는 기업들에도 큰 영향을 미치고 있습니다.이번 글에서는 Elasticsearch가 왜 다시 라이선스 정책을 변경했는지, 그리고 이를 사용하는 기업들이 어떻게 대응해야 하는지 살펴보겠습니다.1. Elasticsearch 라이선스 변경의 역사1.1 Apache 2.0에서 Elastic License 2.0으로의 전환Elasticsearch는 처음에 Apache 2.0 라이선스를 사용했으나, 2021년 1월 Elastic은 Elastic License 2.0과 SSPL로 전환했습니다.Elastic이 이러한 변화를 선택한 이유는 클라우드 제공자, 특히 AWS와의 경쟁 때문입니다.AWS는 Elasticsearch를 기반으로 한 자체 서비스를 제공하면서도, 이에 대한 기여나 비용 지불 없이 수익을 창출했기 때문에 Elastic은 이를 견제하고자 라이선스를 변경했습니다.Elastic License 2.0은 소스 코드를 공개하지만 상업적인 클라우드 서비스에서의 사용을 제한하는 라이선스로, Elastic의 기술적 자산을 보호하는 수단으로 활용되었습니다.AWS는 이에 대응해 OpenSearch 프로젝트를 시작하며 Apache 2.0 라이선스를 계속 유지했습니다.이에 대해서는 이전 블로그, “Elastic License 2.0 그리고 진화하는 오픈소스 라이선스“에서 자세히 다룬 바 있습니다.1.2 Elastic License 2.0는 오픈소스 라이선스가 아니다그러나 Elastic License 2.0은 **Open Source Initiative (OSI)**에서 인정하는 오픈소스 라이선스가 아니었습니다.이는 오픈소스 커뮤니티에서 논란을 불러일으켜습니다.Elastic의 결정은 오픈소스의 자유로운 사용과 상업적 이익 사이에서 갈등을 불러일으켰고, 기업들이 오픈소스를 도입할 때 라이선스 문제에 대한 경각심을 높이는 계기가 되었습니다.2024년 8월, Elastic은 GNU Affero General Public License v3 (AGPL-3.0)를 Elasticsearch와 Kibana의 무료 부분에 대한 라이선스 옵션으로 추가한다고 발표했습니다.AGPL-3.0은 네트워크를 통한 소프트웨어 사용에 대해서