Naly 엔지니어링 노트: 지속 저장된 출처를 활용한 검색 증강 기사 작성

초록

검색 증강 생성은 Naly의 기사 파이프라인에 모델 가중치만으로는 얻기 어려운 더 최신이고 더 감사 가능한 연구 기억을 제공한다. 각 엔지니어링 노트나 시장 인텔리전스 기사 작업에서 시스템은 웹과 arXiv를 검색하고, 생성된 산출물과 함께 출처 URL을 보관하며, 모델에 먼저 답하게 한 뒤 결과를 HTML로 렌더링할 수 있다. 핵심은 자동화 자체가 아니라 독자가 추적할 수 있는 주장을 출판하는 것이다.

논지는 단순하다. 기사 작성용 RAG는 챗봇 패턴이 아니라 프로덕션 증거 시스템으로 다뤄야 한다. 챗봇의 약한 답변은 용서될 수 있지만, 출판된 기사는 오래 남는 신뢰 표면이 된다. 따라서 Naly의 구현에는 세 가지 불변 조건이 필요하다. 초안 작성 전 검색, 출판 이후에도 남는 출처 기록, 읽기 좋은 Markdown을 보존하면서 안전하지 않은 HTML을 피하는 렌더러다.

Naly 안에서의 위치

Naly 기사 작업은 연구 수집과 공개 출판 사이에 있다. 작업은 선택된 주제로 시작해 검색 의도를 생성하고, 웹과 arXiv 자료를 가져오며, 결과를 출처 기록으로 정규화한 다음, 그 제한된 증거 집합을 바탕으로 모델에 답변 우선 기사를 쓰게 한다. 출력은 단순한 산문이 아니다. Markdown 콘텐츠, 렌더링된 HTML, 출처 URL, 출처 제목, 출처 종류, 각 출처가 사용된 이유를 설명할 수 있는 충분한 메타데이터를 포함한 묶음이다.

이는 Naly의 신뢰 루프에 중요하다. Naly의 더 넓은 편집 태도는 다른 이들이 숨기는 것, 즉 의사결정 메모, 보정 한계, 실패, 주장 뒤의 증거를 공개하는 것이다. 출처 기반 생성은 그 태도를 운영 가능하게 만든다. 독자는 어떤 진술이 모델의 학습 데이터, 공식 문서, 논문, 운영자 주장 중 어디에서 왔는지 추측할 필요가 없어야 한다.

RAG 계층은 초안 작성 이후가 아니라 이전에 있어야 한다. 사후에 인용을 붙이는 방식은 모델이 이미 주장을 형성한 뒤이기 때문에 더 약하다. 더 강한 설계에서는 검색이 생성 맥락을 제한하고, 생성은 검색된 집합과 대조해 확인할 수 있는 주장을 만들어낸다. 보이는 기사는 간결하게 유지할 수 있지만, 저장된 산출물은 연구 흔적을 보존해야 한다.

기술적 메커니즘

기사 작성에서 Naly의 RAG 흐름은 배치 파이프라인이다.

주제 선택은 검색 증강 생성이 출처 기반 기사 작성을 어떻게 근거화하는지와 같은 제한된 연구 질문을 만든다.
쿼리 계획은 그 질문을 웹 쿼리, 공식 문서 쿼리, arXiv 쿼리로 확장한다.
검색은 공식 문서, 주요 논문, 신호가 높은 설명 출처를 수집한다.
정규화는 제목, 표준 URL, 출처 종류, 이용 가능한 경우 출판 또는 업데이트 맥락, 관련 스니펫이나 초록을 추출한다.
출처 지속 저장은 나중에 기사를 감사할 수 있도록 생성 전에 URL 장부를 저장한다.
프롬프트 조립은 모델에 주제, Naly 고유의 구현 사실, 작성 제약, 검색된 증거를 제공한다.
생성은 답변 우선 초록, 명시적 실패 모드, 참고문헌 섹션을 포함한 Markdown을 만든다.
검증은 렌더링된 기사 안의 모든 참고문헌이 저장된 출처 객체에 매핑되는지 확인한다.
렌더링은 살균 처리와 프로덕션 검사를 적용하면서 사이트용으로 Markdown을 HTML로 변환한다.

이는 Vercel의 RAG 가이드에서 설명하는 검색 및 증강 생성 패턴과 가깝다. 먼저 관련 맥락을 검색한 뒤, 생성 전에 이를 사용자 또는 작업 질문과 결합하는 방식이다. 차이는 Naly가 대화형 지원을 최적화하지 않는다는 점이다. Naly는 출처 URL이 기사의 데이터 모델 일부가 되는 지속 가능한 출판을 최적화한다.

AI SDK는 이런 종류의 작업에 자연스러운 오케스트레이션 계층이다. 텍스트 생성 인터페이스가 비대화형 자동화, 도구 호출, 다단계 결과, 그리고 제공자가 URL 출처를 반환할 때의 출처 메타데이터를 지원하기 때문이다. 제공자가 네이티브 출처 객체를 반환하지 않는 경우에도 Naly는 자체 검색 출처 목록을 기사 산출물에 붙이고, 모델 네이티브 출처는 권위 있는 근거가 아니라 보조 자료로 취급할 수 있다.

문헌이 말하는 것

Lewis et al.의 원래 RAG 정식화는 핵심 문제를 잘 짚었다. 파라메트릭 언어 모델은 사실을 가중치에 저장하지만, 그 지식을 업데이트하고 출처를 제공하는 일은 여전히 어렵다. 그들의 검색 증강 모델은 시퀀스 모델과 밀집 벡터 인덱스를 결합했고, 지식 집약적 과제에서 파라메트릭 전용 기준선보다 더 구체적이고 다양하며 사실적인 생성을 보였다.

Gao et al.의 이후 RAG 서베이는 그 아이디어를 naive RAG, advanced RAG, modular RAG라는 분류 체계로 일반화한다. Naly의 기사 파이프라인은 모듈형이어야 한다. 검색, 순위화, 출처 지속 저장, 프롬프트 구성, 생성, 참고문헌 검증, 렌더링은 각각 별도의 실패 모드를 가진 별도 단위다. 이를 별도 단위로 다루면 기사가 약한 출처를 인용하거나 더 나은 출처를 놓쳤을 때 시스템을 더 쉽게 디버그할 수 있다.

Self-RAG는 중요한 주의를 더한다. Asai et al.은 검색이 필요한지 여부와 관계없이 고정된 수의 구절을 검색하면 출력 품질이 저하될 수 있다고 주장한다. Naly에게 이는 top-k 검색이 의식처럼 고정되어서는 안 된다는 뜻이다. 안정적인 프레임워크 기능에 관한 짧은 기사는 공식 문서와 논문 한 편이면 충분할 수 있고, 문헌 중심 기사는 여러 arXiv 출처와 서베이가 필요할 수 있다. 검색 깊이는 주장 위험을 따라야 한다.

RAGChecker는 평가상의 교훈을 제공한다. Ru et al.은 RAG 시스템이 특히 장문 응답에서 검색과 생성 전반에 걸친 세밀한 진단을 필요로 한다고 주장한다. Naly에서 평가 단위는 기사 품질만이어서는 안 된다. 검색 재현율, 출처 관련성, 주장 근거, 참고문헌 포괄성, 그리고 근거 없는 주장이 최종 Markdown에 섞여 들어갔는지를 포함해야 한다.

설계 트레이드오프

높은 재현율과 낮은 잡음 사이의 균형이 핵심 트레이드오프다. 더 많은 검색은 올바른 출처를 찾을 가능성을 높이지만, 약한 스니펫이 프롬프트에 들어가 모델을 유도할 가능성도 키운다. Naly는 넓은 수집, 엄격한 필터링, 압축된 프롬프트 맥락으로 이어지는 단계적 접근을 선호해야 한다.

출처 지속 저장은 감사 가능성을 높이지만, 저장과 유지보수 작업도 만든다. URL은 변하고, 논문은 개정되며, 문서 페이지는 이동한다. 지속 가능한 기록에는 표준 URL, 가져온 시각, 제목, 출처 유형, 그리고 가능하다면 콘텐츠 다이제스트나 발췌 경계가 포함되어야 한다. 그래야 Naly가 모델 오류와 변경된 출처를 구분할 수 있다.

답변 우선 글쓰기는 독자 가치를 높이지만, 불확실성을 지나치게 압축할 수도 있다. 기사는 결론으로 시작하되, 뒤쪽 섹션에는 실패 모드와 주의사항을 보존해야 한다. 답변 우선 요약은 진입점이지, 증거를 납작하게 만드는 허가가 아니다.

렌더링된 HTML은 배포와 읽기 경험을 개선하지만 보안 경계를 만든다. Marked는 Markdown 파싱에 빠르고 유용하지만, 문서에서 출력 HTML을 살균하지 않는다고 명시적으로 경고한다. Naly 기사 렌더러는 생성된 HTML을 살균하고, 재생을 위해 신뢰할 수 있는 Markdown 원본을 유지해야 한다.

실패 모드

검색 누락: 검색 단계가 그럴듯하지만 불완전한 출처를 찾는 경우다. 이는 보통 쿼리 플래너가 너무 좁거나 문헌에서 쓰는 표현과 다른 제품 용어를 사용할 때 발생한다. 완화책: 여러 쿼리 스타일을 사용하고, 공식 문서를 포함하며, 기사가 연구 주장을 할 때 최소 두 개의 주요 출처 또는 arXiv 출처를 요구한다.

인용 세탁: 출처가 참고문헌에 나타나지만 실제로는 그 근처 문장을 뒷받침하지 않는 경우다. 이는 거짓 확신을 만들기 때문에 인용이 없는 것보다 더 나쁘다. 완화책: 출처 스니펫과 대조해 주장을 검증하고, 참고문헌이 단지 주제상 관련만 있을 뿐인 기사는 거부한다.

오래된 출처 드리프트: 공식 문서 페이지가 출판 후 변경되는 경우다. 완화책: 생성 시점의 출처 메타데이터를 지속 저장하고 날짜 라벨을 기록한다. 주요 주장을 좌우하는 출처는 라이선스가 허용하는 경우 스냅샷이나 다이제스트를 저장한다.

과잉 검색: 너무 많은 청크가 모델로 하여금 기사 논지에 답하기보다 맥락을 요약하게 만드는 경우다. 완화책: 출처 순위화를 사용하고, 거의 동일한 문서를 중복 제거하며, 프롬프트 증거를 원시 개수가 아니라 주장 관련성 기준으로 제한한다.

맥락 오염: 스팸 페이지, 생성된 SEO 페이지, 저품질 요약이 주요 자료보다 높은 순위를 차지하는 경우다. 완화책: 기사가 명시적으로 업계 반응을 다루는 경우가 아니라면 공식 문서, arXiv, 표준, 소스 저장소를 2차 논평보다 높게 순위화한다.

렌더러 위험: 생성된 Markdown에 원시 HTML, 안전하지 않은 링크, 잘못 형성된 표가 포함될 수 있다. 완화책: 렌더링된 HTML을 살균하고, 링크를 정규화하며, 스크립트 실행 가능 콘텐츠를 거부하고, 성능, 보안, 메타데이터, 접근성에 관한 Next.js 지침과 일관된 프로덕션 검사를 실행한다.

구현 메모

Naly의 현재 런타임 사실을 기준으로 보면, 깔끔한 아키텍처는 다음을 사용하는 TypeScript 작업이다. ai@6.0.0-beta.105 모델 오케스트레이션에는, 증거 수집에는 웹 및 arXiv 검색 도구, 기사 및 출처 기록에는 Neon과 함께 Drizzle ORM을 사용하고, marked@17.0.1 Markdown-to-HTML 렌더링에는, 게시 표면에는 Next.js 16을 사용한다.

데이터베이스는 출처를 Markdown 텍스트 덩어리가 아니라 일급 행으로 취급해야 한다. 실용적인 스키마는 기사 테이블, 기사-출처 조인 테이블, 그리고 URL, 제목, 출처 종류, 검색 시각, 이용 가능한 경우 arXiv ID 같은 표준 식별자, 추출 상태를 담는 출처 필드를 가진다. 그러면 기사 기록은 Markdown, 렌더링된 HTML, 요약, 핵심 포인트, 출판 메타데이터를 가리킬 수 있다.

Vercel Blob은 더 큰 산출물이나 불변 렌더링 출력에 유용한 반면, Postgres는 출처와 기사 메타데이터를 조회 가능한 장부로 유지하는 데 더 적합하다. 이 분리는 감사 쿼리를 저렴하게 만든다. 어떤 출처를 사용한 모든 기사, 어떤 기사에 사용된 모든 출처, 출처 추출에 실패한 모든 기사를 나열할 수 있다.

생성기 프롬프트는 출력 형태에서 출처 규율을 요구해야 한다. 근거 없는 주장 금지, 만들어낸 URL 금지, 링크가 지속 저장된 출처 목록과 일치해야 하는 참고문헌 섹션이 그것이다. 모델은 유려한 산문을 쓸 수 있지만, 작업은 출처의 진실성을 소유해야 한다. 모델이 검색되지 않은 참고문헌을 내보내면 검증기는 조용히 출판하지 말고 기사를 실패 처리해야 한다.

마지막으로, 프로덕션 동작이 중요하다. Next.js는 이미 서버 컴포넌트, 코드 분할, 사전 렌더링, 캐싱 기본값을 제공하지만, 생성 콘텐츠 파이프라인에는 여전히 명시적인 오류 처리, 보안 검사, 메타데이터, Core Web Vitals 인식이 필요하다. RAG는 Naly가 증거를 바탕으로 글을 쓰도록 돕는다. 프로덕션 엔지니어링은 그 증거가 독자에게 빠르고 안전하며 반복적으로 도달하도록 보장한다.

초록