Git Product home page Git Product logo

inhyeokyoo.github.io's Introduction

유인혁

Contact

Email Blog

Conventions

  • file name: snake-case
    • 단, 약자의 경우 대문자를 허용 (e.g. BERT)
    • 띄어쓰기는 허용하지 않음
  • 모든 포스트는 하나의 대표 카테고리를 갖음
    • 이는 category가 됨
    • 저장위치: _posts/category-name/
    • 여러 카테고리를 갖을 수도 있지만, 여전히 대표 카테고리는 하나가 됨.
    • tag는 대표주제가 아닌, 세부적인 내용과 관련하여 적음
      • e.g. 선형대수에서 matrix decomposition 중 SVD를 다뤘다면, Category는 Matrix Decomposition이 되고, tag는 SVD가 됨.
      • e.g. SVD를 활용한 LSA에 대해 다뤘다면, Category는 Machine Learning이나 NLP가 되지, SVD가 될 수 없음.
    • permalink: /Category-Name/post-name/
  • Project
    • Project도 포스트이므로 하나의 대표 카테고리를 갖음
    • 저장위치: _pages/project/Camel Case/
    • permalink: /project/project-name/post-name/
  • categories
    • _pages 폴더 내에 Category Name.md파일 생성필요
    • 이는 category가 됨
    • Convention: Camel Case or camel case
  • tags
    • Convention: Camel Case or camel case

inhyeokyoo.github.io's People

Contributors

mmistakes avatar inhyeokyoo avatar ibug avatar coliff avatar lsolesen avatar maxheld83 avatar ohadschn avatar kulbhushanchand avatar dependabot[bot] avatar zenharbinger avatar nickgarlis avatar seankilleen avatar vincenttam avatar fa-ribeiro avatar edemaine avatar torrocus avatar hkalant avatar justinrummel avatar scot3004 avatar quanengineering avatar rschaerer avatar akhyarrh avatar tobie avatar gamue avatar yihangho avatar tlindsay42 avatar tony-ho avatar lucascaton avatar maazadeeb avatar maxime-michel avatar

Stargazers

diff.blog avatar

Watchers

James Cloos avatar  avatar

Forkers

liycg

inhyeokyoo.github.io's Issues

QA vs. MRC

QA vs. MRC
Question answering is just the broad category of which MRC is one specific part. MRC requires some context along with the request or question, while QA does not. If you ask "Who is the US president?", it is QA since there is no context to read and comprehend. If you add a paragraph of context that somehow contains the answer, then it can be considered an MRC task.

MRC tasks are a group of tasks which to solve them you need the ability to read some text
QA tasks are a group of tasks which to solve them you have to answer a question

QA tasks can be solved in different ways, as we saw before (Retriever-Generator, Retriever-Extractor, Generator, and other). Sometimes a QA task is solved with a MRC technique, this is the reason for the convergence.

Retriever-Extractor and Retriever-Generator, for example, are solutions that fall in this case because they required the ability to read a text. Instead, the solution that is made up only of the Generator solve a QA problem without requiring this skill (so without using a MRC solution).

Just to be clear: of course, not all the MRC solutions are made up to solve QA problems. MRC is the ability to comprehend a text by reading it. This ability can be tested with different tasks, which can also be funded in other NLP problems. If while I am solving a QA task I find a MRC problem, I of course use the MRC solutions that fit well to solve it.

Another interesting thing that I found interesting in that article is the interesting classification of MRC tasks showed below.

https://alessandro-lombardini.medium.com/summary-of-question-and-answering-task-889d5cf70017
https://arxiv.org/pdf/2006.11880.pdf

옮길거

https://arxiv.org/pdf/2010.06467.pdf

다큐먼트 랭킹의 경우 symmetric하지 않음. 따라서 semantic similarity가 qeur-document 연관성을 그대로 측정하기는
어려울 수 있음.

MS MARCO: 데이터 셋

Text ranking의 formulation은 구조화되지 않은 corpus/text의 collection \mathcal C = {d _i}가 있다고 가정. \mathcal C는 매우 크기 때문에, computational efficiency가 고려가 되야 함.

텍스트의 길이는 다양하므로, 텍스트의 구성이나 처리방법, 랭킹에 대한 최종적인 세분화 정도는 독립적일 수 있다. 예를 들면, 논문 같은 경우 타이틀이나 초록만 검색하게끔 고를 수 있다. 이 겨우 아티클에 대한 일부 포션만 다루게 된다. 이에 대체되는 방법은 아티클을 파라그래프로 나누고 각 파라그래프를 검색에 대한 유닛으로 바라보는 것이다. 즉, 시스템은 파라그래프에 대한 리스트를 결과로 반환하게 된다. 또 다른 방법은 파라그래프에 대한 evidence를 취합하여 랭킹하는 것이다. 이는, 파라그래프를 분석의 기본 단위로 취급하지만, 글 자체를 랭킹하는 것은 이로부터 얻어진 파라그래프가 된다.

랭킹을 목적으로 문서를 passage로 나누고 여러 문서의 granularity로부터 evidence를 통합하는 것 (이를 passage retrieval이라고도 함)은 1990년대에 많이 있었음. 이 경우 중요한 것은 적절한 수준의 granularity를 결정하는 것이 까다로울 수 있다는 것임. 예를 들어 이메일 같은 경우 개개의 이메일로 진행해야될지, 이메일의 연속을 봐야할지 어려움.

텍스트의 길이는 트랜스포머를 활용한 랭킹에도 중요한 개념임. 왜냐하면 시퀀스를 정해놓기 때문에 긴 문장을 의미있게 인코드하기가 어렵고, 이에 따른 메모리 이슈가 있음.

유저가 사용하는 짧은 키워드 쿼리는 단지 information need에 대한 표현: 이를 anmoalous state of knoledge (ASK)라 함. 따라서 쿼리랑 인포메이션 니드는 엄밀히 말하여 동의어가 아니다.

TREC에서는 인포메이션 니즈를 '토픽'으로서 조작할 수 있게 한다. Ad hoc retrieval를 위한 TREC topic은 다음과 같다:

  • 타이틀: 인포메이션 니드를 설명할 수 있는 몇개의 키워드로 구성. 서치엔진에 유저가 입력하는 쿼리랑 가까움
  • 디스크립션: 잘 구성된 자연어 문장으로 desired information을 잘 묘사.
  • narrative: 산문체의 파라그래프로, desired information에 대한 자세한 기술.

대부분의 IR 이밸류에이션에서 타이틀은 쿼리로서 사용. Narrative가 더 많은 정보를 포함하고 있는 것은 사실이나, 대부분의 경우 네러티브를 랭킹 모델에 넣는 것은 안 좋은 결과를 불러옴 <- 토픽과 연관없는 term이 많기 때문.

도메인에 따라 다르긴 하지만, 일반적으론 타이틀/타이틀+디스크립션 조합이 백 오브 워즈 쿼리에서 좋은 결과를 냄. 그러나 효율적인면에서 이 둘의 차이는 없다. 그럼에도 불구하고 여기서 핵심은 랭킹모델에 들어가는 인포메이션 니드의 표현이 종종 retrieval effectiveness에 실질적인 효과를 갖는다는 점이다.

다음과 같이 인풋을 더 자세하게 표현하여 텍스트 랭킹 문제를 표현할 수 있다:
쿼리 $q$로 표현된 인포메이션 니드가 주어질 때, 텍스트 랭킹 태스크는 유한한 임의의 텍스트 컬렉션 $\mathcal C = {d _i}$로부터 관심있는 메트릭(e.g. nDCG, AP, etc.)을 최대화하는 k개의 랭킹 리스트 ${d _1, \cdots, d _k}$를 반환하는 것.

랭킹 테스크는 또한 tok-k retrieval/ranking 이라고도 불린다.

랭킹을 수행하는 "것"은 {ranking, retrieval, scoring} × {function, model, method, technique . . . } 등으로 불리며, 가끔은 "시스템" ("the system")이라고도 불린다.

여기서 중요한 차이점은 랭킹은 일반적으로 텍스트의 랭크드 리스트을 구성하는 작업을 의미하고, 이를 트랜스포머 기반의 모델에 바로 적용하여 top k를 뽑기에는 비실용적이다. 대신, 모델은 키워드 기반의 검색결과에 대해 문서의 후보를 rerank하기도 한다. 이를 formal하게 풀어쓰면 랭킹은 text의 리스트 $R = {d _1, \cdots d _k}$를 받아 또다른 리스트 $R' = {d' _1, \cdots d' _k}$을 만든다. 여기서 R 프라임은 R의 permutation이다. 모든 코퍼스를 reranker에 넣게 되면 개념적으로 랭킹과 리랭킹이 동일해지지만, 실제로 이 둘은 전혀 다른 테크닉을 사용한다.

2.3 Releavance

마지막으로 인포메이션 니드의 표현으로서의 쿼리를 텍스트의 "좋음"으로 측정하는 방법을 알아보자. 이러기 위해서는 metric이 필요하다. 궁극적으로 메트릭은 *관련성(relevance)*과 관련있으며, 이는 텍스트와 특정 인포메이션 니드 사이의 관계를 나타낸다. 어떤 텍스트는 information need를 해소할 수 있는 경우 관련이 있다고 말한다. 그러나 이를 이진적으로 다루는 것은 간단화한 것으로, 다차원에서 서열척도(ordinal scale)을 통해 연관도를 특성화하는 것이 더욱 정확한 평가를 가능하게 할 것이다.

연관도는 정확하게 정의하기 어려운 개념이다. 따라서 topical relevance (텍스트의 토픽이나 주제가 인포메이션 니드와 맞아 떨어지는가?), cognitive relevance (텍스트가 유저에게 이해할 수 있는 것인가?), situational relevance (텍스트를 통해 문제를 바로 해결할 수 있는가) 등의 개념들이 있다.

이를 설명해보자. 텍스트의 topic이 연관은 있지만, 전문가를 위해 쓰여져 있어서 검색자가 이해하지 못하는 경우가 있다. 이 경우 cognitive perspective로부터 연관이 없을 수 있다. 이번에는 유저가 특정한 결정을 내리기 위해 정보를 찾는 경우로 생각해보자. 텍스트의 topic이 연관이 있고, 유용한 정보를 제공해주긴 하지만, 이 결정에 실행가능한 조언을 못 주는 경우도 있을 것이다. 이 경우 topically relevant하다고 하지만, 유용하지는 않다 (즉, situational relevance가 없다).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.