[컴][머신러닝] GPT-3

이 글은 ref. 1 에 대한 일부 번역이다.

GPT-3

  • GPT-3는 일반적인 언어 기반 작업(tasks)을 해결할 수 있다. 전례없이 쉽게 글을 만들고, 분류하고 다른 글 스타일과 글 목적들 사이를 자유롭게 움직인다.
  • GPT-3 은 generic(포괄적인, 일반적으로 사용가능한) 언어 모델이다.

NLP(Natural Language Processing)

NLP 는 글(text)과 말하는 단어들을 사람과 같은 방식으로 이해하는 컴퓨터를 만드는 것과 관련한 AI 분야중 하나.

현재 NLP는 다음 것들을 가지고 있다.

  • 통계학적으로 계산을 요구하는 언어학 모델(사람 language modling 의 rule-based modeling)
  • 머신러닝 모델
  • 딥러닝 모델

NLP 는 ‘스팸처리’, 기계번역, 가상 도우미와 챗봇들, 소셜미디어 감정경향분석, 글자 요약 등에 사용

language model 은 자연어 처리(NLP) application 들에서 가장 중요한 구성요소이다. 통계학적인 예측 기계들로 생각하면 된다. 이 기계는 text 를 input 으로 주면, output 으로 예측되는 것을 준다. 폰에서 ‘자동완성’ 기능을 생각하면 된다.

GPT-3 이전에는 잘동작하는 generic language model 이 없었다. 언어 모델은 이미 존재하는 알고리즘 및 아키텍처를 사용해서 텍스트 생성, 요약 또는 분류와 같은 하나의 특정 NLP 작업를 수행하도록 설계되었다.

GPT-3

Generative model 들, 자체생산이 가능한 모델
이건 통계적 모델링의 한가지 이다.
수학적으로 세상을 어림짐작하는 방법
2개의 통계모델이 있다.
generative 와 discriminative

generative 모델들은 새로운 data 를 만들 수 있다.
Discriminative 모델들은 다른 종류의 data 를 식별할 수 있다.

generative model 을 훈련하려면, dataset 을 모으고,
이 dataset 은 모델이 특정 task 를 수행하는 법을 배우게 하는데 도움을 주는 예제들의 모음이다.
보통 특정 분야에 대한 많은 양의 data 이다. 예를 들면, ’차’가 무엇인지 알게 하기위해 차에 대한 몇백만개의 차 이미지들

Pre-trained model 들

잘 동작하는 model 을 만들려면, 그것을 ‘특정변수’들의 집합을 이용해서 훈련해야 한다. 이 특정변수가 parameter 이다.
model 내부에 있는 설정변수이다. 이 값들은 training data 로부터 측정된다.
모델의 이상적인 parameter 들을 결정하는 과정을 ’trainning’ 이라고 한다.
모델은 성공적인 trainning iteration 을 통해서 parameter 값들을 배운다.

pre-trained model 은 특정 문제를 풀기위해 만들어진 model 이다.
아무것도 없이 처음부터 model 을 만드는 대신에, 다른 문제에서 훈련된 model 을 이용할 수 있다.
pre-trained model 을 가져와서 좀더 구체적인 trainning 을 시켜줄 수 있다.

ML(machine learning) 에서 model 은 dataset 위에서 훈련된다. 해결하려는 task 에 따라 data sample 의 크기나 종류가 다양하다. GPT-3 는 5개의 dataset 들의 text corpus 를 이용해서 훈련됐다.

  • Common Crawl: petabyte 의 data, OpenAPI 에서 curated, filtered version 을 사용
  • WebText2 : WebText 의 확장버전, 내부의 OpenAI corpus 이다. 품질좋은 웹페이지 크롤링 해서 모은 자료다. 좋은 품질을 위해서 적어도 3개이상 karma 가 걸린 Reddit 에 걸린 outbound link 들을 scrap 했다. 450만 링크에서 800만이 넘는 문서에서 가져온 40GB 의 text 가 있다.
  • Book1, Book2 : 다양한 주제에 대한 많은 책에서 가져온 text 들
  • Wkikipedia : Wikipedia 에 있는 모든 영어 기사들, 대략 600만개 이상의 기사들

GPT-3 는 확장적인 다양한 text corpus에서 미리훈련됐다(pre-trained). GPT-3 는 놀랍도록 많은 NLP task 들을 성공적으로 수행한다. user가 추가적인 example data 를 제공하지 않아도 말이다.

Transformer model 들

2가지 종류의 신경 망

  • sequence-to-sequence model
  • transformer model

transformer model 의 아이디어는 [1706.03762] Attention Is All You Need 에서 나왔다.

sequence-to-sequence(Seq2Seq) 구조는 transformer model 의 근간(backbone) 이다.
Seq2Seq 는 문장의 단어(word) 같은 요소들의 순서를 바꿔서 다른 sequence 로 바꿔준다.
이 seq2seq 는 ‘text 요약’과 ’image captioning’ 에서 큰 성공을 거둔상황이다.

Seq2Seq 는 특히 번역에서 특히 좋다.
번역에서는 특정 언어에서의 단어의 순서를 다른 언어의 다른 단어들 순서로 변환해준다.
Google translate 은 2016년 후반부터 비슷한 종류의 model 을 이용하기 시작했다.

Seq2Seq 는 2개의 model 로 이뤄져 있다. Encoder와 Decoder
Ecoder 와 Decoder 는 각각 2개의 언어를 번역할 수 있다. 2개가 갖는 공통적인 언어가 있어서 Encoder 가 B라는 언어를 읽어서 A라는 언어로 번역하면, 그것을 Decoder 가 읽고 그것을 C라는 언어로 번역한다.

transformers 와 attention mechanisms

Transformer architecture 또한 하나의 sequence를 다른 sequence 로 변환한다.
마찬가지로, Encoder와 Decoder의 도움을 받지만 기존의 seq2seq와 차이점이 있다.
Transformer architecture 는 2017년에 발명됐는데, 기계 번역 task 들에 대한 Ai들의 성능을 향상시키기 위해 발명됐다.

attention mechanism은 ‘인지적 주의집중’(cognitive attention) 을 흉내낸 기술이다.
예를 들면, 사람이 글을 읽을때, 현재 단어를 읽겠지만, 문맥을 제공하기 위해서 이전의 읽은 문장의 증요한 키워드를 기억하고 있다.

attention mechanism 도 비슷하다.
Encoder가 문장의 의미에 중요한 키워드를 적어서, 번역과 함께 Decoder에 제공한다
이런 키워드들이 Decoder가 번역을 더 쉽게 하게 해준다.
문장의 어떤 부분이 중요한지, 어떤 용어가 문맥을 제공하는지를 알 수 있게 됐기 때문이다.

attention mechanism 은 transformer 가 잡음을 걸러내고, 관련성에 더 집중하게 도와준다.
즉, 서로 어떤 관계가 있는지 표시되어 있지 않은 2개의 연관있는 단어들을 연결한다.

Transformer model 들은 더 거대한 구조와 더 거대한 양의 data 로 부터 이익을 얻는다.
큰 dataset 들을 이용한 훈련과 특정 task 들에 대한 fine-tuning(미세조정)은 결과를 향상시킨다.

GPT-3 는 Open API 형태로 제공된다.

GPT-2 는 15억개 parameter 들과 40GB 의 text 에서 훈련됐다.
GPT-3 는 1750억개의 parameter 들과 570 GB 의 text 에서 훈련됐다.
GPT-2 가 몇몇 후속 task 들에서 사용할 수 없었지만, GPT-3 는 심지어 예제 context 만 있는 좀더 이전에 보지못한 새로운 task(novel task) 들에서도 수행가능하다.

See Also

  1. GPT-3 🤖 (@gpt_three) / Twitter
  2. https://github.com/abhagsain/ai-cli : gpt 3를 이용해서 cli명령어에 대한 help를 가져오는 예제

Referenence

  1. GPT-3 Building Innovative NLP Products Using Large Language Models

[컴][네트워크] 동시접속자수 ?

동접의 의미 / 동접 기준 / 동시접속자 측정방법 / 동시접속자 의미 / 기준 / 시간 기준 / 동시접속자 수에서 시간단위 / ccu /

동시접속자수 ?

ref. 1 의 댓글

웹서버의 경우와 게임의 경우는 동접을 계산하는 방식이 다릅니다. 웹의 경우 Connection Less이고 온라인게임의 경우 Connection Oriented입니다. 전자의 경우 사용자의 세션( 사용자를 인식할 수 있는 메모리공간 )를 유지하고 않고 ( 한번 접속하여 페이지를 넘겨주고 나면 세션을 마감합니다. ), 후자의 경우 사용자의 세션을 계속 유지합니다. 따라서 웹서버의 경우 동접자 계산은 임의로 타임 윈도우를 설정하고 이 사이에 요청된 커넥션 숫자로 결정하는 경우가 많습니다. 그러므로 어느정도 유동적입니다. ( 타임윈도우를 어떻게 설정하느냐에 따라서 달라지니까요. ) 이에 반해 게임의 경우 사용자세션을 계속 유지해줘야 하기땜에 말 그대로 동접 ( 동접 5만이면, 5만개의 사용자세션이 유지된다는 예기입니다. )입니다.

정리하면,

  • 웹 : 임의의 시간구간을 정하고, 이 사이에 요청된 connection 숫자, 즉, request 수를 이야기한다.
  • 게임서버 (tcp/ip 서버임을 가정할 때) : 현재 유지되고 있는 connection 의 수를 이야기한다.

저렇게 정의해도 빠져있는 부분은 시간에 대한 부분이다. 과연 ’동시’라는 것이 어느 시간구간(time window) 인지 정의하지 않으면, 값은 많이 달라진다. 10초에 10만명이 동시접속자라고 한다면, 1초에는 평균적으로 1만명의 동시접속자이다. 그러면 동시접속자 수를 이야기할때 10만명이라고 해야할지, 1만명이라고 해야할 지 애매하다.

ref. 2 에 보면, 시간구간이 ‘ms~s’ 사이라고 되어 있다.

ref. 3 에 보면, 한 개발자는 second(초) 를 기준 active user 를 계산 했다. 1초 동안의 active connection 을 계산했다.

ref. 4 를 보면, concurrent users 에 대한 정의를 좀 더 잘 이해할 수 있다. IBM 쪽에서 active users 와 concurrent users 를 구분했는데, 동시에 system resource 를 요청하는 user 수를 이야기한다. 즉, request 하는 user 수 request 에 대한 response 를 기다리는 user 가 모두 user수에 잡힌다.

그리고 ref. 4 에서 자신의 “IBM Cognos BI” 에서의 ratio 를 하나 이야기하는데, 대략적으로 10명의 active user 라면, 1명의 concurreent user 가 존재한다고 한다고 이야기한다.

이 부분을 ref.3 에 대입하면, 대략적으로 1초에 대한 active user 가 있다면, ’concurrent user 수’는 0.1s 시간동안의 active user 정도가 될 것이다.

Reference

  1. PHPSCHOOL-Community > 포럼, 2016-05-02
  2. GNUJAVA, 2009
  3. Possible to calculate CCU (Concurrent User) in each vHost? · Issue #36 · vozlt/nginx-module-vts · GitHub, 2016-03-28
  4. Estimating Concurrent Users - IBM Documentation, 2021-03-03

[컴] Reactor 에서 onErrorReturn, onErrorResume, onErrorContinue 의 차이

 java flux / spring flux / reactor

Reactor 에서 onErrorReturn, onErrorResume, onErrorContinue 의 차이

onErrorReturn

error 가 발생할 때 static 한 기본 값을 return 하려고 할때 쓰면된다.

// kotlin code

fun test(): Mono<String> {

    return Mono.just("test")
      .map{
        "return-test"
      }
      .doOnError{
        log.error('it.message')
      }
      .onErrorReturn("error-return")
}

onErrorResume

error 가 났을때 어떤 동작을 할지 함수를 할당할 수 있다. onError Resume 에서 return 하는 것으로 Flux 가 대체된다.(replace)

fun test(): Mono<String> {
    return Mono.just("test")
      .map{
        "return-test"
      }
      .doOnError{
        log.error('it.message')
      }
      .onErrorResume {
        Mono.just("error-return")
      }
}

onErrorContinue

Flux.range(1,5) 라는 stream 이 있다고 하고, 3번째에서 error 가 났다고 가정해보자. 그러면, onErrorContinue 는 3번째에서 error 관련 처리를 하고, 이어서 4번째 5번째 처리를 한다.

onErrorResume 인 경우3번째에서 끝난다. 그래서 이때 return 으로 다른 stream(Flux) 를 줘야 한다.

onErrorResume 과 doOnError 의 차이점

위 글에서 수도관을 예로 들어 잘 설명해준다.

요약하면, doOnError 는 log 등 pipeline 에 영향을 주지 않는 작업을 할 때 쓰이고, onErrorResume은 pipeline 의 stream 에 대한 변형등을 할 때 쓰인다.

See Also

  1. 쿠…sal: [컴] reactor의 flatMap vs map

Reference

  1. Flux (reactor-core 3.4.22)
  2. Reactor onErrorContinue VS onErrorResume
  3. Handling Errors in Spring WebFlux | Baeldung

[컴] javascript 에서 undefined 확인 방법

js undefined check / if / 검사 / undefined 확인 방법 / 에러나는 이유 /

javascript 에서 undefined 확인 방법

결론을 이야기하면, 정의되지 않은 변수에 대해서는 typeof myvar === undefined 로만 check 를 할 수 있다. 하지만 정의되지 않은 property 에 대해서는 다양한 방법으로 check 를 할 수 있다.

참고로, typeof myvar === "undefined" 가 처음에 있던 문법이고, typeof myvar === undefined 는 “5th Edition – ECMAScript 2009” 부터 도입됐다고 한다.[ref. 1]

아래처럼 defined 가 안된 myvar 을 check 할 수 있다.

if( typeof myvar === undefined ) {
    console.log('myvar is not defined')
}

정의되지 않은 property 는 다양한 방법으로 undefined 를 check 할 수 있다.


if( window.myvar === undefined ){
    console.log('myvar is not defined')
}

// or

if( window.myvar == null ){
    console.log('myvar is not defined')
}

// or

if( !window.myvar ){
    console.log('myvar is not defined')
}

// or

if( typeof window.myvar === undefined ){
    console.log('myvar is not defined')
}

하지만 아래처럼은 안된다.

if( myvar === undefined ) {
    // 여기로 오지 않는다.
    // ReferenceError 가 발생한다.
    console.log('myvar is not defined')
}
if( !myvar ) {
    // 여기로 오지 않는다.
    // ReferenceError 가 발생한다.
    console.log('myvar is not defined')
}

Reference

  1. How can I check for "undefined" in JavaScript? - Stack Overflow

[컴][웹] google 의 Manifest V3

 

MV3 / 파폭 / 파이어폭스 / 구글 크롬 문제 / 사용하지 말아야 하는 / 파폭을 이용해야 , 사용해야 하는 이유

google 의 Manifest V3

extension 이 사용할 수 있는 browser 의 기능을 제한하려 한다. 구글은 이것이 privacy 를 위한 것이라 하지만, 실제로 그렇지 않은 듯 하다.

firefox 는 크로스 브라우저 호환성을 위해 Mv3를 채택할 것이다.

그러나 2020년 애드블록커 개발 서밋에서 파이어폭스의 애드온 운영 관리자는 확장 보안 검토 프로세스에 대해 “악성 애드온의 경우 관리 가능한 수준이었다고 생각한다..add-on들은 대부분 bad data 를 낚아채는것에 관심이 있기 때문에, 그들은 여전히 현재 blocking 되지 않는 webRequest API 를 이용해서 그것을 할 수 있다.”

쉬운 영어로 이것은 악의적인 확장이 보안 검토 프로세스를 몰래 통과할 때 일반적으로 브라우저와 사용자가 방문하는 웹 사이트 간의 대화를 단순히 ’관찰’하는 데 관심이 있다는 것을 의미한다. 악의적인 활동은 데이터를 이미 읽은 후, 다른 곳에서 발생한다.

좀 더 철저한 검토 과정을 거치면 보안이 향상될 수 있지만 크롬은 그렇게 하겠다고 말하지 않은 상황이다. 대신, 그들의 해결책은 모든 확장에 대한 기능을 제한하는 것이다.

자세한 이야기는 ref. 1 에서 확인하자.

See Also

  1. 쿠…sal: [컴][웹] 개인정보보호 관련 브라우저 extension 은 성능에 대체로 좋은 영향을 미친다.

Reference

  1. Chrome Users Beware: Manifest V3 is Deceitful and Threatening | Electronic Frontier Foundation

[컴][웹] 개인정보보호 관련 브라우저 extension 은 성능에 대체로 좋은 영향을 미친다.

애드블록 / ad blocker / uorigin 성능, ad blocker 성능 확인 /크롬/파폭 / chrome extension / firefox extension / plugin /

개인정보보호 관련 브라우저 extension 은 성능에 대체로 좋은 영향을 미친다.

자세한 사항은 ref.1 을 보자.

  • 파란색은 유리한 extension 을 설치하지 않을 때 보다 좋은 성능을 나타낸다.
  • onContentLoad 는 최초 html 이 load 되는 것이다. 이 시점에 다른 resource 는 load 되지 않는다.
  • onLoad 는 실질적으로 resource 들이 load 되는 시점

Privacy Badger 의 동작

from. 1

blacklist 방법이 주로 쓰이나, 이 blacklist 에 등록되기 전까지 ads(광고들)은 여전히 노출된다. 이부분에 대한 보완으로 heristic algorithm 을 도입한 privacy extension 이 있다. 대표적인 예가 Privacy Badger 이다.

반복적으로 특정 속성들에 속하는 third-party content (즉, 슈퍼쿠키들)을 보고 있는다. 그리고 해당 request 들을 수정하거나 막는다(modify or block)

만약 third-party 가 legitimate content(규칙에 맞는 콘텐츠) 를 제공하면 노출이 된다. 이런 false positive들(틀린 positive, 즉 맞았는데 틀렸다고 판단하는 것)을 막기 위해서 Privacy Badger 는 third-party request 들을 항상 막지는 않지만, user 의 privacy 를 위해서 request 를 수정할 것이다. (즉, request 에서 cookie 들을 제거하는 등)

일반적으로 이런 heuristic 방법, 즉 tracking 에 대한 학습을 하는 것이 더 많이 성능에 영향을 미칠 것이다.

Reference

  1. Understanding the Performance Costs and Benefits of Privacy-focused Browser Extensions - www2020-privacy-extensions.pdf, 2020-04

[컴][db] mongo db 의 Aggregation pipeline 의 한계

 

몽고db / mongo / mongod / Aggregation 한계

mongo db 의 Aggregation pipeline의 한계

ref. 1 의 내용을 정리

결과 크기 제한

aggregate 명령은 커서를 반환하거나 결과를 collection에 저장할 수 있다. result set 의 각 문서는 16MB BSON Document Size Limit 이 적용된다. 단일 문서가 BSON 문서 크기 제한을 초과할 경우 aggregation은 오류를 생성합니다. limit 은 returned document 에만 적용된다. pipeline 처리 중에 document가 이 크기를 초과할 수 있다. db.collection.aggregate() 메서드는 기본적으로 커서를 반환다.

stage 개수 제한

aggregation 에서 한개의 pipeline 에서 가능한 stage 의 개수는 ver. 5.0 부터 1000개로 제한한다.

메모리 제한

각 pipeline stage 는 100MB RAM 으로 제한된다. 기본적으로 stage 가 한도를 넘으면, Mongodb 는 error 를 뿜는다.

몇몇 pipeline stage 들을 위해서 allowDiskUse option 을 이용해서, pipeline processing 이 더 많은 공간을 사용할 수 있게 해줄 수 있다. 이것은 aggregation pipeline stage 들이 임시 파일들에 data 를 write 할 수 있게 해준다.

References

  1. Aggregation Pipeline Limits — MongoDB Manual