보통 논문 비교하는 부분 작성할 때, 어떻게 가져다가 쓸까?
내가 구현한 코드의 특정부분만 교체하는걸까??

비교 실험 기본 원칙 (Reviewer 시점)

비교 실험헤서 reviewer가 보는건 이 성능 차이가 정말 제안하는 방법덕분인가? 인지이다. 그래서 다른 부분들은 최대한 고정하고 비교하고 싶은 요소만 최소한으로 바꾸어 비교한다.

일반적인 방법

“부분 교체 방식” (가장 정석)

내가 파이프라인을 구현한 상태라면, 제안하는 방법에 기존(비교군) 방법을 넣어 해당 부분만 변경한다.

예시

RAG 파이프라인을 기준으로 삼는다면, RAG는 보통 query를 통해 retriever가 관련 있는 문서를 검색해온다. 이 후, 선택된 문서를 통해 정답을 생성한다. 이 과정에서 기존 query의 reformulation, 검색된 문서를 pooling, reranking방법 적용, reader(답변 생성) 등을 적용하여 더 나은 답변을 도출하도록 한다.
만약, reranking 부분만 교체하고 싶다면 아래에서 reranking 방법만 교체한다.

Query
 → Query
 → Retrieval (same retriever)
 → Reranking / Selection Method
 → Answer / Evaluation

이 구조에서:

• Query 동일
• Retriever (FAISS 동일)
  • encoder 교체
    • Baseline: Bert
    • Prior work A : RoBerta
    • Prior work B : T5
• Top-K 동일
• Reranking 동일
  • Ours: Ourproposed method

그러면 review는 encoder 만 교체했다고 알 수 있다.

전체 파이프라인 비교

전체 파이프라인을 고치는 것은 주의해야할 부분이다.
비교대상이 아래와 같은 시스템 레벨 논문이라면,

• “End-to-end RAG framework”
• “Joint retrieval + generation optimization”

각 논문에서 제안한 다음 사항등을 유지해야한다.

• 동일 세팅
• 동일 데이터셋
• 동일 metrics

그러나 이런 경우에는

• retriever가 달라서 그런 거 아닐지
• encoder 차이 여부

Related Work 문단 작성

작성한 Related work는 비교 실험으로 이어진다.

• 예시 문장 :

  Unlike prior approaches that rely on a single, fixed encoder for document ranking, our method considers multiple encoder representations during the document selection process.

주의할 점!

❌ 다른 사람의 논문 결과를 숫자 그대로 가져와서는 안된다.
왜냐하면, 아래와 같은 이슈로 reviewer에게 공격당할 수 있으며,
“This is not comparable.” !

• dataset split 다름
• retriever 다름
• metric 정의 다름

❌ baseline을 약하게 잡기
비교할 수 있는 baseline을 잘 구성하여 넣는다
예를 들면, BM25사용이 당연한 것인데, 왜 비교군을 들어가지 않았는지 질문을 할 수 있다.