이 게시물은 텍스트 유사도 검색이라는 특정 기술에 중점을 두고 있습니다. 이 유형의 검색에서는 사용자가 짧은 자유 텍스트 쿼리를 입력하면 쿼리와의 유사성에 따라 문서 순위가 매겨집니다. 텍스트 유사성은 다양한 사용 사례에서 유용하게 사용될 수 있습니다:

• 질문-답변: 자주 묻는 질문 모음이 주어지면 사용자가 입력한 질문과 유사한 질문을 찾습니다.

• 논문 검색: 연구 논문 모음에서 사용자의 검색어와 밀접한 관련이 있는 제목의 기사를 반환합니다.

• 이미지 검색: 캡션이 있는 이미지 데이터 세트에서 사용자의 설명과 유사한 캡션이 있는 이미지를 찾습니다.

유사성 검색에 대한 간단한 접근 방식은 문서가 쿼리와 얼마나 많은 단어를 공유하는지에 따라 순위를 매기는 것입니다. 그러나 공통 단어가 거의 없더라도 문서가 쿼리와 유사할 수 있으며, 보다 강력한 유사성 개념은 구문 및 의미론적 내용도 고려합니다.

자연어 처리(NLP) 커뮤니티에서는 단어와 문장을 숫자 벡터로 인코딩하는 텍스트 임베딩이라는 기술을 개발했습니다. 이러한 벡터 표현은 텍스트의 언어적 내용을 캡처하도록 설계되었으며 쿼리와 문서 간의 유사성을 평가하는 데 사용할 수 있습니다.

이 게시물에서는 텍스트 임베딩과 Elasticsearch의 dense_vector 유형을 사용하여 유사도 검색을 지원하는 방법을 살펴봅니다. 먼저 임베딩 기술에 대한 개요를 살펴본 다음, Elasticsearch를 사용한 간단한 유사성 검색 프로토타입을 단계별로 살펴보겠습니다.

텍스트 임베딩이란 무엇인가요?

다양한 유형의 텍스트 임베딩과 기존 검색 방식과 비교하여 자세히 살펴보겠습니다.

단어 임베딩

단어 임베딩 모델은 단어를 밀도가 높은 숫자 벡터로 표현합니다. 이러한 벡터는 단어의 의미적 속성을 포착하는 것을 목표로 하며, 벡터가 서로 가까운 단어는 의미적 의미 측면에서 유사해야 합니다. 좋은 임베딩에서는 벡터 공간의 방향이 단어 의미의 다양한 측면에 연결됩니다. 예를 들어, "캐나다" 의 벡터는 한 방향으로는 "프랑스" 에 가깝고 다른 방향으로는 "토론토" 에 가까울 수 있습니다.

NLP 및 검색 커뮤니티에서는 꽤 오랫동안 단어의 벡터 표현에 관심을 가져왔습니다. 지난 몇 년 동안 신경망을 사용하여 많은 전통적인 작업을 재검토하면서 단어 임베딩에 대한 관심이 다시 높아졌습니다. 단어 임베딩 알고리즘이 성공적으로 개발되었는데, 워드2vec과 GloVe가 대표적입니다. 이러한 접근 방식은 대규모 텍스트 컬렉션을 활용하고 각 단어가 나타나는 문맥을 검토하여 벡터 표현을 결정합니다:

• word2vec 스킵그램 모델은 신경망을 훈련시켜 문장에서 단어 주변의 문맥 단어를 예측합니다. 네트워크의 내부 가중치는 임베딩이라는 단어를 부여합니다.

• GloVe에서 단어의 유사성은 다른 문맥 단어와 얼마나 자주 나타나는지에 따라 달라집니다. 이 알고리즘은 단어 동시 발생 횟수에 대한 간단한 선형 모델을 학습합니다.

많은 연구 그룹에서 Wikipedia나 Common Crawl과 같은 대규모 텍스트 말뭉치에 대해 사전 학습된 모델을 배포하고 있으므로 다운로드하여 다운스트림 작업에 편리하게 연결할 수 있습니다. 사전 학습된 버전을 직접 사용하는 경우도 있지만, 특정 대상 데이터 세트와 작업에 맞게 모델을 조정하는 것이 도움이 될 수 있습니다. 이는 종종 사전 학습된 모델에 '미세 조정' 단계를 실행하여 수행합니다.

단어 임베딩은 매우 강력하고 효과적인 것으로 입증되었으며, 이제 기계 번역 및 감정 분류와 같은 NLP 작업에서 개별 토큰 대신 임베딩을 사용하는 것이 일반적인 관행이 되었습니다.

문장 임베딩

최근에는 연구자들이 단어뿐만 아니라 긴 텍스트 섹션을 표현하는 임베딩 기술에 집중하기 시작했습니다. 현재 대부분의 접근 방식은 복잡한 신경망 아키텍처를 기반으로 하며, 의미 정보를 포착하는 데 도움을 주기 위해 학습 중에 레이블이 지정된 데이터를 통합하기도 합니다.

학습이 완료된 모델은 문장을 가져와 문맥에 따라 각 단어에 대한 벡터와 전체 문장에 대한 벡터를 생성할 수 있습니다. 단어 임베딩과 마찬가지로 많은 모델의 사전 학습된 버전이 제공되므로 사용자는 값비싼 학습 과정을 생략할 수 있습니다. 학습 과정은 매우 리소스 집약적일 수 있지만, 모델을 호출하는 것은 훨씬 더 가볍습니다. 문장 임베딩 모델은 일반적으로 실시간 애플리케이션의 일부로 사용할 수 있을 만큼 빠릅니다.

몇 가지 일반적인 문장 임베딩 기술로는 InferSent, 범용 문장 인코더, ELMo, BERT 등이 있습니다. 단어 및 문장 임베딩을 개선하는 것은 활발한 연구 분야이며, 강력한 모델이 추가로 도입될 가능성이 높습니다.

기존 검색 방식과 비교

기존 정보 검색에서 텍스트를 숫자 벡터로 표현하는 일반적인 방법은 어휘의 각 단어에 하나의 차원을 할당하는 것입니다. 그런 다음 텍스트의 벡터는 어휘의 각 용어가 나타나는 횟수를 기반으로 합니다. 이러한 텍스트 표현 방식은 문장 구조와 관계없이 단순히 단어 발생 횟수만 계산하기 때문에 흔히 "단어 가방," 이라고도 합니다.

텍스트 임베딩은 몇 가지 중요한 점에서 기존의 벡터 표현과 다릅니다:

• 인코딩된 벡터는 밀도가 높고 비교적 낮은 차원으로, 보통 100~1,000차원에 걸쳐 있습니다. 이와 대조적으로 단어의 가방 벡터는 희소하며 50,000개 이상의 차원으로 구성될 수 있습니다. 임베딩 알고리즘은 의미론적 의미를 모델링하기 위해 텍스트를 저차원 공간으로 인코딩합니다. 이상적으로 동의어 단어와 구문은 새 벡터 공간에서 비슷한 표현으로 끝납니다.

• 문장 임베딩은 벡터 표현을 결정할 때 단어의 순서를 고려할 수 있습니다. 예를 들어" 의 "튠이라는 문구는 "의" 과는 매우 다른 벡터로 매핑될 수 있습니다.

• 실제로 문장 임베딩은 텍스트의 큰 섹션에 잘 적용되지 않는 경우가 많습니다. 일반적으로 짧은 단락보다 긴 텍스트를 나타내는 데는 사용되지 않습니다.

유사도 검색에 임베딩 사용

질문과 답변이 많이 모였다고 가정해 보겠습니다. 사용자가 질문을 하면 컬렉션에서 가장 유사한 질문을 검색하여 답변을 찾을 수 있도록 도와줍니다.

텍스트 임베딩을 사용하여 유사한 질문을 검색할 수 있도록 할 수 있습니다:

• 인덱싱하는 동안 각 질문은 문장 임베딩 모델을 통해 실행되어 숫자 벡터를 생성합니다.

• 사용자가 쿼리를 입력하면 동일한 문장 임베딩 모델을 통해 실행되어 벡터를 생성합니다. 응답의 순위를 매기기 위해 각 질문과 쿼리 벡터 간의 벡터 유사도를 계산합니다. 임베딩 벡터를 비교할 때는 코사인 유사도를 사용하는 것이 일반적입니다.

이 리포지토리는 Elasticsearch에서 이를 어떻게 수행할 수 있는지에 대한 간단한 예를 보여줍니다. 기본 스크립트는 StackOverflow 데이터 세트에서 최대 20,000개의 질문을 색인한 다음 사용자가 데이터 세트에 대해 자유 텍스트 쿼리를 입력할 수 있도록 합니다.

곧 스크립트의 각 부분을 자세히 살펴보겠지만 먼저 몇 가지 결과 예시를 살펴보겠습니다. 많은 경우, 이 방법은 쿼리와 색인된 질문 간에 단어가 많이 겹치지 않는 경우에도 유사성을 포착할 수 있습니다:

• "파일 압축하기" 반환 "폴더 압축/압축 풀기 & 파일"

• "" 반환 문자열이 IP인지 호스트 이름인지 어떻게 알 수 있나요? ""

• "바이트를 복수로 변환" 반환 "파이썬에서 바이트를 부동 소수점 숫자로 변환하기"

구현 세부 정보

스크립트는 TensorFlow에서 임베딩 모델을 다운로드하고 생성하는 것으로 시작됩니다. Google의 범용 문장 인코더를 선택했지만 다른 많은 임베딩 방법을 사용할 수 있습니다. 스크립트는 추가 교육이나 미세 조정 없이 임베딩 모델을 그대로 사용합니다.

다음으로, 질문 제목, 태그, 그리고 벡터로 인코딩된 질문 제목에 대한 매핑을 포함하는 Elasticsearch 인덱스를 생성합니다:

dense_vector에 대한 매핑에서 벡터에 포함될 차원 수를 지정해야 합니다. title_vector 필드를 색인할 때 Elasticsearch는 매핑에 지정된 것과 동일한 수의 차원을 가지고 있는지 확인합니다.

문서를 색인화하기 위해 임베딩 모델을 통해 질문 제목을 실행하여 숫자 배열을 얻습니다. 이 배열은 title_vector 필드에 있는 문서에 추가됩니다.

사용자가 쿼리를 입력하면 먼저 동일한 임베딩 모델을 통해 텍스트가 실행되고 쿼리 벡터 매개변수에 저장됩니다. 7.3 버전부터 Elasticsearch는 기본 스크립팅 언어로 cosineSimilarity 함수를 제공합니다. 따라서 사용자 쿼리와의 유사성을 기준으로 질문의 순위를 매기기 위해 스크립트_스코어 쿼리를 사용합니다:

모든 새 쿼리에서 스크립트()를 다시 컴파일하지 않도록쿼리 벡터를 스크립트 매개변수로 전달해야 합니다. Elasticsearch는 음수 점수를 허용하지 않으므로 코사인 유사도에 음수 점수를 추가해야 합니다.

| 참고: 이 블로그 게시물은 원래 Elasticsearch 7.3에서 사용할 수 있었던 벡터 함수에 대해 다른 구문을 사용했지만 7.6에서 더 이상 사용되지 않습니다. |

중요한 제한 사항

script_score 쿼리는 제한적인 쿼리를 래핑하고 반환하는 문서의 점수를 수정하도록 설계되었습니다. 하지만 인덱스의 모든 문서에 대해 스크립트가 실행된다는 의미의 match_all 쿼리를 제공했습니다. 벡터는 문서 채점에는 사용할 수 있지만 초기 검색 단계에서는 사용할 수 없다는 것이 현재 Elasticsearch의 벡터 유사성의 제한 사항입니다. 벡터 유사성을 기반으로 한 검색 지원은 현재 진행 중인 중요한 작업 영역입니다.

모든 문서를 스캔하는 것을 피하고 빠른 성능을 유지하려면 match_all 쿼리를 보다 선택적인 쿼리로 대체할 수 있습니다. 검색에 사용할 수 있는 올바른 쿼리는 특정 사용 사례에 따라 달라질 수 있습니다.

위에서 몇 가지 고무적인 사례를 살펴봤지만, 결과가 노이즈가 많고 직관적이지 않을 수도 있다는 점에 유의해야 합니다. 예를 들어, "파일을 압축하는 경우" " 부분 .csproj에도 높은 점수를 부여합니다. 파일" 및 ".pyc를 피하는 방법 파일은". 그리고 메서드가 놀라운 결과를 반환하는 경우, 각 벡터 구성 요소의 의미가 불분명하고 해석 가능한 개념과 일치하지 않는 경우가 많아 문제를 디버그하는 방법이 항상 명확하지 않습니다. 단어 중복에 기반한 기존의 채점 기법을 사용하면 "이 문서가 높은 순위를 차지한 이유는 무엇인가요? 라는 질문에 답하기가 더 쉬워지는 경우가 많습니다."

앞서 언급했듯이 이 프로토타입은 임베딩 모델을 벡터 필드와 함께 사용할 수 있는 방법을 보여주는 예시일 뿐, 실제 제작에 사용할 수 있는 솔루션은 아닙니다. 새로운 검색 전략을 개발할 때는 자체 데이터에서 접근 방식이 어떻게 수행되는지 테스트하고 일치 검색어와 같은 강력한 기준과 비교하는 것이 중요합니다. 대상 데이터 세트에 대한 임베딩 모델을 미세 조정하거나 단어 수준 쿼리 확장 등 임베딩을 통합하는 다양한 방법을 시도하는 등 확실한 결과를 얻기 전에 전략을 크게 변경해야 할 수도 있습니다.

결론

임베딩 기술은 텍스트의 언어적 콘텐츠를 캡처할 수 있는 강력한 방법을 제공합니다. 임베딩을 색인하고 벡터 거리를 기반으로 점수를 매김으로써 단어 수준의 중첩을 넘어서는 유사성 개념을 사용하여 문서를 비교할 수 있습니다.

벡터 필드 유형을 기반으로 하는 더 많은 기능을 소개할 수 있기를 기대합니다. 검색에 벡터를 사용하는 것은 미묘한 차이가 있고 발전 중인 영역입니다. 언제나 그렇듯이 Github과 토론 포럼에서 여러분의 사용 사례와 경험을 듣고 싶습니다!

배경

Elasticsearch를 개발하는 동안, 우리는 때때로 이를 해결하기 위한 간단하거나 확립된 접근 방식이 없는 중요한 문제에 직면하게 됩니다. "흠, 이 문제를 다룬 학술 논문이 있나요?"라고 묻는 것은 당연한 질문입니다. 때로는 학문적 연구가 영감의 원천이 되기도 합니다. 새로운 알고리즘이나 데이터 구조를 제안하는 논문을 접하고 "정말 유용할 것 같다!"라고 생각하게 됩니다. 다음은 Elasticsearch와 Apache Lucene이 학술 작업을 통합하는 방법의 몇 가지 예입니다:

• 카디널리티 집계를 위한 HyperLogLog++

• 적응형 복제본 선택을 위한 C3 알고리즘

• 루씬에서 가장 가까운 벡터 검색을 위한 계층적 탐색 가능한 작은 세계 그래프(HNSW)

• 머신 러닝 분류를 개선하기위한 MIC 통계

• Lucene에서 더 빠른 인기 검색을 위한블록 최대 WAND

• ... 그리고 더 많은 것

학술 논문은 데이터 집약적인 시스템을 개발하는 엔지니어에게 매우 귀중한 자료입니다. 그러나 알고리즘 설명이 복잡하고 중요한 실용적인 세부 사항이 생략된 경우가 많아 구현하기가 어렵고 오류가 발생하기 쉽습니다. 예를 들어, 데이터 세트에 따라 결과가 크게 달라지는 머신 러닝 알고리즘을 어떻게 철저하게 테스트할 수 있을까요?

소프트웨어 종속성을 평가할 때와 마찬가지로 논문을 평가하세요.

새 소프트웨어 종속성을 추가하려면 신중한 평가가 필요합니다. 다른 패키지가 부정확하거나 느리거나 안전하지 않은 경우 우리 프로젝트도 마찬가지일 수 있기 때문입니다. 개발자는 종속성을 가져오기 전에 종속성의 품질을 평가해야 합니다.

구현을 고려 중인 학술 논문에도 동일하게 적용됩니다. 알고리즘이 논문에 발표되었기 때문에 정확하고 성능이 좋아야 한다고 생각할 수 있습니다. 그러나 검토 과정을 통과했더라도 학술 논문에는 문제가 있을 수 있습니다. 정확성 증명은 현실적이지 않은 가정에 의존하는 것일 수도 있습니다. 또는 '실험' 섹션에서 기준선보다 훨씬 더 나은 성능을 보여 주지만 이는 특정 데이터 세트에만 해당됩니다. 논문 품질이 뛰어나더라도 그 접근 방식이 프로젝트에 적합하지 않을 수 있습니다.

학술 논문에 대한 '의존성' 여부를 고려할 때는 소프트웨어 패키지에 대해 동일한 질문을 하는 것이 도움이 됩니다:

• 라이브러리가 널리 사용되고 '실전 테스트'를 거쳤나요? → 다른 패키지에서 이 문서를 구현한 적이 있으며 잘 작동했나요?

• 성능 벤치마크가 제공되나요? 정확하고 공정해 보이나요? → 논문에 실제 실험이 포함되어 있나요? 디자인이 잘 되어 있나요?

• 성능 개선이 복잡성을 정당화할 만큼 충분히 큰가요? → 논문이 강력한 기준 접근 방식과 비교되나요? 이 기준선을 얼마나 능가하나요?

• 이 접근 방식이 우리 시스템과 잘 통합되나요? → 알고리즘의 가정과 트레이드오프가 우리 사용 사례에 맞는가?

소프트웨어 패키지가 경쟁사와의 성능 비교를 발표할 때 항상 가장 빠르게 나오는 패키지가 있습니다! 제3자가 벤치마크를 설계했다면 더 균형 잡힌 결과를 얻을 수 있습니다. 학술 논문에도 동일한 현상이 적용됩니다. 알고리즘이 원본 논문에서 좋은 성능을 보였을 뿐만 아니라 다른 논문에서도 강력한 기준이 되는 것으로 나타난다면 그 알고리즘은 견고할 가능성이 매우 높습니다.

창의적으로 테스트하기

학술 논문의 알고리즘은 우리가 일상적으로 접하는 알고리즘 유형보다 더 정교한 동작을 하는 경우가 많습니다. 아마도 더 나은 속도를 위해 정확도를 희생하는 근사 알고리즘일 것입니다. 또는 대규모 데이터 세트를 받아 (때로는 예상치 못한) 결과를 생성하는 머신 러닝 방법일 수도 있습니다. 이러한 알고리즘의 동작을 간단한 방법으로 특성화할 수 없다면 어떻게 테스트를 작성할 수 있을까요?

불변값에 집중

단위 테스트를 설계할 때 알고리즘에 이 예제 입력을 제공하면 해당 출력을 가져야 한다는 식으로 예제 측면에서 생각하는 것이 일반적입니다. 안타깝게도 대부분의 수학 알고리즘은 예제 기반 테스트만으로는 그 동작을 충분히 커버할 수 없습니다.

Elasticsearch가 검색 요청을 처리할 노드를 파악하는 데 사용하는 C3 알고리즘을 살펴보겠습니다. 노드의 이전 서비스 및 응답 시간, 대기열 크기를 통합하는 미묘한 공식을 사용하여 각 노드의 순위를 매깁니다. 몇 가지 예를 테스트한다고 해서 공식을 제대로 이해했는지 확인할 수 있는 것은 아닙니다. 서비스 시간이 증가하면 노드의 순위가 감소하는가? 등 한 발 물러서서 불변성 테스트에 대해 생각해 보는 것도 도움이 됩니다. 대기열 크기가 0인 경우, 논문에서 주장한 것처럼 응답 시간에 따라 순위가 결정되나요?

불변값에 집중하면 여러 가지 일반적인 경우에 도움이 될 수 있습니다:

• 이 방법은 순서에 구애받지 않아야 하나요? 그렇다면 입력 데이터를 다른 순서로 전달해도 동일한 출력을 얻을 수 있습니다.

• 알고리즘의 어떤 단계가 클래스 확률을 생성하나요? 그렇다면 이 확률의 합계는 1이 되어야 합니다.

• 함수가 원점을 중심으로 대칭인가요? 그렇다면 입력의 부호를 뒤집으면 출력의 부호도 뒤집히게 됩니다.

C3를 처음 구현할 때 응답 시간 대신 응답 시간의 역수를 실수로 사용하는 공식에 버그가 있었습니다. 이는 느린 노드가 더 높은 순위를 차지할 수 있다는 것을 의미했습니다! 문제를 수정할 때 향후 실수를 방지하기 위해 불변 확인을 추가했습니다.

레퍼런스 구현과 비교

저자들은 논문과 함께 알고리즘의 구현을 공개할 예정입니다. (많은 저널에서 저자가 결과 재현을 위한 코드를 게시하도록 요구하기 때문에 논문에 실험이 포함된 경우 특히 그렇습니다.) 이 참조 구현과 비교하여 접근 방식을 테스트하여 알고리즘의 중요한 세부 사항을 놓치지 않았는지 확인할 수 있습니다.

가장 가까운 이웃 검색을 위한 Lucene의 HNSW 구현을 개발하는 동안, 논문 저자의 참조 라이브러리와 비교하여 테스트했습니다. 동일한 데이터 세트에 대해 Lucene과 라이브러리를 모두 실행하여 결과의 정확도와 수행한 계산 횟수를 비교했습니다. 이 수치가 거의 일치하면 Lucene이 알고리즘을 충실히 구현한다는 것을 알 수 있습니다.

알고리즘을 시스템에 통합할 때는 여러 코어로 확장하거나 휴리스틱을 추가하여 성능을 개선하는 등 수정 또는 확장을 해야 하는 경우가 많습니다. 먼저 "바닐라" 버전을 구현하고 레퍼런스와 비교하여 테스트한 다음 점진적으로 변경하는 것이 가장 좋습니다. 이렇게 하면 사용자 지정하기 전에 모든 핵심 부분을 캡처했다고 확신할 수 있습니다.

기존 알고리즘과의 결투

마지막 섹션에서는 테스트 불변수에 대한 또 다른 아이디어를 제시합니다. 알고리즘의 출력을 더 간단하고 이해하기 쉬운 알고리즘의 출력과 비교하는 것입니다. 예를 들어, 상위 결과에 표시되지 않는 문서를 건너뛰어 문서 검색 속도를 높여주는 Lucene의 블록 최대 WAND 알고리즘을 생각해 보세요. 모든 경우에 블록맥스 WAND가 어떻게 작동해야 하는지 정확히 설명하기는 어렵지만, 적용한다고 해서 상위 결과가 바뀌지는 않는다는 것은 알고 있습니다! 따라서 테스트에서는 여러 개의 무작위 검색 쿼리를 생성한 다음 WAND 최적화를 적용하거나 적용하지 않은 상태에서 실행하여 결과가 항상 일치하는지 확인할 수 있습니다.

이러한 테스트의 중요한 측면은 비교를 실행하기 위해 무작위 입력을 생성한다는 것입니다. 이를 통해 생각하지 못했던 사례를 연습하고 예상치 못한 문제를 발견할 수 있습니다. 예를 들어, BM25F 채점에 대한 Lucene의 무작위 비교 테스트는 미묘한 에지 케이스에서 버그를 발견하는 데 도움이 되었습니다. 알고리즘에 무작위 입력을 공급하는 아이디어는 컴퓨터 보안의 일반적인 테스트 기법인 퍼징 개념과 밀접한 관련이 있습니다.

Elasticsearch와 Lucene은 이 테스트 접근 방식을 자주 사용합니다. 두 알고리즘(TestDuelingAnalyzers, testDuelTermsQuery...) 간에 "결투" 를 언급하는 테스트가 표시되면 이 전략이 실행 중인 것입니다.

논문 용어 사용

다른 개발자가 여러분의 코드를 작업할 때는 해당 문서를 참조하여 세부 사항을 따라야 합니다. Elasticsearch의 HyperLogLog++ 구현에 대한 코멘트가 이를 잘 설명해줍니다: "논문을 읽지 않고 이 클래스가 하는 일을 이해하려고 하는 것은 모험적인 일로 간주됩니다." 이 메서드 주석도 좋은 예가 됩니다. 여기에는 학술 논문 링크가 포함되어 있으며, 원래 설명된 알고리즘에 어떤 수정 사항이 있었는지 강조 표시되어 있습니다.

개발자는 문서를 기반으로 코드를 이해하게 되므로 동일한 용어를 사용하는 것이 도움이 됩니다. 수학적 표기는 간결하기 때문에 일반적으로 '좋은 스타일'로 간주되지 않지만 논문의 맥락에서는 매우 명확한 이름이 될 수 있습니다. 학술 논문의 공식은 rS, muBarSInverse와 같은 암호화된 변수 이름을 Elasticsearch에서 접하게 되는 몇 안 되는 경우 중 하나입니다.

저자가 추천하는 논문 읽기 방법: 큰 커피와 함께.

작성자에게 이메일을 보낼 수 있습니다.

어려운 논문을 작성하다 보면 공식을 잘못 이해한 건지, 오타가 있는 건지 몰라 몇 시간 동안 고민할 때가 있습니다. 오픈 소스 프로젝트인 경우 GitHub 또는 StackOverflow에서 질문할 수 있습니다. 그렇다면 학술 논문은 어디에서 구할 수 있을까요? 작성자는 바빠 보이고 이메일에 짜증이 날 수 있습니다.

오히려 많은 학자들이 자신의 아이디어가 실용화되고 있다는 소식을 듣고 기뻐하며 이메일을 통해 기꺼이 질문에 답변해 줍니다. 그들이 잘 알고 있는 제품이라면 웹사이트에 애플리케이션을 등록할 수도 있습니다!

또한 학계에서 소프트웨어 개발과 동일한 많은 도구를 사용하여 공개적으로 논문을 토론하는 경향이 증가하고 있습니다. 문서에 소프트웨어 패키지가 함께 제공되는 경우 Github에서 일반적인 질문에 대한 답변을 찾을 수 있습니다. "이론적 컴퓨터 과학" 및 "교차 검증"과 같은 Stack Exchange 커뮤니티에는 인기 있는 논문에 대한 자세한 토론도 포함되어 있습니다. 일부 학회에서는 모든 논문 리뷰를 온라인으로 게시하기 시작했습니다. 이 리뷰에는 접근 방식에 대한 유용한 인사이트를 얻을 수 있는 저자와의 주고받는 토론이 포함되어 있습니다.

계속하기

이 게시물에서는 학술 논문 선택의 기본 사항에 중점을 두고 다음과 같이 설명합니다.

를 올바르게 구현하는 방법을 설명하지만 실제로 알고리즘을 배포하는 모든 측면을 다루지는 않습니다. 예를 들어 알고리즘이 복잡한 시스템에서 하나의 구성 요소에 불과한 경우 구성 요소의 변경이 엔드투엔드 개선으로 이어지도록 하려면 어떻게 해야 할까요? 알고리즘을 통합하는 과정에서 원본 논문에서 다루지 않은 상당한 수정이나 확장이 필요하다면 어떻게 해야 할까요? 이러한 주제는 향후 포스팅에서 더 많이 공유하고자 하는 중요한 주제입니다.