인용 가능성(citation likelihood)을 높이는 9가지 기법

Perplexity·ChatGPT Search·Gemini grounding 같은 RAG 기반 AI 답변 엔진은 출처를 선택할 때 희소 검색(BM25)·밀집 임베딩 유사도·교차 인코더 재순위화·청킹 완결성 네 레이어를 순차 적용한다. 각 레이어는 독립된 신호를 참조하므로, 인용 가능성(citation likelihood)을 높이려면 레이어별로 대응하는 기법을 적용해야 한다. 아래 9가지 기법은 Cuconasu et al. 2024 RAGAS 논문, Shi et al. 2023 Large Language Models Can Be Easily Distracted by Irrelevant Context, Perplexity 공개 인덱싱 가이드를 근거로 도출했다.

기법 1·2 — 수치·통계 삽입과 독립 완결 단락

작동 원리

BM25에서 숫자 토큰(23%, 2024년)은 역문서빈도(IDF)가 높아 희소 검색 점수를 상승시킨다. 밀집 임베딩 공간에서도 수치를 포함한 문장은 동일 수치를 언급하는 쿼리와 코사인 유사도가 구조적으로 높게 측정된다(실험 환경·임베딩 모델에 따라 다름). RAG는 문서를 고정 토큰 수 또는 문단 경계로 분할하므로, 한 단락 내에 맥락이 완결되지 않으면 청크가 잘려 인용 품질이 저하된다.

구현 방법

• 수치를 단락 첫 문장에 배치한다. 왜: 교차 인코더 재순위 단계에서 관련 구절이 앞에 있을수록 점수가 높다. 어떻게: "전환율이 상승했다" 대신 "2024년 3분기 전환율은 전년 대비 18% 상승했다"로 시작.
• 단락당 150~300 토큰(한국어 약 100~200자)을 유지한다. 왜: 512 토큰 청크 안에 단락 2~3개가 묶이므로 단락 경계 = 의미 경계를 맞춰야 청크 내 완결성이 보장된다. 어떻게: "주제문 → 근거 수치 → 결론" 3줄 구조로 작성.
• 수치마다 출처 연도를 인라인 표기한다. 왜: LLM은 날짜 정보를 신뢰도 신호로 사용하며, 연도 없는 수치는 재순위 단계에서 할인된다. 어떻게: (McKinsey, 2023) 형식으로 문장 끝에 표기.

검증/측정

RAGAS 오픈소스 프레임워크로 자체 RAG 파이프라인의 context_recall·faithfulness 지표를 측정한다. 외부 검증은 해당 수치를 Perplexity에 직접 쿼리해 자사 URL이 출처로 노출되는지 확인하는 방식으로 수행한다.

기법 3·4 — JSON-LD 구조화 데이터와 FAQ 마크업

작동 원리

Googlebot·PerplexityBot은 HTML 파싱과 별개로 <script type="application/ld+json"> 블록을 추출해 엔티티 그래프를 구성한다. FAQPage 스키마는 질문-답변 쌍을 명시적으로 전달하므로, 답변 엔진이 자연언어 파싱 단계를 건너뛰고 구조화된 데이터를 직접 인용 후보로 사용할 수 있다.

구현 방법

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "RAG 파이프라인에서 청킹 크기는 얼마로 설정해야 하나?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "일반적으로 512 토큰이 기본값으로 사용되지만, 문서 유형에 따라 256~1024 토큰 범위에서 실험해야 한다. 단락 경계와 청크 경계를 일치시키는 것이 context_recall을 높이는 데 효과적이다."
      }
    }
  ]
}

• FAQPage 스키마를 본문 FAQ와 1:1 동기화한다. 왜: 스키마와 본문이 불일치하면 크롤러가 스키마를 무효 처리한다. 어떻게: 빌드 단계에서 JSON-LD를 본문 FAQ 배열에서 자동 생성하는 스크립트 적용.
• Article 스키마에 datePublished·author·publisher를 모두 명시한다. 왜: E-E-A-T 신호가 Google SGE·Bing Copilot 재순위에 반영된다. 어떻게: "author": {"@type": "Person", "name": "박도현", "jobTitle": "AEO 리서처"} 형식 사용.

기법 5 — llms.txt 크롤러 인용 허용 선언

작동 원리

llms.txt는 2024년 Answer.AI 논의에서 제안된 비공식 컨벤션으로, LLM 크롤러(GPTBot, PerplexityBot, ClaudeBot)가 어떤 경로를 인용 가능한 콘텐츠로 처리할지 명시한다. robots.txt가 크롤 허용·차단 이진 제어라면, llms.txt는 "인용 우선순위"와 "라이선스 조건"을 추가로 전달하는 레이어다. 현재 공식 표준으로 확정되지 않았으며 크롤러별 지원 여부가 상이하다.

구현 방법

# llms.txt — 도메인 루트에 배치 (https://example.com/llms.txt)

# 인용 우선 경로
/blog/research/       priority: high
/docs/api/            priority: medium

# 인용 비허용 경로
/admin/               noindex: true
/drafts/              noindex: true

# 콘텐츠 메타
Organization: Citeon
Contact: [email protected]
License: CC-BY-4.0

• 우선순위 경로에는 수치·구조화 콘텐츠만 배치한다. 왜: 품질 낮은 페이지가 동일 가중치로 처리되면 고품질 연구 콘텐츠의 인용 점수가 희석된다. 어떻게: priority: high 경로에 데이터 기반 아티클만 집중.

기법 6·7·8·9 — 정의 패턴·E-E-A-T·엔티티 밀도·외부 출처 인용

작동 원리

LLM은 파인튜닝 과정에서 "X는 Y이다" 형태의 정의 문장을 사실 저장 패턴으로 학습한다. RAG 인용 단계에서도 "X가 무엇인가" 쿼리에 대해 이 패턴을 포함하는 청크가 높은 관련성 점수를 받는다. 고유 엔티티(브랜드명·제품명·인명·연도)는 임베딩 공간에서 희소하므로, 동일 엔티티를 언급하는 쿼리와의 유사도가 집중적으로 높아진다.

구현 방법

• 각 섹션 첫 문장을 정의 패턴으로 시작한다. 왜: "AEO란?" 쿼리에 대해 "AEO(Answer Engine Optimization)는 AI 답변 엔진이 콘텐츠를 인용할 확률을 높이는 최적화 기법이다" 형태가 직접 인용 후보가 된다. 어떻게: 용어 → 영문 풀네임 → 한 문장 정의 순서 유지.
• 저자 정보를 <meta name="author">와 JSON-LD 양쪽에 중복 명시한다. 왜: E-E-A-T에서 저자 전문성이 재순위에 영향을 준다. 어떻게: 기관 소속·직함·발행 날짜를 Article 스키마에 포함.
• 외부 권위 출처를 인라인 하이퍼링크로 연결한다. 왜: 크롤러는 링크 그래프를 통해 콘텐츠의 근거 신뢰도를 평가한다. 어떻게: arXiv·PubMed·정부 보고서 URL을 앵커 텍스트에 논문 제목·저자·연도로 명시.
• 단락당 고유 엔티티 2~4개를 유지한다. 왜: 엔티티 과밀(6개 이상)은 임베딩 벡터를 분산시켜 특정 쿼리와의 유사도를 낮춘다(추정, 임베딩 모델에 따라 다름). 어떻게: 동의어 반복 대신 표준 명칭 하나를 일관되게 사용.

흔한 오해 — "콘텐츠가 길수록 인용될 가능성이 높다"

분량이 많은 글이 더 많은 정보를 포함하므로 인용 가능성이 높다는 직관은 RAG 파이프라인의 청킹 메커니즘을 이해하면 반례가 된다. RAG는 전체 문서가 아닌 청크 단위로 검색하고 인용한다. 5000자 분량의 글이라도 청크마다 맥락이 불완전하다면, 300자의 완결된 단락보다 인용 점수가 낮다.

올바른 처리법: 긴 글을 쓰더라도 각 H2 섹션을 독립 인용 가능한 단위로 설계한다. 섹션 첫 단락에서 정의·수치·결론을 모두 포함하고, 이후 단락은 보조 근거로 배치한다. 이 구조는 청크가 섹션 경계에서 잘려도 첫 단락이 독립적으로 인용될 수 있도록 보장한다.

참고 자료

이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.

• Google 검색 센터 — SEO 기본 가이드
• GEO: Generative Engine Optimization (arXiv 2311.09735)
• Google 검색의 AI 기능과 내 웹사이트