Accept 헤더로 AI 에이전트에게 Markdown 제공하기
Serve Markdown to AI Agents with Accept Headers
웹사이트는 이미 콘텐츠를 가지고 있습니다. Markdown 변형을 제공하면 AI 에이전트 클라이언트가 탐색, 스크립트, 레이아웃 마크업을 건너뛰고 콘텐츠를 직접 읽을 수 있습니다. 이 접근 방식은 토큰 수를 줄이고, 검색 품질을 높이며, 지연 시간을 개선합니다. 이 사이트는 URL이 `Accept: text/markdown`을 지원하는지 확인하는 도구와 함께, `Vary` 헤더, `406` 응답, `q` 값 처리 등 구현 가이드와 레시피를 제공합니다.
에이전트는 당신의 DOM이 아닌 당신의 산문에 컨텍스트를 사용합니다.
HN 토론
71- k1m
Roy Fielding의 의견에 동의합니다:
> 모든 요청에 사용자의 선호 가능한 변형을 모두 알려주기 위해 헤더 필드 뭉치를 보내는 것은 나쁜 설계 트레이드오프입니다. 특히 그 차원들 중 어떤 것이 대상 리소스에 적용될 가능성이 매우 낮을 때 더욱 그렇습니다. 1993-94년의 아주 짧은 기간, 사람들이 어떤 이미지 형식이 모든 UA에서 사용 가능한지 몰랐고 클라이언트 측 적응을 위한 CSS나 자바스크립트도 없었을 때부터 나쁜 설계 트레이드오프였습니다.
> ...사전 협상의 캐싱 영향은 사이트당 한 번의 추가 왕복을 필요로 하는 반응 협상보다 훨씬 더 나쁩니다. 그리고 클라이언트 측 적응을 지원하는 형식에서는 그 왕복조차 필요하지 않습니다.
캐싱 영향에 대해 Simon Willison은 이렇게 썼습니다:
> ...Cloudflare CDN 뒤에서 Accept 헤더를 통한 콘텐츠 협상을 사용하는 애플리케이션을 배포할 수 없습니다. 예를 들어 들어오는 Accept 헤더에 따라 같은 URL에 대해 JSON 또는 HTML을 제공하는 경우입니다. 그렇게 하면 Cloudflare가 HTML 클라이언트에게 캐시된 JSON을 제공하거나 그 반대가 될 수 있습니다.
참고: 저는 이 내용을 다른 댓글에 두 인용문에 대한 링크와 함께 올렸는데, 지금은 쉽게 복사할 수 없어서 나중에 추가하겠습니다.
- joshum97
제가 미친 건가 싶네요. 정신이 멀쩡한 사람이 누가 LLM에게 원시 HTML을 먹이겠어요??
HTML은 마크업 언어입니다. 사용자 에이전트는 사용자에게 의미 있는 방식으로, 즉 시각적으로 또는 보조 기술을 통해 이를 제시합니다. LLM '사용자'를 추가한다고 해서 이것이 바뀌어서는 안 됩니다. 그들의 사용자 에이전트, 즉 하네스가 HTML을 Markdown으로 변환하여 그들이 원래 이해할 수 있는 방식으로 제시해야 합니다.
하네스 개발자들이 npm에서 HTML-to-markdown 패키지를 가져오기 너무 게으르거나 멍청해서 웹 전체를 다시 쓰지는 않을 것입니다. 어떤 사이트가 어쨌든 그렇게 하기를 원한다면 잘된 일입니다. 많은 경우 저는 CSS/JS를 건너뛰고 마크다운을 직접 읽고 싶습니다(또는 더 좋게는, 예쁘게 포맷된 것을). 하지만 하네스가 토큰을 낭비하는 것을 웹사이트 작성자 탓으로 돌리지 마세요.
- lekevicius
상위 4개 AI 챗봇 중 하나라도 이 헤더로 요청을 보내겠다고 하면 그렇게 하겠습니다. 그 전에는 그냥 채택이 없는 멋진 아이디어일 뿐입니다.
또한 상위 4개 챗봇 중 어떤 것이 이 방식으로 웹사이트를 로드하도록 선택할 가능성은 극히 낮다고 생각합니다. 몇 년 후에도 채택률이 0.01%에 불과할 위험이 너무 많습니다.
- collimarco
깨끗하고 의미론적인 HTML은 어떻습니까?
그것은 이미 봇과 검색 엔진(봇이기도 한)을 위해 최적화되어 있었고 수십 년 동안 사용되어 왔습니다. 왜 지금 마크다운으로 제공해야 합니까?
또한 네비게이션과 같은 HTML의 많은 부분은 봇과 AI에게 유용하며 마크다운 버전에서는 제거될 수 있습니다.
- kaangiray26
이것이 주류가 되기를 바랍니다. 그러면 광고, JS, 블로트 없이 페이지를 그냥 볼 수 있게 되니까요.