Practice makes perfect!

앱 아키텍처

na0dev — Mon, 22 May 2023 20:47:39 +0900

앱은 사용자 중심의 다양한 워크플로우 및 작업에 맞게 조정될 수 있어야 한다.

또한 휴대 기기는 리소스가 제한되어 있으므로, os가 새로운 앱을 위한 공간을 확보하도록 언제든지 일부 앱을 종료해야 할 수 있다. 이런 환경 조건을 고려해볼 때 앱 구성요소는 개별적이고 비순차적으로 실행될 수 있으며, 운영체제나 사용자가 언제든지 앱 구성요소를 제거할 수 있다.

이런 이벤트는 직접 제어할 수 없기 때문에 앱 구성요소에 애플리케이션 데이터나 상태를 저장하면 안되고, 앱 구성요소가 서로 종속되면 안된다.

일반 아키텍처 원칙

앱 아키텍처는 앱의 부분과 그 각 부분에 필요한 기능 간의 경계를 정의한다.

관심사 분리

Activity 또는 Fragment에 모든 코드를 작성하는 실수는 흔히 일어난다.

이러한 UI 기반의 클래스는 UI 및 OS 상호작용을 처리하는 로직만 포함해야한다. 또한 클래스를 최대한 가볍게 유지해 구성요소 수명 주기와 관련된 많은 문제를 피할 수 있다. os는 사용자 상호작용을 기반으로 또는 메모리 부족과 같은 시스템 조건으로 언제든지 클래스를 제거할 수 있다. 때문에 클래스에 대한 의존성을 최소화하는 것이 좋다.

데이터 모델에서 UI 도출하기

데이터 모델은 앱의 데이터를 나타내며, 앱의 UI 요소 및 기타 구성요소로부터 독립되어 있다. 즉, 이들은 UI 및 앱 구성요소 수명 주기와는 관련이 없다. 하지만 os가 메모리에서 앱의 프로세스를 삭제하기로 결정하면 데이터 모델도 삭제된다. 이에 android os에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않고, 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동하도록 지속 모델을 사용하는 것이 권장된다.

단일 소스 저장소

앱에서 새로운 데이터 유형을 정의할 때는 데이터 유형에 단일 소스 저장소 (SSOT)를 할당해야 한다. SSOT는 데이터의 소유자이며, SSOT만 데이터를 수정하거나 변경할 수 있다. SSOT는 이를 위해 불변 유형을 사용해 데이터를 노출하며, 다른 유형이 호출할 수 있는 이벤트를 수신하거나 함수를 노출하여 데이터를 수정한다.

이 패턴으로

- 특정 유형 데이터의 모든 변경사항을 한곳으로 일원화하고

- 다른 유형이 조작할 수 없도록 데이터를 보호하며

- 데이터 변경 사항을 더 쉽게 추적할 수 있도록 한다.

오프라인 중심 애플리케이션의 데이터 정보 소스는 주로 데이터 베이스이며, ViewModel이거나 UI가 정보 소스인 경우도 있다.

ㅁ

Layout

na0dev — Sat, 13 May 2023 22:07:02 +0900

안드로이드는 화면을 구성할 때 배치되는 뷰들이 어디에 배치되는지 좌표를 직접 설정하지 않음.

-> 안드로이드 디바이스 기기마다 액정 사이즈가 다른데, 똑같은 위치에 배치하면 view가 잘릴 수 있기 때문

안드로이드는 좌표가 아닌 '가운데 배치' 등 배치되는 모양을 결정한다.

개발자가 배치되는 모양을 결정하고 뷰들을 배치하면 안드로이드 OS가 단말기에 적합한 좌표를 계산하고 직접 뷰들을 배치하게 된다.

Parent 와 Child

안드로이드는 화면을 구성하기 위해 layout을 먼저 배치하고 그 위에 다른 View들을 배치한다.
이때 layout을 Parent, 배치되는 view들을 Child라고 부른다.
모든 View 들은 단 하나의 Parent를 가질 수 있으며, 모든 layout은 다수의 Child를 가질 수 있다.

LinearLayout

방향성을 가지고 view를 배치하는 layout
가로 혹은 세로 방향으로 배치 가능하다.
한 칸에 하나의 view만 배치 가능하다.
안드로이드에서 가장 많이 사용하는 layout으로 여러 LinearLayout을 조합해 다양한 모양을 만들 수 있다.
속성
- orientation : 배치되는 모양 결정
- weight : LinearLayout 안에 배치되는 View 들의 비율 설정
  - 뷰를 먼저 배치하고 남은 공간을 각 뷰들이 얼마만큼 나눠서 가질 것인가를 결정하는 것
  - 처음 생성된 뷰의 사이즈가 다르면 남은 공간 1:1로 나눠가져도 최종 사이즈가 다른 것에 주의
  - 각 뷰들에 설정하는 것 (layout_weight)

[코.활.안] 안드로이드 개요 및 개발 환경

na0dev — Sat, 15 Apr 2023 15:15:00 +0900

2019년 3분기 자료에 따르면 전 세계에서 안드로이드 OS를 탑재한 스마트폰이 약 85%, 아이폰이 11% 정도를 차지하고 있다. 2008년 9월에 최초의 안드로이드 1.0 버전이 공개되었고, 모든 소스 코드를 공개하는 오픈소스로 선언되었다.

주요 기능

- 모바일 기기를 위한 운영체제

- 안드로이드 SDK (Software Development Kit)는 Java를 기반으로 안드로이드 애플리케이션을 개발할 수 있는 API를 제공함

- 모바일용 데이터베이스인 SQLite 제공

- 모바일 기기에 내장된 각종 하드웨어(블루투스, 카메라, 와이파이..) 지원

특징

- 안드로이드는 여러 기업이 함께 개발하는 형식을 띠고 있지만, 대부분은 구글이 주도적으로 개발함

- 핵심 커널은 리눅스로 구성되어 있으며, 리눅스 커널에서 모바일용으로 적합한 내용을 추출하여 필요한 기능을 추가한 것

- 개발 언어로 Java 또는 Kotlin을 사용하며 이에 최적화된 통합 개발 도구인 Android Studio를 사용해 고효율의 생상성을 보임

- 높은 수준의 애플리케이션을 제작하기 위한 NDK (Native Development Kit)도 제공하여 c, c++ 기반으로 개발이 가능함 (시스템 응용 프로그램 개발 시 사용)

- 안드로이드 SDK는 많은 라이브러리를 포함하고 있어 개발을 용이하게 할 수 있으며, 특히 SQLite 등을 지원하며 별도의 외부 라이브러리를 사용하지 않아도 됨

안드로이드 구조

1. Applications

- 안드로이드 스마트폰에서 사용가능한 일반적인 응용 프로그램

- 웹브라우저, 구글 맵, 연락처, 게임 등 사용자 입장에서 가장 많이 사용하는 앱

- Java 또는 Kotlin으로 작성됨

2. Application Framework

- 안드로이드 API가 존재하는 곳

- 애플리케이션은 API를 통해 안드로이드의 커널에 접근가능

3. Android Runtime

- JVM을 사용하지 않고 Java 코어 라이브러리와 Dalvik VM 또는 ART Runtime으로 구성됨

4. Libraries

- 안드로이드에 사용되는 여러 시스템 라이브러리는 시스템 접근 때문에 C로 작성되어 있어 성능이 뛰어나고 세밀한 조작이 가능함

5. Linux Kernel

- 메모리 관리, 디바이스 드라이버, 보안 등 HW 운영과 관련된 low level의 관리 기능이 들어있음

- 안드로이드 커널로 리눅스를 채택한 이유는 오픈소스라는 장점과 함께 카메라, 터치스크린 등 많은 스마트폰 장치를 지원하기 때문

안드로이드 개발 환경

안드로이드 개발 환경의 구성

1. 안드로이드 개발에 기본이 되는 Java 또는 Kotlin을 사용하기 위해 JDK (Java Development Kit)가 필요하다.

Android Studio 2.2 부터는 Open JDK가 내장되어 있어 별도 설치가 필요하지는 않다. Kotlin 언어를 사용할 때도 JDK가 설치되어 있어야 하며, 설치 후에는 둘 중 어떤 언어를 사용해도 된다.

2. 안드로이드 SDK는 별도의 폴더에 존재해야 하는데, 모든 개발 API가 들어있지는 않기 때문에 필요한 버전의 API를 추가로 다운받는 과정도 필요하다.

3. 실제 개발자가 코딩하기 위한 IDE가 핵심에 존재한다.

4. Android Studio와 안드로이드 SDK를 연결하기 위한 플러그인 ADT(Android Development Tools)가 내부적으로 필요하다.

5. 이 때 안드로이드 SDK가 설정된 경로가 지정되어 있어야 한다.

6. 결과를 화면에 테스트로 출력하기 위한 가상 안드로이드 장치인 AVD를 별도로 만들어야 한다

[백준] 2606 바이러스 - python

na0dev — Fri, 7 Jan 2022 21:03:19 +0900

- 문제 링크 : https://www.acmicpc.net/problem/2606

- 접근 방법 : 1번 컴퓨터에 연결된 모든 컴퓨터를 찾으면 되는 문제이므로 dfs로 접근.

( 현재 나의 위치에서 연결된 브랜치를 모두 방문하고자 할 때 )

n = int(input())
con = int(input())

graph = [[] for _ in range(n+1)]
visited = [0]*(n+1)

for _ in range(con):
    a, b = map(int, input().split())
    graph[a].append(b)
    graph[b].append(a)

cnt = -1

def dfs(a):
    visited[a] = 1
    global cnt
    cnt += 1
    
    for b in graph[a]:
        if visited[b] == 0:
            dfs(b)
    
dfs(1)
print(cnt)

Week 15 자연어처리 데이터 기초

na0dev — Mon, 8 Nov 2021 13:53:35 +0900

1. 인공지능 모델 개발을 위한 데이터

데이터의 종류

말뭉치 류 : 실제 텍스트 기반의 데이터 ex) 대화문, 기사, 댓글, 주석 말뭉치, 요약 말뭉치 등
사전/데이터베이스 류 : 텍스트 분석 시 참조로 사용되는 자원 ex) 온톨로지, 워드넷, 시소러스 등

언어 모델 평가를 위한 종합적인 벤치마크 등장

GLUE (General Language Understanding Evaluation) : 자연어 이해 (2018)
Super GLUE (Difficult GLUE) : 고난도 자연어 이해 (2019)
KILT (Knowledge-Intensive Language Tasks) : 지식기반 자연어 이해(2020)
GEM (Natural Language Generation,Evaluation, Metrics) : 자연어 생성(2021)

2. 데이터 관련 용어 정리

text : 주석, 번역, 서문 및 부록 따위에 대한 본문이나 원문
corpus : 어떤 기준으로든 한 덩어리로 볼 수 있는 말의 뭉치(한 저작자의 저작 전부, 특정 분야 저작 전체)
data : 컴퓨터가 처리할 수 있는 문자, 숫자, 소리, 그림 따위의 형태로 된 정보

텍스트 데이터의 기본 단위

영어 말뭉치의 계량 단위 : 단어
한국어 말뭉치의 계량 단위 : 어절
한국어의 "단어"는 9품사로 분석된다 (명사, 수사, 대명사, 동사, 형용사, 관형사, 부사, 조사, 감탄사)
이 중 "조사"는 체언(명사, 수사, 대명사)과 붙어서 사용되기 때문에 띄어쓰기 단위와 단어의 단위가 일치하지 않다. 또한 "어미"는 하나의 품사로 인정되지 않으며, 형태 단위이므로 독립된 단어가 아니다.
동사와 형용사는 형태를 바꿔 활용 가능하다

type & token

토큰화 (tokenization) → 표제어 추출 (lemmatization) / 품사 주석 (POS tagging)
토큰 : 언어를 다루는 가장 작은 기본 단위 (단어, 형태소, 서브워드를 기준으로 삼을 수 있다)
타입 : 토큰의 대표 형태
예시
- "이 사람은 내가 알던 사람이 아니다"
- 토큰화 : 이 사람 은 내 가 알 더 ㄴ 사람 이 아니 다
- 표제어 추출 : 이, 사람, 나, 알다, 아니다
- 품사 주석 : 이/MM 사람/NNG+은/JX 나/NP+가/JKS 알/VV+더/EP+ㄴ/ETM 사람/NNG+이/JKS 아니/VA+다/EF
- x토큰 수 : 12개, 타입 수 : 10개 ('이'는 같은 타입이지만 다른 토큰)

N-gram

연속된 N개의 단위. 입력된 단위는 글자, 형태소, 단어, 어절 등으로 사용자가 지정할 수 있다.

표상 (representation)

대표로 삼을 만큼 상징적인 것.
자연어 처리 분야에서 표현으로 번역하기도 하나, 자연어를 컴퓨터가 이해할 수 있는 기법으로 표시한다는 차원에서 표상이 더 적합하다.
PLM, word2vec 등을 통해 단어나 텍스트를 수치화하는 것을 표상이라고 생각하면 된다.

3. 자연어처리 데이터 형식

HTML (Hypertext Markup Language)

우리가 보는 웹 페이지가 어떻게 구조화되어 있는지 브라우저로 하여금 알 수 있도록 하는 마크업 언어
보통 웹 페이지를 크롤링한 자료는 HTML 형식으로 되어있다
파싱 라이브러리 (beautifulsoup 등)을 통해 태그를 제외한 순수한 텍스트만 추출하여 사용한다.

XML (EXtensible Markup Language)

사람과 기계가 동시에 읽기 편한 구조.
다른 특수한 목적을 갖는 마크업 언어를 만드는데 사용하도록 권장되는 다목적 마크업 언어
HTML과의 차이 : HTML은 태그가 지정되어 있으나, XML은 사용자가 임의로 지정하여 사용할 수 있다.

JSON(JavaScript Object Notation) & JSONL(JavaScript Object Notation Lines)

"속성-값" 또는 "키-값" 쌍으로 이루어진 데이터 오브젝트를 전달하기 위해 인간이 읽을 수 있는 텍스트를 사용하는 개방형 표준 포맷
기본 자료형 : 수, 문자열, 불린, 배열, 객체, null
JSONL은 JSON을 한 라인으로 만든 것

CSV (comma-seperated values)

몇 가지 필드를 쉼표(,)로 구분한 텍스트 데이터 및 텍스트 파일

TSV(tab-seperated values)

몇 가지 필드를 탭(\t)로 구분한 텍스트 데이터 및 텍스트 파일

* csv와 tsv는 구분자(delimiter)의 차이

* 문자열 데이터 내에 쉼표(,)가 많이 포함돼있기 때문에, 혹시나 모를 오류를 방지하기 위해 tsv 사용을 권장한다.

Week 12 (8) Reducing Training Bias

na0dev — Thu, 21 Oct 2021 14:50:34 +0900

1. Definition of Bias

Bias의 종류

Bias in learning

학습할 때 과적합을 막거나 사전 지식을 주입하기 위해 특정 형태의 함수를 선호하는 것 (inductive bias)

A Biased World

현실 세계가 편향되어 있기 때문에 모델에 원치 않는 속성이 학습되는 것 (historical bias)
성별과 직업 간 관계 등 표면적인 상관관계 때문에 원치않는 속성이 학습되는 것 (co-occurrence bias)

Bias in Data Generation

입력과 출력을 정의한 방식 때문에 생기는 편향 (specification bias)
데이터를 샘플링한 방식 때문에 생기는 편향 (sampling bias)
어노테이터의 특성 때문에 생기는 편향 (annotator bias)

2. Bias in Open-domain Question Answering

Training bias in reader model

모델이 편향된 데이터만 학습하면 일반적인 데이터에 대해 제대로 학습하지 못함.

How to mitigate training bias?

1. Train negative examples

훈련할 때 잘못된 예시를 보여줘야 retriever이 negative한 내용들은 먼 곳에 배치할 수 있음

→ negative sample도 완전히 다른 negative와 비슷한 negative에 대한 차이 고려 필요

[좋은 negative sample 만들기]

- Corpus 내에서 랜덤하게 뽑기

- 좀 더 헷갈리는 negative 샘플들 뽑기 (어려운 샘플을 줘야 학습을 더 잘할 수 있음)

: 높은 BM25 / TF-IDF 매칭 스코어를 가지지만, 답을 포함하지 않는 샘플

: 같은 문서에서 나온 다른 passage/question 선택하기

2. Add no answer bias

입력 시퀀스의 길이가 N일시, 시퀀스의 길이 외 1개의 토큰이 더 있다고 생각하기

→ 훈련 모델의 마지막 레이어 weight에 훈련 가능한 bias를 하나 더 추가

→ softmax로 answer prediction을 최종적으로 수행할 때, start end 확률이 해당 bias 위치에 있는 경우가 가장 확률이 높으면 이는 "대답할 수 없다"고 취급

3. Annotation Bias from Datasets

1) What is annotation bias?

ODQA 학습 시 기존의 MRC 데이터셋 활용

→ ODAQ 세팅에는 적합하지 않은 bias가 데이터 제작(annotation) 단계에서 발생할 수 있음

: 질문을 하는 사람이 답을 알고있기 때문에, paraphrasing 되지않고 질문과 evidence 문단 사이의 많은 단어가 겹치는 bias가 발생 가능하다

: SQuAD는 500개의 문서만 활용하기 때문에 학습 데이터의 분포 자체가 이미 bias 되어있다

2) Effect of annotation bias

ODQA 세팅에는 적합하지 않은 bias가 데이터 제작 단계에서 발생할 수 있음

→ 데이터셋 별 성능 차이가 annotation bias로 인해 발생할 수 있음

(BM25 : Sparse embedding / DPR : dense embedding)

→ Annotation 단계에서 발생할 수 있는 bias를 인지하고, 이를 고려하여 데이터를 모아야 함

ex) Natural Questions : supporting evidence가 주어지지 않은, 실제 유저의 question들을 모아서 dataset 구성

Week 12 (7) Linking MRC and Retrieval

na0dev — Wed, 20 Oct 2021 11:48:13 +0900

1. Introduction to Open-domain Question Answering (ODQA)

MRC : 지문이 주어진 상황에서 질의응답
ODQA : 지문이 따로 주어지지 않고 방대한 World Knowledge에 기반해서 질의응답 -> 봐야하는 문서의 크기가 매우 큼 ex) 서치 엔진 : 연관 문서 뿐만 아니라 질의 답을 같이 제공함.

1) History of ODQA

Text retrieval conference (TREC) – QA Tracks (1999-2007) : 연관문서만 반환하는 information retrieval (IR)에서 더 나아가서, short answer with support 형태가 목표 (답을 갖고있는 문서를 같이 되돌려주는 형태)

1) Question processing + 2) Passage retrieval + 3) Answer processing

Question processing : 질문으로부터 키워드를 선택해 Answer type selection (답변의 형태를 설정) -> 어떻게하면 질문을 잘 이해할 수 있을지.
Passage retrieval : 기존의 IR 방법을 활용해 연관된 문서를 뽑고, 문서가 너무 길기 때문에 passage 단위로 자른 후 선별 (Named entity / Passage 내 question 단어의 개수 등과 같은 hand-crafted features 활용) -> 현재의 방법론과 유사.
Answer processing : Hand-crafted features와 heuristic을 활용해 classifier를 만들고, 주어진 question과 선별된 passage들 내에서 답을 선택 -> 최근에는 passage 선별 뿐만 아니라 passage 내에서 어떤 span이 답변이 되는지를 맞추는 것으로 진화됨.

2. Retriever-Reader Approach

1) Retriever-Reader 접근 방식

Retriever : 데이터베이스에서 관련있는 문서를 검색(search) 함
- 입력 : document corpus, query
- 출력 : 관련성 높은 문서
Reader : 검색된 문서에서 MRC 모델을 이용해 질문에 해당하는 답을 찾아냄
- 입력 : retrieved 된 문서, query
- 출력 : 답변

2) 학습 단계

Retriever

TF-IDF, BM25 -> labeled된 데이터를 통한 학습은 없고, self supervised 형태로 학습
Dense : QA 데이터셋을 활용해 학습

Reader

SQuAD와 같은 MRC 데이터셋으로 학습
학습 데이터를 추가하기 위해 Distanct supervision 활용

3) Distant supervision

질문-답변만 있는 데이터셋 (CuratedTREC, WebQuestions, WikiMovies -> 답변이 어디에 존재하는 지는 모름)에서 MRC 학습 데이터 만들기. Supporting document가 필요함

위키피디아에서 Retriever를 이용해 관련성 높은 문서를 검색
너무 짧거나 긴 문서, 질문의 고유명사를 포함하지 않는 등 부적합한 문서 제거
answer가 exact match로 들어있지 않은 문서 제거
남은 문서 중에 질문과 (사용 단어 기준) 연관성이 가장 높은 단락을 supporting evidence로
사용함

4) Inference

Retriever가 질문과 가장 관련성 높은 n개 문서 출력
Reader는 n개 문서를 읽고 답변 예측
Reader가 예측한 답변 중 가장 score가 높은 것을 최종 답으로 사용함

3. Issues and Recent Approaches

1) Different granularities of text at indexing time

위키피디아에서 각 Passage의 단위를 문서, 단락, 또는 문장으로 정의할지 정해야 함.
- Article : 5.08 million
- Paragraph : 29.5 million
- Sentence : 75.9 million

Retriever 단계에서 몇개 (top-k)의 문서를 넘길지 정해야 함
Granularity에 따라 k 가 다를 수 밖에 없음
(e.g. article -> k=5, paragraph -> k=29, sentence -> k=78)

2) Single-passage training vs Multi-passage training

Single-passage : 현재 우리는 k 개의 passage들을 reader가 각각 확인하고 특정 answer span에 대한 예측 점수를 나타냄. 그리고 이 중 가장 높은 점수를 가진 answer span 을 고르도록 함
⇒ 이 경우 각 retrieved passages 들에 대한 직접적인 비교라고 볼 수 없음
⇒ 따로 reader 모델이 보는 게 아니라 전체를 한번에 보면 어떨까?
Multi-passage : retrieved passages 전체를 하나의 passage 로 취급하고, reader 모델이 그
안에서 answer span 하나를 찾도록 함
Cons : 문서가 너무 길어지므로 GPU에 더 많은 메모리를 할당해야함 & 처리해야하는 연산량이
많아짐

3) Importance of each passage

Retriever 모델에서 추출된 top-k passage들의 retrieval score를 reader 모델에 전달

-> 최종 answer를 고를 때 passage retrieval score까지 합했을 때 성능이 잘 나오는 경우도 연구가 되었음

Week 11 (6) Passage Retrieval – Scaling Up

na0dev — Mon, 18 Oct 2021 19:45:04 +0900

1. Passage Retrieval and Similarity Search

How to find the passage in real time? -> Similarity Search

1) MIPS (Maximum Inner Product Search)

주어진 질문(query) 벡터 q에 대해 Passage 벡터 v들 중 가장 질문과 관련된 벡터를 찾아야함

(관련성은 inner product 값으로 계산)

검색 : 인덱싱 된 벡터들 중 질문 벡터와 가장 내적값이 큰 상위 k개의 벡터를 찾는 과정
인덱싱 : 방대한 양의 passage 벡터들을 저장하는 방법
brute-force(exhaustive) search : 저장해둔 모든 Sparse/Dense 임베딩에 대해 일일히 내적값을 계산하여 가장 값이 큰 passage 추출
- 실제로 검색해야 할 데이터는 훨씬 방대하기 때문에 더이상 모든 문서 임베딩을 일일히 보면서 검색할 수 없음

2) Tradeoffs of similarity search

2. Approximating Similarity Search

1) Compression - Scalar Quantization(SQ)

compression : vector를 압축하여, 하나의 vector가 적은 용량을 차지 -> 압축량 ↑ => 정보 손실 ↑

ex) scalar quantization

2) Pruning - Inverted File (IVF)

pruning : Search space를 줄여 search 속도 개선(dataset의 subset만 방문)

쿼리에 가장 근접한 cluster만 보는 방식. 그 내의 포인트에 대해서는 exhaustive search로 모두 검색.ex) k-means clustering

+ FAISS : Library for efficient similarity search (indexing 쪽을 도움. endoing은 x)

Week 11 (5) Passage Retrieval - Dense Embedding

na0dev — Thu, 14 Oct 2021 17:56:26 +0900

1. Introduction to Dense Embedding

TF-IDF와 같은 sparse embedding은 벡터의 크기는 아주 크지만 그 안에 0이 아닌 숫자는 아주 적음

벡터의 차원 수가 매우 큰 것은 compressed format으로 극복 가능하지만, 유사성을 고려하지는 못함.

이 단점을 극복하기 위해 dense embedding이 많이 사용됨

1) Complementary to sparse representations by design

더 작은 차원의 고밀도 벡터 (length = 50-1000)
각 차원이 특정 term에 대응되지 않음. 차원이 모두 합쳐져 벡터 스페이스 상에서의 위치가 의미를 나타내도록 복합/부분적인 의미를 가짐
대부분의 요소가 non-zero값 (의미있는 값을 가짐)

2) Retrieval: Sparse vs Dense

sparse

각 dimesion마다 하나의 원소에 대응되고 많은 요소가 zero값을 가짐. 단어의 존재 유무 등을 알아맞히기에는 유용하나, 의미적으로 해석하기는 어려움
항상 dimension이 dense에 비해 크기 때문에 활용가능한 알고리즘에 한계가 있음
장점 : 중요한 term들이 정확히 일치해야 하는 경우 성능이 뛰어남 -> 현업에서 sparse와 dense를 동시에 쓰는 방식으로 retrieval을 구축하기도 함
단점 : 임베딩이 구축되고 나서는 추가적인 학습이 불가능함

dense

의미가 같더라도 다른 단어로 표현된 경우를 detect할 수 있는 방법론을 사용함
dense가 작아 활용가능한 알고리즘이 많음
최근 사전학습 모델의 등장으로 dense embedding을 배우는 것이 용이해졌음
장점
- 단어의 유사성 또는 맥락을 파악해야하는 경우 성능이 뛰어남
- 학습을 통해 임베딩을 만들며 추가적인 학습 또한 가능함

2. Training Dense Encoder

1) Dense Encoder

Dense Encoder로 BERT와 같은 Pre-trained language model (PLM)이 자주 사용됨
그 외 다양한 neural network 구조도 가능
MRC에서는 passage와 question을 둘다 input으로 넣어줬던 반면에, dense encoder에서는 각각을 독립적으로 넣어줌 (각각의 임베딩을 구하기 위해)
기존에는 passage 내에 답변이 어디있을 지 예측하기 위해 각 토큰별로 score를 내는 것이 목적이었다면, 이번에는 임베딩을 output 하는 것이 목적이기 때문에 [CLS] 토큰의 output 사용

Dense Encoder 구조

bert를 활용해 q와 p를 vector로 내보내고 유사도를 측정해 최종 유사 점수를 냄
학습 시에는 bert를 fine-tune해 실제 정답 p는 유사도 점수가 높게, 아닌 것은 유사 점수가 -로 갈 수 있도록 학습함

2) Dense Encoder 학습 목표와 학습 데이터

학습목표 : 연관된 question과 passage dense embedding 간의 거리를 좁히는 것 (= inner
product를 높이는 것 = higher similarity)
Challenge : 연관된 question / passage를 어떻게 찾을 것인가? -> 기존 MRC 데이터셋을 활용
관련없는 passage는 random하게 샘플링, 관련있는 passage는 question이 속해있던 passage를 활용해 한쪽은 거리를 좁히고, 한쪽은 거리를 멀리하는 방식으로 학습 진행함.

Negative Sampling

연관된 question과 passage 간의 dense embedding 거리를 좁히는 것 (higher similarity) ⇒ Positive
연관 되지 않은 question과 passage간의 embedding 거리는 멀어야 함 ⇒ Negative
Choosing negative examples
1. Corpus 내에서 랜덤하게 뽑기
2. 좀 더 헷갈리는 negative 샘플들 뽑기 (ex. 높은 TF-IDF 스코어를 가지지만 답을 포함하지 않는 샘플 <- 모델입장에서 구분하기 어려운 샘플)

Evaluation Metric for Dense Encoder

Top-k retrieval accuracy : retrieve 된 passage 중에 답을 포함하는 passage의 비율
extractive mrc에서는 passage내에 답이 없으면 절대 답을 낼 수 없음 -> upper bound

3. Passage Retrieval with Dense Encoder

From dense encoding to retrieval
Inference : Passage와 query를 각각 embedding한 후, query로부터 가까운 순서대로 passage의
순위를 매김

From retrieval to open-domain question answering
Retriever를 통해 찾아낸 Passage를 MRC (Machine Reading Comprehension) 모델에 넣어 답을
찾음.

How to make better dense encoding

학습 방법 개선 (e.g. DPR)
https://arxiv.org/abs/2004.04906

Dense Passage Retrieval for Open-Domain Question Answering

Open-domain question answering relies on efficient passage retrieval to select candidate contexts, where traditional sparse vector space models, such as TF-IDF or BM25, are the de facto method. In this work, we show that retrieval can be practically implem

arxiv.org

인코더 모델 개선 (BERT보다 큰, 정확한 Pretrained 모델)
데이터 개선 (더 많은 데이터, 전처리, 등)

* competition하면서 올바른 문서를 찾아오는 방법을 개선하는 것이 중요

Week 11 (4) Passage Retrieval - Sparse Embedding

na0dev — Thu, 14 Oct 2021 13:45:13 +0900

1. Introduction to Passage Retrieval

1) Passage Retrieval

질문(query)에 맞는 문서(passage)를 찾는 것
질문이 들어왔을 때 웹 또는 위키피디아 상에서 관련된 문서를 가져오는 시스템

2) Passage Retrieval with MRC

MRC에서 지문이 주어졌다고 가정 후 지문 내에서 답변을 찾는 형태의 모델을 만들 때, 지문을 주는 모델도 필요함.
Open-domain Question Answering: 대규모의 문서 중에서 질문에 대한 답을 찾기
- Passage Retrieval과 MRC를 이어서 2-Stage로 만들 수 있음
- Passage Retrieval은 질문, 질문에 대한 답, 질문과 관련된 내용을 포함할 것 같은 지문을 MRC 모델에 넘김.
- MRC는 그 지문을 보고 정확한 답변을 냄.

3) Overview of Passage Retrieval

Query와 Passage를 임베딩한 뒤 유사도로 랭킹을 매기고, 유사도가 가장 높은 Passage를 선택함
Passage는 미리 임베딩 해둬 효율성 도모
Similarity score를 재는 방법으로 nearest neighbor, inner product 등이 있음
모든 passage에 대해 유사도를 계산하고, 가장 높은 score를 갖는 순서대로 내보냄

2. Passage Embedding and Sparse Embedding

1) Passage Embedding

구절(Passage)을 벡터로 변환하는 것
Passage Embedding space : Passage Embedding의 벡터 공간.
벡터화된 Passage를 이용하여 Passage 간 유사도 등을 알고리즘으로 계산할 수 있음.

2) Sparse Embedding

Sparse (<-> Dense) : 0이 아닌 숫자가 적게 있음을 의미
Bag-of-Words(BoW)
- 문서를 embedding space로 매핑하기 위해 문서에 존재하는 단어들을 1이나 0으로 표현하여 긴 vector로 표현
- 특정 단어의 존재 유무를 표현하기 때문에 vector의 길이는 전체 vocab의 사이즈와 동일
BoW를 구성하는 방법 -> n-gram
- unigram(1-gram) : It was the best of times => It, was, the, best, of, times (벡터 크기 = vocab size)
- bigram (2-gram): It was the best of times => It was, was the, the best, best of, of times
- n이 늘어날수록 vocab 사이즈가 기하급수적으로 늘어남. 보통 bi, tri까지 사용
Term value 를 결정하는 방법 (가장 바닐라한 BoW)
- Term이 document에 등장하는지 (binary)
- Term이 몇번 등장하는지 (term frequency), 등. (e.g. TF-IDF)

3) Sparse Embedding 특징

Dimension of embedding vector = number of terms
- 등장하는 단어가 많아질수록 증가
- N-gram의 n이 커질수록 증가
Term overlap을 정확하게 잡아 내야 할 때 유용.
반면, 의미(semantic)가 비슷하지만 다른 단어인 경우 비교가 불가 -> dense embedding 활용

3. TF-IDF

BoW는 단순하게 특정 단어가 문서에 존재하는지를 0 or 1로 벡터화하는 것

1) TF-IDF (Term Frequency – Inverse Document Frequency) 소개

Term Frequency (TF): 특정 term의 단어의 등장빈도
Inverse Document Frequency (IDF): 단어가 제공하는 정보의 양 (단어가 얼마나 덜 등장하는지)
TF x IDF 로 최종 수치를 잼 (어떤 문서 내에 단어가 많이 등장했는데, 전체 문서 내에는 그 단어가 별로 없다 -> 더 높은 점수를 받을 수 있음)
ex) It was the best of times
-> It, was, the, of : 자주 등장하지만 제공하는 정보량이 적음
-> best, times : 좀 더 많은 정보를 제공

2) Term Frequenct (TF)

해당 문서 내 단어의 등장 빈도
BoW는 0 or 1로 표현했지만 TF는 등장 횟수 표현 가능
해당 문서에서의 단어의 중요도를 나타냄
1. Raw count
2. Adjusted for doc length : raw count / num words (TF)
3. Other variants : binary, log normalization, etc.

3) Inverse Document Frequency (IDF)

단어가 제공하는 정보의 양
모든 문서에 등장하는 단어는 IDF 값이 0이 됨 (e.g. N=100, DF(t)=100)
해당 단어의 문서 전체에서의 중요도를 나타냄

Document Frequency (DF) = Term t가 등장한 document의 개수
N: 총 document의 개수

TF와 달리 IDF는 각 term에 특정되고 문서에는 무관함
자주 출현한 단어들은 IDF 값이 낮음
IDF 값은 문서에 상관없이 항상 일정한 값을 가짐

4) Combine TF & IDF

TF-IDF(t, d) : TF-IDF for term t in document d

‘a’, ‘the’ 등 관사 ⇒ Low TF-IDF
- TF는 높을 수 있지만, IDF가 0에 가까울 것 (거의 모든 document에 등장 ⇒ N ≈ DF(t) ⇒ log(N/DF) ≈ 0)
자주 등장하지 않는 고유 명사 (ex. 사람 이름, 지명 등) ⇒ High TF-IDF
- IDF가 커지면서 전체적인 TF-IDF 값이 증가
질의 TF-IDF 계산 후 가장 관련있는 문서 찾기
1. 사용자가 입력한 질의 토큰화
2. 기존 vocab에 없는 토큰 제외
3. 질의를 하나의 문서로 생각하고, 이에 대한 TF-IDF 계산
4. 질의 TF-IDF 값과 각 문서별 TF-IDF 값을 곱해 유사도 점수 계산
5. 가장 높은 점수를 가지는 문서 선택

5) BM25

TF-IDF 의 개념을 바탕으로, 문서의 길이까지 고려하여 점수를 매김
TF 값에 한계를 지정해두어 일정한 범위를 유지하도록 함
평균적인 문서의 길이 보다 더 작은 문서에서 단어가 매칭된 경우 그 문서에 대해 가중치를 부여
실제 검색엔진, 추천 시스템 등에서 아직까지도 많이 사용되는 알고리즘
https://github.com/dorianbrown/rank_bm25

BM25에서 직접 변경 가능한 파라미터

k1 : Term Frequency의 saciling을 조절
- 0 : binary model : 문서에 단어 존재 유무
- 숫자가 커지면, 실제 term frequency를 사용하겠다는 의미
- 일반적으로 1.2에서 2.0 사이
b : 문서 길이 normalization
- 0 : no normalization
- 1 : full length normalization
- 일반적으로 0.75를 사용