Beauty Domain-Specific Pre-trained Language Model 개발하기

안녕하세요. 화해팀 데이터 사이언티스트 김수진, 윤성민입니다. Pre-trained Language Model

 

오늘은 화해에서 개발한 뷰티 도메인 최초의 언어 모델인 Hwahae PLM(Pre-trained Language Model)에 대해 공유해드리려고 합니다.

 

 

화해는 약 600만 개의 클린 리뷰 데이터와 매일 약 26만 건씩 적재되는 검색 데이터 등 많은 양의 텍스트 데이터를 보유하고 있는 명실상부 대한민국 1등 뷰티 앱입니다. 화해팀은 우리가 가진 데이터를 어떻게 잘 가공해서 앱을 이용하는 고객들에게 더 좋은 서비스로 돌려드릴 수 있을지를 지속적으로 고민해 왔는데요, Hwahae PLM 개발의 출발점이 된 저희의 질문도 바로 여기에서 시작되었습니다.

 

“화해가 가진 텍스트 데이터를 어떻게 서비스에 더 잘 녹여낼 수 있을까?”

“고객들에게 더 좋은 가치를 제공하기 위해서는 어떤 기술이 필요할까?”

 

이를 위해 저희는 뷰티 도메인에서 텍스트 데이터를 좀 더 똑똑하게 처리할 수 있는 언어 모델을 만들어서 자연어처리 기술이 활용되는 여러 서비스에 접목시켜보고자 했습니다.

 

 

 

 

PLM이란?

 

PLM이란?

PLM이란 Pre-trained Language Model의 약자로, ‘사전에 학습시킨 언어 모델’을 의미합니다. 많은 양의 텍스트 데이터를 활용하여 일반적인 수준의 ‘언어 이해(language understanding)’가 가능하도록 모델을 사전 훈련시킴으로써 텍스트 분류, 생성, 번역 등과 같은 다양한 downstream task에서 좋은 성능을 내도록 하는 것이 목적이라고 할 수 있습니다. 이렇게 pre-train한 모델을 가져온 뒤 downstream task를 수행함으로써 파라미터들을 업데이트하는 과정을 fine-tuning이라고 합니다. end-to-end로 모델을 학습하는 task-specific 방식에 비해 여러 자연어처리 task의 성능을 비약적으로 끌어올렸고 이제는 PLM을 통한 전이 학습(transfer learning)이 대세로 자리잡았습니다.

 

 

 

Pre-trained Language Model

출처 https://towardsdatascience.com/pre-trained-language-models-simplified-b8ec80c62217

 

 

 

자연어처리 영역의 새로운 패러다임이라고 불리는 BERT(Bidirectional Encoder Representations from Transformers)의 등장 이후 더 좋은 성능의 언어 모델을 만들기 위해 수많은 연구들이 진행되어 왔는데요, ALBERT, BART, BigBird, DistilBert, ELECTRA, Longformer, GPT-, RoBERTa, T5, XLNet (알파벳 순) 등 트랜스포머 아키텍쳐 기반의 새로운 모델들이 계속해서 쏟아지고 있습니다. BERT 모델을 이해하기 위해서는 트랜스포머 신경망 아키텍쳐를 이해해야 하는데요, BERT는 트랜스포머 인코더 구조를 그대로 가져와 양방향으로 학습한 모델이기 때문입니다. 자세한 내용은 아래 두가지 논문을 참고해 주세요.

 

 

Pre-trained Language Model_BERT

출처 https://towardsdatascience.com/pre-trained-language-models-simplified-b8ec80c62217

 

 

Transformer 논문 Attention Is All You Need

BERT 논문 BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding

 

 

 

 

PLM이 왜 필요할까?

기존의 언어 모델에 비해 PLM이 가지는 장점은 매우 큽니다. 적은 양의 task-specific한 데이터를 가지고 학습시킨 모델은 그 범위 이상의 언어적인 지식과 문제 해결 능력을 가지기 어렵지만, PLM은 이미 많은 양의 텍스트를 소화한 상태이기 때문에 이러한 언어적 지식의 확장이 더 효과적으로 일어날 수밖에 없습니다. 마치 국어영역 지문을 읽을 때 책을 많이 읽어온 학생이 지문을 훨씬 더 빨리, 그리고 심도 있게 이해하는 것과 비슷한 원리입니다.

 

 

출처 https://towardsdatascience.com/pre-trained-language-models-simplified-b8ec80c62217

 

 

 

기존의 언어 모델이 문맥에 의존하지 않는 모델이었다면, PLM은 문맥을 이해할 수 있는 모델이라고 할 수 있습니다. 같은 단어라 하더라도 앞 뒤 맥락에 따라 해당 단어의 의미를 서로 다르게 이해할 수 있게 된 것이죠. 동음이의어를 문맥에 따라 다르게 이해할 뿐만 아니라 거의 비슷한 형태의 문장들 간 미묘한 의미 차이까지도 파악할 줄 아는 똘똘한 모델입니다. 이쯤 되면 정말 ‘사람의 언어를 이해하는 모델’이라는 생각이 들지 않나요?

 

또한 잘 만들어진 PLM은 적은 데이터셋으로도 fine-tuning을 통해 좋은 성능을 낼 수 있다는 장점도 있습니다.

 

 

이러한 PLM도 다시 두 가지로 나눠볼 수 있습니다.

 

General-domain PLM과 Domain-specific PLM 인데요, 전자는 일반적인 도메인의 텍스트로 학습시킨 모델이고 후자는 특정 도메인에서 좀 더 좋은 성능을 내는 것을 목적으로 학습시킨 모델을 말합니다. 특히 Domain-specific PLM은 특정 분야의 데이터를 모델에 추가적으로 학습시킴으로써 해당 분야에서의 문제를 해결하는 데 더 좋은 성능을 낼 수 있다는 장점이 있습니다. Domain-specific PLM에도 두 가지 방식이 존재합니다. 하나는 일반적인 도메인의 텍스트에 도메인 친화적인 텍스트를 추가해서 학습시키는 방법, 다른 하나는 도메인 친화적인 텍스트만을 사용하여 PLM을 만드는 방법입니다.

 

화해팀은 일반적인 도메인 데이터와 화해 내부 데이터를 함께 사용하는 방법을 통해 Beauty Domain-specific PLM을 개발하였는데요, 대한민국 뷰티 도메인 최초의 PLM이라고 자신 있게 말씀드릴 수 있을 것 같네요. 🙂

 

그럼 이제 Hwahae PLM 개발 과정과 그렇게 만들어진 PLM이 내부의 어떤 문제들을 해결하고 있는지 이야기 해보겠습니다.

 

 

 

 


 

Hwahae PLM 개발 과정

 

모델 개발 과정은 다음과 같습니다.

 

 

STEP 1. Corpus 수집 및 전처리

한국어 위키백과 데이터를 포함한 퍼블릭 데이터, 그리고 화해에 등록된 리뷰 및 제품 정보 데이터를 모두 모아 약 60GB에 해당하는 학습 말뭉치(corpus)를 생성하였습니다.

 

좋은 성능의 PLM을 만들기 위해서는 좋은 vocab이 필요하고, 좋은 vocab을 만들기 위해서는 전처리 과정에 공을 들여야 하는데요. 여러가지 전처리 기준을 정함에 있어서 무엇보다도 해당 도메인 데이터의 특성을 잘 고려하는 것이 가장 중요하다고 할 수 있습니다. 화해팀의 경우 문장 분류, 검색, 추천 등 다양한 영역에서 PLM을 활용하고자 하는 목적이 있었기 때문에 세부적인 전처리 기준을 정하기에 앞서 아래와 같은 정성적인 기준을 정했습니다.

 

 

Pre-trained Language Model_화해기준

 

 

숫자, 문장 부호, 특수문자, 이모지, 외국어 항목의 경우 데이터 소스마다 서로 다른 전처리 기준을 적용했고, 기타 항목의 경우 정규표현식을 통해 해당 항목의 대표값으로 치환하는 과정을 거침으로써 최소한의 정보만 손실되도록 하였습니다.

 

 

 

STEP 2. Tokenizer와 Vocab

Tokenizer로는 transformers 라이브러리와의 호환 등을 고려하여 Huggingface의 Wordpiece tokenizer를 선택하였습니다. 특히 Huggingface의 Tokenizer 라이브러리는 Rust 언어로 구현되어 있어 큰 사이즈의 corpus도 빠르게 처리할 수 있다고 하네요.

 

from tokenizers import BertWordPieceTokenizer

## cased model
tokenizer = BertWordPieceTokenizer(
    vocab_file=None,
    clean_text=True,
    handle_chinese_chars=True,
    strip_accents=False, # Must be False if cased model
    lowercase=False,
    wordpieces_prefix="##"
)

tokenizer.train(
        files=paths,
        limit_alphabet=3000, # [UNK] 최대한 줄이자
        vocab_size=args.vocab_size,
        min_frequency=50
        show_progress=True,
        special_tokens=['[PAD]', '[UNK]', '[CLS]', '[SEP]', '[MASK]', '[PHONE]', '[EMAIL]', '[PERSON]','{laughing}', '[BOS]', '[EOS]', '[UNK0]', '[UNK1]', '[UNK2]', '[UNK3]', '[UNK4]', '[UNK5]', '[UNK6]', '[UNK7]', '[UNK8]', '[UNK9]'])

 

적게는 35,000개에서부터 많게는 95,000개까지 다양한 vocab size를 가지고 테스트를 진행하였습니다. 퍼블릭 데이터와 도메인 데이터의 비율, 어느 정도 범위까지의 문자열을 보존하고 싶은지에 따라 적절한 범위를 선택하여 실험해 보시는 것을 추천드립니다.

 

위와 같이 생성된 vocab의 퀄리티는 다음 3가지 방법을 통해 간단히 평가하였습니다.

  • 랜덤 샘플링한 화해 리뷰 데이터를 토크나이징 하였을 때 생성되는 [UNK] token의 수(비율)
  • 내부적으로 관리되는 약 160개 정도의 special tokens를 얼마나 잘 보존하는지 보존 비율
  • 간단한 biLSTM 구조의 모델을 통한 리뷰 관련 task에서의 성능이 얼마나 달라지는지 확인
    • 화해 리뷰 데이터의 좋은점/아쉬운점 분류 벤치마크 테스트
    • NSMC(Naver Sentiment Movie Corpus) 감성 분류 벤치마크 테스트

 

model = tf.keras.Sequential([
    tf.keras.layers.Embedding(tokenizer.vocab_size, 64),
    tf.keras.layers.Bidirectional(tf.keras.layers.LSTM(64)),
    tf.keras.layers.Dropout(0.2),
    tf.keras.layers.Dense(64, activation='relu'),
    tf.keras.layers.Dropout(0.2),
    tf.keras.layers.Dense(1, activation='sigmoid')])

Vocab 결과 비교를 위한 LSTM 모델 구조

 

 

 

위 평가 지표들을 종합적으로 고려하여 최종 vocab size로 75,000개를 선정하였습니다. 75,000개라는 수치가 조금 많아 보일 수도 있지만 뷰티 도메인에 특화된 단어들이 vocab 목록에 포함될 수 있도록 하기 위해 일반적인 사이즈보다 조금 큰 사이즈를 선택하였고 이는 vocab 퀄리티 평가에서도 좋은 결과를 보였습니다.

 

 

최종적으로 선택한 vocab size를 반영하여 토크나이징한 예시를 보여드리겠습니다.

 

Pre-trained Language Model_토크나이징예시1

Pre-trained Language Model_토크나이징예시2Pre-trained Language Model_토크나이징예시3

 

‘좁쌀’, ‘여드름’, ‘쿨링’과 같은 뷰티 도메인에서 자주 등장하는 단어가 잘 토크나이징 되는 것을 확인할 수 있습니다.

 

 

 

KoELECTRA나 KcBERT tokenizer에 비해 확실히 뷰티 도메인에서 자주 등장하는 단어가 반영된 것을 볼 수 있습니다.

 

좋은 vocab을 만드는 것이 곧 토크나이징 퀄리티와 직결되고, 이는 모델이 맥락 지식을 잘 학습하여 downstream task에서 좋은 성능을 내는 데에까지 영향을 미치기 때문에 모델 학습에 들어가기에 앞서 vocab을 잘 살펴볼 필요가 있습니다.

 

 

 

STEP 3. 모델 학습 (Pre-train)

Transformer 네트워크 구조를 사용하는 다양한 언어모델 중 저희가 선택한 모델은 ELECTRA-Base 모델입니다. ELECTRA 모델은 스탠포드대와 Google Brain의 공동 연구를 통해 2020년에 공개된 모델인데요, BERT보다 가벼우면서 15%의 [MASK] token만을 학습하는 BERT와 달리 전체 token에 대해서 학습하는 구조를 채택함으로써 BERT와 비슷한 성능을 보인다는 점에서 학습 효율이 높다는 장점이 있습니다. 자세한 내용은 ELECTRA 논문을 참고해 주세요.

 

Pre-train은 공식 레포지토리 코드를 참고하였으며 데이터 수집 및 적재, 전처리, 학습, 벤치마크 테스트 등 모든 작업은 Google Cloud Platform에서 진행하였습니다.

 

 

 

Pretrain을 위해서는 STEP 1에서 전처리 완료한 데이터셋을 TFRecord 형태로 컨버팅해 주어야 하는데요, TFRecord는 텐서플로우에서 제공하는 직렬화된 프로토콜 버퍼 형태의 파일 포맷으로 대용량 데이터의 I/O 및 처리에 빠르다는 장점을 가지고 있습니다. 공식 레포지토리에서 제공하는 build_pretraining_dataset.py 코드를 사용하여 텍스트 데이터를 모델이 받을 수 있는 구조의 TFRecord 파일로 컨버팅할 수 있습니다.

 

컨버팅에 앞서서 원하는 tokenizer의 종류에 따라 토크나이저 지정 코드를 수정해 주어야 합니다. 미리 생성해 둔 vocab 파일이 존재한다면 해당 경로를 지정해 주면 됩니다. 이번 개발 과정에서는 Huggingface tokenizer를 통해 vocab을 생성하고 special token을 지정해주었기 때문에 아래 부분을 해당 tokenizer로 변경해주었습니다. TF Tokenizer와 인터페이스가 같기 때문에 Huggingface tokenizer를 지정해 주어도 잘 동작하게 됩니다.

 

 

class ExampleWriter(object):
  """Writes pre-training examples to disk."""

  def __init__(self, job_id, vocab_file, output_dir, max_seq_length,
               num_jobs, blanks_separate_docs, do_lower_case,
               num_out_files=1000, strip_accents=True):
    self._blanks_separate_docs = blanks_separate_docs
    # 논문에서의 tokenizer 설정
    # tokenizer = tokenization.FullTokenizer(
    #    vocab_file=vocab_file,
    #    do_lower_case=do_lower_case,
    #    strip_accents=strip_accents)
		
    # HuggingFace tokenizer로 교체
    tokenizer = ElectraTokenizer.from_pretrained("hwahae/Hhelectra-base")
		
    self._example_builder = ExampleBuilder(tokenizer, max_seq_length)
    self._writers = []
    for i in range(num_out_files):
      if i % num_jobs == job_id:
        output_fname = os.path.join(
            output_dir, "pretrain_data.tfrecord-{:}-of-{:}".format(
                i, num_out_files))
        self._writers.append(tf.io.TFRecordWriter(output_fname))
    self.n_written = 0

 

 

TFRecord 변환까지 완료한 후 TPU를 세팅합니다.

 

공식 코드에서 TPU를 지원하고 있기 때문에 ELECTRA 모델을 pretrain할 경우 GPU보다 TPU를 사용하는 것이 훨씬 효율적이라고 하네요. VM을 새로 띄우거나 AI Platform Notebooks 인스턴스에서 작업을 해도 상관 없지만 해당 인스턴스와 TPU의 이름을 동일하게 지정해 주어야 합니다. TPU 세팅에 관한 자세한 내용은 monologg님의 블로그를 참고하시면 됩니다.

 

모델 학습 시 어려움을 겪었던 부분이 학습 파라미터 세팅이었는데요, 제대로 된 학습 결과를 확인하기까지 몇 차례의 시행착오를 거쳤습니다. ELECTRA 논문, 공식 레포지토리, Huggingface의 ELECTRA 모델 관련 문서, KoELECTRA 프로젝트 문서 등 여러 자료들을 참고하여 학습을 진행하였습니다.

 

모델을 학습시키기 위해 설정하였던 주요 학습 파라미터는 아래와 같습니다.

 

keep_checkpoint_max 0
embedding_size 768 # Discriminator embedding size
generator_layers 12 # Generator size
num_train_steps 2000000
train_batch_size 256 
max_seq_length 128 
learning_rate 0.0002 
generator_hidden_size 0.33333 # Generator hidden size ratio

 

 

화해에 등록된 리뷰 특성을 반영하기 위하여 max_seq_length를 128로 줄이는 것 이외에 기본적인 파라미터들은 논문에서 제시된 base 값들을 그대로 사용하였습니다.

 

generator_hidden_size가 정수가 아닌 것은 Discriminator의 embedding_size와 generator_hidden_size의 곱이 256의 값을 가져야 하기 때문입니다 (768*0.33333 = 256).

 

keep_checkpoint_max는 최신 checkpoint 저장 개수를 지정하는 값으로 디폴트는 5로 설정되어 있어 가장 최근 5개의 checkpoint만 저장됩니다. (0으로 설정하면 모든 checkpoint를 저장합니다.) 파라미터 설정을 완료한 후 TPU를 이용하여 총 200만 step을 학습하도록 했고, 약 10일의 학습 시간이 소요되었습니다.

 

 

Tensorboard

 

 

 

학습이 완료된 이후에는 Huggingface Transformers를 사용하기 위해서 Pytorch bin파일로 포팅을 해주어야 합니다. Huggingface에서 제공하는 포팅 코드를 이용하였고 아래와 같이 설정값을 지정해 주었습니다.

 

# base-discriminator
{
  "architectures": ["ElectraForPreTraining"],
  "attention_probs_dropout_prob": 0.1,
  "embedding_size": 768,
  "hidden_act": "gelu",
  "hidden_dropout_prob": 0.1,
  "hidden_size": 768,
  "initializer_range": 0.02,
  "intermediate_size": 3072,
  "layer_norm_eps": 1e-12,
  "max_position_embeddings": 128,
  "model_type": "electra",
  "num_attention_heads": 12,
  "num_hidden_layers": 12,
  "pad_token_id": 0,
  "type_vocab_size": 2,
  "vocab_size": 75000
}

# base-generator
{
  "architectures": [
    "ElectraForMaskedLM"
  ],
  "attention_probs_dropout_prob": 0.1,
  "hidden_size": 256,
  "intermediate_size": 1024,
  "num_attention_heads": 4,
  "num_hidden_layers": 144,
  "embedding_size": 768,
  "hidden_act": "gelu",
  "hidden_dropout_prob": 0.1,
  "initializer_range": 0.02,
  "layer_norm_eps": 1e-12,
  "max_position_embeddings": 128,
  "model_type": "electra",
  "type_vocab_size": 2,
  "vocab_size": 75000,
  "pad_token_id": 0
}

 

Discriminator의 num_attention_heads 값 세팅 시 주의해야 하는데, 어떤 값을 주어도 포팅이 되는 것처럼 보이기 때문에 학습 시 설정했던 값을 잘 전달해 주어야 합니다. Base 모델 기준으로 설정값을 지정해주지 않는 경우 12로 설정됩니다. 성공적으로 포팅이 완료되면 저장 경로에 pytorch_model.bin 파일이 생성되고 Huggingface 패키지로 불러올 수 있게 됩니다.

 

 

 

 


 

모델 평가

 

학습을 완료한 PLM으로 몇 가지 기본적인 NLP Benchmark 테스트를 진행했고, 초기 개발 의도대로 화해 리뷰와 관련된 task들에서 어느 정도의 성능을 보이는지 확인하였습니다. 여기서는 화해 리뷰 관련 Benchmark에 대한 내용만 간단히 다루고자 합니다.

  • 화해 리뷰는 좋은 점, 아쉬운 점으로 구분이 되어 있는데, 주어진 리뷰가 어느 항목으로 분류되는지를 추론하는 task에서는 96.03%라는 높은 정확도(Acc)를 기록했습니다. 이는 기존의 general PLM을 fine-tuning 했을 때에 비해 약 3-4% 정도 높은 수치입니다.
  • 각각의 리뷰가 어떤 화장품 카테고리에 포함된 것인지를 분류하는 task에서는 Micro-F1 0.88을 기록하여 만족스러운 성능을 보여주었는데요, 이 역시 general PLM 대비 ****정도의 약 7% 정도 높은 향상을 보임으로써 Hwahae PLM이 화해 내/외부 서비스에 충분히 적용할 만 하다는 판단을 내릴 수 있었습니다.

 

 

제품 리뷰 카테고리 분류 task metrics

 

 

 

 

서비스 적용

 

그럼 이제 실제 화해의 내/외부 서비스에 모델을 적용한 사례에 대해 공유해 보겠습니다.

 

 

사용자 리뷰 검수모델

화해는 신뢰도 있는 리뷰, 클린 리뷰를 표방하는 앱입니다. 화해는 매일 등록되는 리뷰들에 대해 이 리뷰들이 정말 제품을 충분히 사용해 보고 작성한 리뷰인지, 다른 고객들에게 불편감을 줄 수 있는 내용이 포함되어 있지는 않은지 등에 대해 엄격하게 검수하는 프로세스를 진행하고 있습니다. 화해 앱 이용자가 많아짐에 따라 등록되는 리뷰도 증가하는 추세인데요, 담당자가 일일이 검수하기 어려운 양이기 때문에 모델이 1차로 분류한 결과를 통해 검수해야 하는 리뷰의 풀을 줄이게 됩니다.

 

몇가지 검수 항목들이 있지만, 여기에서는 미사용 리뷰 검수 관련 사례를 간단히 보여드리겠습니다. 실제로 제품을 사용해 보지 않은 상태에서 사용한 것처럼 리뷰를 작성한 경우, 다른 이용자가 작성한 리뷰를 보기 위해서 제품 미사용 상태에서 리뷰를 작성하는 경우 등이 검수 대상에 포함됩니다.

 

검수 담당자는 아래의 화면과 같은 내용을 어드민 페이지에서 확인하게 됩니다. 각각의 리뷰 문장이 미사용 리뷰일 확률을 sorting해서 볼 수 있고 높은 확률로 미사용 리뷰로 판단된 리뷰에 한해서만 전수검사 없이 빠르게 블라인드 처리를 할 수 있게 됩니다. Hwahae PLM 적용을 통해 모델 정확도 개선을 확인할 수 있었고, 실제로 담당자의 검수 업무 시간이 크게 줄어드는 효과를 확인할 수 있었습니다.

 

 

 

 

리뷰에서 제품 속성 추출하기

화해의 리뷰에는 제품의 속성에 관해 많은 내용들이 포함되어 있습니다. 이를 잘 추출해 낼 수 있다면, 리뷰의 내용을 요약하여 사용자에게 필요한 정보만 선택적으로 잘 전달할 수 있고 제품의 속성 또한 쉽게 파악할 수 있습니다. 아래의 차트에는 각질을 제거하는데 주로 사용되는 성분인 바하(BHA)가 포함되어 있는 앰플 제품과 그렇지 않은 앰플 제품의 리뷰에서 몇 가지 제품 사용 속성을 추출하여 등록된 리뷰 수 대비 등장 속성의 비율을 기록한 결과입니다.

 

 

 

 

 

차트를 보면 바하가 포함되어 있는 제품에는 각질이 제거된다는 의견과 매끄러워진다는 의견이 다른 제품에 비해 월등하게 높은 비율로 나타난 것을 볼 수 있습니다. 이렇듯 PLM을 통해 제품에 대한 주요 속성을 파악할 수 있게 되었고 이를 기반으로 추천, 검색 등 다양한 영역에서 활용할 수 있는 새로운 제품 메타데이터를 확보할 수 있었습니다. 관련해서 자세한 내용은 다음 포스트에서 다루도록 하겠습니다.

 

 

 

 

정리하며

 

지금까지 뷰티 도메인에 친화적인 PLM 개발 과정과 몇가지 서비스 적용 사례에 대해 공유드렸습니다. 화해팀은 앞으로도 추천시스템 개발, 검색 개선 등 자연어처리가 활용될 수 있는 여러 영역에서 Hwahae PLM을 적용하여 서비스 경험을 개선하고자 하는 계획을 가지고 있습니다. 다른 아키텍쳐의 다양한 PLM에 대해서도 학습을 진행하고 있으며, 유연한 학습 구조를 위한 파이프라인 설계도 진행 중이니 관련 내용은 이후 포스트에서 공유해 보도록 하겠습니다. 긴 글 읽어주셔서 감사합니다.

 

 

 

 

레퍼런스

모두의 말뭉치

https://monologg.kr/2020/05/02/koelectra-part1/

https://github.com/monologg/KoELECTRA

https://huggingface.co/monologg/koelectra-base-discriminator

https://github.com/google-research/electra

https://medium.com/daangn/딥러닝으로-동네생활-게시글-필터링하기-263cfe4bc58d

https://deview.kr/data/deview/2019/presentation/[111]+엄_청+큰+언어+모델+공장+가동기.pdf

https://jalammar.github.io/

https://towardsdatascience.com/pre-trained-language-models-simplified-b8ec80c62217

https://www.microsoft.com/en-us/research/blog/domain-specific-language-model-pretraining-for-biomedical-natural-language-processing/?fbclid=IwAR0EEbDjofs5Kp5t1wAQompBr5heDvub13kD8eYAt3mmV4GSvVTPieF9uGo

 

 

성민님의 다른 글이 궁금하다면 딥러닝으로 리뷰에서 제품 속성 정보 추출하기 편도 확인해보세요!

 

 

 


 

 

 

 

 

채용정보 확인하기

 

 

 

15
by nc nd