사내 RAG는 근거를 먼저 넣고, 모자랄 때만 찾으러 보내십시오 — 질문 50개에서 원천 90%를 맞히며 AI 호출을 43% 줄인 배달 설계

PART 01 · Frame근거를 건네는 길은 두 가지입니다

미리 넣기는 하네스의 일입니다. Claude Code 같은 에이전트 도구는 사용자가 프롬프트를 보내는 순간 정해 둔 스크립트(훅)를 실행할 수 있습니다. 이 훅이 사내 문서 색인을 뒤져 관련 근거를 프롬프트 옆에 붙입니다. 대규모 언어 모델(LLM)은 생각을 시작하기 전에 이미 근거를 들고 있습니다.

찾으러 가기는 에이전트의 일입니다. 모델이 생각하다가 근거가 필요하다고 판단하면 검색 도구를 부르고, 결과를 읽고, 모자라면 질의를 고쳐 다시 부릅니다. 입구 글에서 다룬 ‘다시 찾는 고리’가 이것입니다. 추론 중간에 키워드 검색을 끼워 넣은 IRCoT(Trivedi 외, 2023)와 검색이 필요한지 모델이 스스로 판단하는 Self-RAG(Asai 외, 2023)가 이 길의 연구 원형입니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

표의 마지막 줄이 이 글의 질문입니다. 두 길은 서로 다른 모습으로 실패합니다. 그렇다면 어떤 입력을 어느 길로 보내야 할까요.

PART 02 · Push미리 넣기는 프롬프트의 2~3%에만 들어갔습니다

Sillok의 미리 넣기 훅은 여섯 단계로 움직입니다.

1. 앵커 판정: 프롬프트에 그 인스턴스의 도메인 낱말(앵커)이 있는지 봅니다. 1,500자가 넘거나 낱말이 너무 적으면 색인을 열지 않습니다.
2. 검색: 키워드 검색(BM25)으로 원문 조각과 용어집에서 상위 4건을 뽑습니다.
3. 충분성 판정: 1위 점수가 8.0 이상이고 질의 낱말의 절반 이상을 덮을 때만 넣습니다.
4. 주입: 인용 표기를 붙인 근거를 1,800자 안에서 넣습니다.
5. 나눠 쓰기: 여러 인스턴스가 함께 근거를 내면 총 3,600자를 고르게 나눕니다.
6. 시간 제한: 5초 안에 답하지 못한 인스턴스는 버립니다.

엔진은 이 판정을 프롬프트마다 기록합니다. PMI 표준 인스턴스의 기록을 보면 이렇습니다. 2026년 9월 21일부터 11월 3일까지 훅이 본 프롬프트는 2,359건이었습니다.

프롬프트의 56%는 앵커가 없어 색인을 열지 않았습니다. 22%는 1,500자를 넘었고, 15%는 낱말이 너무 적었습니다. 앵커를 통과한 150건 가운데서도 충분성 판정을 넘은 것은 42건이었습니다. 여기에 사용자가 태그로 강제한 24건을 더해 주입은 모두 66건, 프롬프트의 2.8%였습니다. 공공 정보화사업 법령 인스턴스는 1.9%, 공공 AX 안내서 인스턴스는 2.0%였습니다.

이 숫자는 미리 넣기의 첫 번째 장점을 보여 줍니다. 무관한 프롬프트에는 비용이 거의 들지 않습니다. 코드 수정이나 일정 정리를 시킬 때 법령 조문이 끼어들지 않습니다.

이 비율을 그대로 옮기면 안 됩니다. 제 세션은 대부분 RAG와 무관한 작업이고, 분모에는 시험 프롬프트도 섞여 있습니다. 질문 전용 비서라면 거의 모든 입력이 도메인 질문입니다. 뒤의 실험에서도 질문형 입력은 70%에 근거가 들어갔습니다. 자기 조직의 비용은 ‘주입률 × 평균 주입 글자 수’로 먼저 어림해 보시기 바랍니다.

근거가 들어갈 때 여러 인스턴스가 함께 내는 일은 적지 않았습니다. 전역 주입 기록(9월 8일~11월 2일) 118건 가운데 인스턴스 1개가 85건, 2개가 25건, 3개가 5건, 4개가 3건이었습니다. 넷 중 한 건꼴(28%)은 둘 이상이 함께 냈으니, 나눠 쓰기의 손실을 따져 봐야 합니다.

PART 03 · Budget넣는 양은 1,800자에서 포화했습니다

그렇다면 한 번에 얼마나 넣어야 할까요. 많이 넣을수록 좋다면 상한을 올리면 됩니다. 하지만 넣은 글자는 매 프롬프트의 토큰 비용이 되고, 모델이 읽어야 할 잡음도 됩니다.

평가 질문 90개로 상한만 바꿔 가며 재 보았습니다. 질문은 세 인스턴스의 평가셋입니다. 사전과 위키를 다듬을 때 보지 않은 보류 질문 70개와 PMI 질문 20개입니다. 이 가운데 72개에 근거가 들어갔고, 그 주입문 안에 정답 원천이 들어 있는 비율을 셌습니다. AI 모델은 쓰지 않았습니다.

300자에서는 12%였습니다. 조각 하나도 다 담지 못하는 상한입니다. 600자에서 82%로 뛰었고, 1,200자에서 92%, 1,800자에서 96%였습니다. 상한을 3,600자로 두 배 늘려도 96%로 같았습니다. 상위 4건만 넣기 때문입니다. 상위 8건으로 늘리고 3,600자를 쓰면 99%가 되지만, 실제로 넣는 글자도 약 두 배가 됩니다.

이 포화점은 제 문서의 조각 길이에서 나온 값입니다. 상위 4건이 실제로 차지한 글자는 1,400~1,800자, 조각 하나에 350~450자였습니다. 상한은 ‘넣을 건수 × 평균 조각 길이’로 잡고, 자기 문서로 이 곡선을 다시 그려 확인해야 합니다.

지금 Sillok의 설정인 인스턴스당 1,800자, 총 3,600자는 이 곡선의 어깨에 놓여 있습니다. 여러 인스턴스가 함께 내면 총 3,600자를 나눕니다. 짧게 낸 쪽이 남긴 글자는 긴 쪽이 더 씁니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

넷이 함께 내도 잃는 몫은 7%포인트 안쪽으로 어림됩니다. 다만 포함률은 인스턴스 하나씩 잰 값이고, 여러 인스턴스가 동시에 넣은 경우를 따로 재지는 않았습니다.

PART 04 · Experiment넣으면 정확했지만, 넣지 못한 빈칸이 많았습니다

이제 두 길을 정면으로 비교했습니다. 입력은 두 종류입니다.

• 질문형 50개: 공공 정보화사업 법령과 공공 AX 안내서의 보류 질문을 25개씩 뽑았습니다. “감리원이 되려면 어떤 자격과 교육이 필요한가요”처럼 사람이 묻는 문장입니다.
• 문장형 50개: 입구 글에서 쓴 봉인 문장입니다. 실제 공공 사업 문서에서 떼어 와, 사전과 위키를 다듬을 때 한 번도 보지 않도록 따로 둔 문장입니다. 문장을 주고 근거 조항을 찾게 합니다.

조건은 셋입니다.

1. 미리 넣기: 훅과 같은 규칙으로 근거를 넣고, AI가 그 근거만 읽고 원천과 위치를 답하거나 ‘근거 부족’이라고 답합니다.
2. 찾으러 가기: AI가 검색·전문 검색·원천 목록·원문 읽기 도구를 최대 5번 씁니다.
3. 먼저 넣고, 모자라면 찾으러 가기: 미리 넣기가 ‘근거 부족’이면 찾으러 가기로 넘깁니다.

AI는 Claude Sonnet 5.5이고, 제 개인 설정을 끈 상태로 불렀습니다. 채점 기준은 이렇습니다.

• 원천 적중: 답이 가리킨 문서가 정답 문서와 같습니다. 위치까지 적중은 쪽·조까지 같습니다.
• 틀린 답: ‘근거 부족’이 아닌데 원천이 틀렸습니다.
• AI 호출: 모델을 부른 횟수입니다. 미리 넣기에서 근거가 들어가지 않은 입력은 AI를 부르지 않고 ‘근거 부족'(0회)으로 셉니다.

표의 †는 입구 글의 실험값입니다. 같은 문장과 같은 모델로 앞서 잰 결과를 그대로 썼습니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

질문형에서 미리 넣기는 근거가 들어가기만 하면 대체로 맞혔습니다. 근거가 들어간 질문 35개 가운데 30개에서 정답 원천을 맞혔고, 3개는 틀렸고 2개는 근거 부족이었습니다. 표의 틀린 답 6%는 50개 전체가 분모라서, 답을 미룬 17개만큼 낮게 보입니다. 답을 낸 33개로 보면 3개, 약 9%로 찾으러 가기의 8%와 비슷합니다. 문제는 빈칸이었습니다. 질문의 30%에는 아무것도 들어가지 않았습니다. 표의 근거 부족 34%는 이 15개에, 근거가 들어갔지만 부족하다고 답한 2개를 더한 값입니다.

빈칸의 원인은 대부분 앵커 판정이었습니다. 공공 AX 안내서의 보류 질문 30개 가운데 16개가 앵커 없음으로 걸러졌습니다. 같은 질문을 앵커 판정 없이 검색하면 30개 모두 주입문에 정답 원천이 들어 있었습니다. 색인이 아니라 문지기 낱말 목록이 병목이었습니다.

찾으러 가기는 넓었습니다. 질문형 원천 적중이 92%였고, 미리 넣기만 맞힌 질문은 1개, 찾으러 가기만 맞힌 질문은 17개였습니다. 대신 AI 호출이 질문당 3.5회, 시간이 약 26초였습니다.

둘을 이으면 이 차이가 대부분 메워졌습니다. 질문의 34%만 찾으러 가기로 넘어갔고, 원천 적중은 90%였습니다. AI 호출은 2.0회로 찾으러 가기만 쓸 때보다 43% 적었고, 시간은 약 14초로 절반 수준이었습니다.

다만 위치까지 맞힌 비율은 74%로, 찾으러 가기만 쓴 82%보다 8%포인트 낮았습니다. 미리 넣은 근거로 답할 때는 원문을 다시 열어 쪽·조를 대조하지 않기 때문으로 보입니다. 아래 붙여 넣기 규칙 4는 이 손실을 호출 한 번과 바꾸는 선택입니다.

문장형은 전혀 다른 모습이었습니다. 문장 50개 가운데 23개(46%)에 근거가 들어갔지만, 주입문에 정답 원천이 든 문장은 5개였습니다. 주입된 문장의 22%입니다. 문장의 낱말이 법령 쪽 낱말과 어긋나 엉뚱한 근거가 들어간 것으로 보입니다. 미리 넣기를 먼저 거쳐도 76%가 찾으러 가기로 넘어갔고, 호출은 9%만 줄었습니다.

점수만 보면 찾으러 가기 54%와 혼합 50%는 2문장 차이입니다. 이 표본으로는 가를 수 없는 크기입니다. 그래도 문장형을 처음부터 찾으러 보내자는 이유는 위험 쪽에 있습니다. 미리 넣은 엉뚱한 근거를 믿고 AI가 ‘근거 부족’ 없이 틀린 문장이 7개(14%)였고, 그중 3개는 찾으러 가기였다면 맞혔습니다. 엉뚱한 근거는 ‘근거 부족’ 신호를 지워, 다음 길로 넘어갈 기회를 막습니다.

PART 05 · Rule그래서 입력에 따라 길을 나눴습니다

실험이 가리키는 규칙은 단순합니다.

1. 도메인 낱말이 분명한 질문은 먼저 넣습니다. 넣은 근거로 답할 수 있으면 그대로 답하고, 인용을 붙입니다. 왕복이 늘지 않습니다.
2. 넣은 근거로 답할 수 없으면 찾으러 보냅니다. ‘근거 부족’을 실패가 아니라 다음 길로 넘기는 신호로 씁니다.
3. 문서 문장·붙여 넣은 자료·간접 질문은 처음부터 찾으러 보냅니다. 미리 넣어 봐야 엉뚱한 근거가 들어가기 쉽습니다.
4. 넣는 양은 인스턴스당 1,800자, 상위 4건으로 시작합니다. 그 이상은 글자 대비 얻는 몫이 작았습니다. 자기 문서의 조각 길이로 곡선을 다시 그려 확인합니다.
5. 앵커 낱말 목록을 평가셋으로 점검합니다. 빈칸의 대부분은 문지기 목록에서 생겼습니다.

입력을 고르는 일은 질문의 복잡도에 따라 검색 경로를 고르는 Adaptive-RAG(Jeong 외, 2024)와 같은 방향입니다. 차이는 분류기를 학습시키지 않고, 훅 규칙과 지침 한 줄로 나눴다는 점입니다. 질문형과 문장형은 다음 신호로 가르자고 제안합니다. 시험하지 않은 설계안이고, 표의 예시 문장은 설명을 위해 지어낸 것입니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

지금 Sillok 훅은 이 판별을 하지 않습니다. 1,500자가 넘는 붙여 넣기를 걸러 낼 뿐입니다. 그래서 짧은 문장형 입력의 판별은 지침으로 모델에게 맡깁니다(아래 붙여 넣기 규칙 1).

앵커 점검은 이렇게 합니다. 평가 질문을 앵커 판정에만 통과시켜 통과율을 재고, 걸러진 질문의 낱말을 목록에 더합니다. 산출물은 통과율 표와 보강한 낱말 목록이고, 그 RAG를 운영하는 사람이 맡습니다. 앵커 판정은 무관한 프롬프트에 색인을 열지 않는 문지기라서, 없애기보다 목록을 보강하는 쪽을 택했습니다.

이 가운데 1·4번은 지금 Sillok 훅이 하는 일입니다. 2·5번은 이번 실험으로 확인한 보완점이고, 3번의 판별 신호는 설계안이라 시험하지 않았습니다. 아직 훅에 반영하지 않았습니다.

훅 쪽 설정과 에이전트 쪽 지침을 나란히 적으면 이렇습니다. 앞의 것은 Sillok의 현재 값이고, 뒤의 것은 지침 파일에 그대로 붙여 넣을 수 있는 문장입니다.

[훅 설정 — Sillok 현재 값]
제외      : 1,500자 초과 · 낱말 2개 미만 · 인스턴스의 앵커 낱말 없음
주입 조건 : BM25 1위 점수 8.0 이상 · 질의 낱말의 절반 이상을 덮음
양        : 상위 4건 · 인스턴스당 1,800자 · 여러 인스턴스면 총 3,600자를 고르게
시간      : 인스턴스마다 5초 안에 답하지 못하면 버림

[근거 배달 규칙 — 지침 파일에 붙여 넣기 · 위에서부터 적용]
1. 입력이 문서에서 붙여 넣은 문장이거나 서술·지시 어미로 끝나면, 주입된 근거가 있어도 믿지 말고 처음부터 검색한다.
2. 그 밖의 질문은 주입된 근거로 먼저 답하고, 주장마다 인용을 붙인다.
3. 주입된 근거로 답할 수 없으면 "근거 부족"이라고 적고, 검색 도구로 다시 찾는다(최대 5회).
4. 쪽·조·항을 인용해야 하면, 주입된 근거든 찾은 근거든 원문을 열어 위치를 대조한 뒤 인용한다(호출 1회 추가).

PART 06 · Field크린앤사이언스 사내 RAG도 근거를 한 길로 몰지 않았습니다

필터 미디어를 만드는 코스닥 상장사 크린앤사이언스와 2026년 6월부터 사내 RAG를 함께 만들었습니다. 고객 동의를 받아 설계 결정만 옮깁니다. 이 글의 미리 넣기 분기를 그대로 적용한 사례는 아니고, 검색과 회수, 응답 길이 쪽의 결정입니다. 사내 시스템 이름과 문서 수, 사용 기록 같은 수치는 싣지 않습니다.

첫째, 검색 방식부터 둘을 함께 썼습니다. 제품 코드, 특허 번호, 금액, 날짜 같은 업무어는 낱말이 그대로 맞아야 해서 키워드 검색(BM25)이 강했습니다. 표현이 다른 질문은 다국어 의미 검색이 받쳤고, 두 결과는 역순위 융합(RRF)으로 합쳤습니다.

둘째, 한 번 검색으로는 닿지 않는 근거가 있었습니다. 업무 기록에 딸린 첨부 문서는 수많은 기록 조각에 밀려 직접 검색 상위에 잘 오르지 않았습니다. 그래서 첨부는 검색어를 바꿔 다시 찾기보다, 먼저 찾은 기록에서 첨부로 이어진 연결을 따라가는 길을 권장 회수 경로로 정했습니다. 이 글의 ‘찾으러 가기’를 어디로 보낼지 정한 셈입니다.

셋째, 건네는 양을 줄였습니다. 10월에 사내 AI 연결 서버, 곧 모델 컨텍스트 프로토콜(MCP) 서버의 검색 응답을 점검하니 결과 몇 건만 받아도 같은 발췌가 되풀이됐습니다. 그래서 기본 응답을 근거와 기준일, 열람 링크 위주의 짧은 형식으로 바꾸고, 점수 근거가 필요할 때만 자세한 형식을 부르게 했습니다. 얼마나 넣을지라는, 이 글의 상한 논의와 같은 질문에 대한 결정입니다.

PART 07 · Harness하네스와 RAG는 같은 왕복을 나눠 씁니다

짝을 이루는 하네스 편 「AI 에이전트가 느리다는 불만, 모델보다 왕복 수부터 세십시오」는 20분 넘게 걸린 턴이 평균 92번 모델을 오갔다고 적었습니다. 근거도 왕복을 씁니다. 찾으러 가기는 검색 한 번, 읽기 한 번마다 왕복을 하나씩 늘립니다. 이번 실험에서도 질문 하나에 AI 호출 3.5회, 약 26초가 들었습니다. 미리 넣기는 그 왕복을 프롬프트가 들어오기 전 하네스 쪽으로 옮깁니다.

토큰은 이번 실험에서 재지 않았습니다. 많이 찾을수록 정확해지는 경향은 다른 연구에서도 보입니다. Anthropic은 다중 에이전트 연구 시스템을 웹 탐색 평가로 재 보니, 성능 차이의 80%를 토큰 사용량이 설명했다고 밝혔습니다. 다른 짝 편 「AI 에이전트 비용은 토큰 총량이 아니라 성공 작업당 비용으로 봅니다」는 줄일 후보를 같은 세션 30분 안에 이미 보낸 내용을 다시 싣는 문맥(22.4%)에서 찾았습니다. 미리 넣기에도 같은 위험이 있습니다. 지금 Sillok 훅은 같은 세션에 같은 근거를 다시 넣는지 확인하지 않습니다.

그래서 기업 RAG를 설계할 때는 검색 엔진보다 먼저 이 두 가지를 하네스에 적어 두는 편이 좋습니다. 어떤 입력에 근거를 미리 넣을지, 그리고 넣은 근거가 모자랄 때 에이전트에게 무엇을 시킬지입니다. 앞의 것은 훅의 앵커와 상한이고, 뒤의 것은 지침 파일의 한 줄입니다. “주입된 근거로 답할 수 없으면 검색 도구로 다시 찾는다.”

PART 08 · Limits이 실험이 말하지 못하는 것

• 표본이 작습니다: 입력 종류마다 50개, 조건마다 한 번씩, 모델 하나로 돌렸습니다.
• 미리 넣기를 따로 떼어 쟀습니다: 실제 훅은 대화 맥락이 있는 세션에 근거를 넣습니다. 실험의 AI는 근거만 보고 답했으므로, 실제 세션의 답 품질과는 다를 수 있습니다.
• 질문형은 제가 쓴 평가 질문입니다: 앵커 목록도 같은 도메인을 보고 만들었습니다. 다른 조직의 질문에서는 빈칸의 비율이 달라질 수 있습니다.
• 판정 기록의 분모는 범용 작업 세션입니다: 시험 프롬프트도 섞여 있습니다. 주입률은 대략의 규모로 읽어 주십시오.
• 문장형은 검색을 한 조건에서 틀린 답이 절반 가까이였습니다: 찾으러 가기 46%, 넣고 모자라면 찾기 50%입니다. 미리 넣기는 틀린 답이 14%였지만 76%에서 근거 부족으로 답을 미뤘습니다. 문서 문장의 근거 찾기는 이 방식으로도 사람이 원문을 대조해야 합니다.
• 문장형 판별은 시험하지 않았습니다: 신호표는 설계안입니다. 지침만으로 모델이 문장형을 가려내는지, 사람이 치는 ‘~해 주세요’ 같은 질문까지 문장형으로 보내지는 않는지는 재지 않았습니다.
• 최종 답의 질은 재지 않았습니다: 이번 실험의 채점은 근거의 원천과 위치까지입니다.
• 평가셋과 판정 기록은 공개하지 않습니다: 질문은 본문 예시와 같은 형식이고, 비율마다 분자와 분모를 본문에 적었습니다.

PART 09 · Closing세 줄로 다시, 그리고 이번 주에 할 일

미리 넣기는 빠르고 넣은 질문은 대체로 맞혔지만, 질문형 입력의 30%에는 넣지 못했습니다.

먼저 넣고 모자라면 찾게 하자, 질문형에서 호출 3.5회를 2.0회로 줄이며 원천 90%를 맞혔습니다.

문서 문장 같은 간접 입력은 처음부터 찾으러 보내고, 넣는 양은 1,800자에서 시작해 자기 문서로 확인합니다.

이번 주에는 사내 RAG나 AI 앱의 지식 기능에 질문 10개와 문서 문장 10개를 넣어 보시기 바랍니다. 검색 도구를 끈 측정 모드로 두고, 지침에 “붙은 근거만으로 답할 수 없으면 ‘근거 부족’이라고만 답해”라는 한 줄을 넣습니다. 입력별로 정답 원천을 먼저 표시해 두고, 미리 넣은 근거만으로 풀린 수와 근거 부족, 근거 부족 없이 틀린 답을 따로 셉니다. 제 실험에서 풀린 수는 질문형이 10개 중 6개, 문장형이 1개꼴이었습니다. 근거 부족 없이 틀린 답이 하나라도 있고 풀린 수가 10개 중 3개 이하인 입력군은 처음부터 찾으러 보냅니다. 이 기준은 시작값이니 자기 데이터로 고칩니다. 사내 RAG 운영 담당 한 사람이 반나절이면 됩니다.

이 20개로는 상한이 조각 한 개보다 작아 원천이 잘리는지만 볼 수 있습니다. 1,200자와 1,800자처럼 4%포인트 차이를 가르려면, 정답 원천을 표시한 질문형을 50개 이상 모으십시오. 분모는 근거가 들어간 질문으로 고정하고, 앵커에 걸려 들어가지 않은 질문은 따로 적습니다. 후보 상한은 조각 1개, 2개, 4개 분량처럼 자기 조각 길이의 배수로 잡습니다.

함께 읽으면 좋은 글입니다.

• 프롬프트는 형식을, 사내 RAG는 판단을 채웠습니다 — 그리고 하네스가 둘 다의 오류를 잡았습니다
• Claude·OpenAI·Apple·Qwen 엔진 11개, 건강 질문 답변 310건으로 잰 질의응답 품질과 비용
• Obsidian × LLM 2년 운영 실측 — 4만 노트 개인 RAG의 최종 아키텍처 5층

「기업 RAG 운영 교훈」 시리즈

• 입구 글: 사내 RAG는 벡터 DB보다 ‘다시 찾는 고리’가 먼저입니다
• 1편: 사내 RAG는 근거를 먼저 넣고, 모자랄 때만 찾으러 보내십시오 (이 글)
• 2편: 사내 RAG를 늘리기 전에 인용 점검기와 퇴역 기준부터 다십시오
• 3편: 사내 RAG 근거는 사실을 더할 뿐 권한을 더하지 않습니다

짝 시리즈 · 경험으로 배운 하네스 운영 교훈

1. AI 에이전트가 느리다는 불만, 모델보다 왕복 수부터 세십시오
2. AI 에이전트 비용은 토큰 총량이 아니라 성공 작업당 비용으로 봅니다
3. AI 가드레일은 지침 문장이 아니라 집행 장치입니다
4. AI 운영 대시보드를 늘리기 전에 ‘끄면 무엇이 달라지는가’를 물으십시오
5. 기업 AI의 기억은 쌓기보다 꺼내는 길이 먼저입니다
6. 특별편: AI가 코드를 쓰는 회사에 필요한 개발 하네스

참고 자료

• Jeong, S. 외, Adaptive-RAG: Learning to Adapt Retrieval-Augmented LLMs through Question Complexity, NAACL 2024.
• Asai, A. 외, Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection, 2023.
• Trivedi, H. 외, Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions, ACL 2023.
• Anthropic, How we built our multi-agent research system, 2025.