사내 RAG를 늘리기 전에 인용 점검기와 퇴역 기준부터 다십시오 — 인용 실험 40문항과, 개인 RAG 8개 중 3개만 자동으로 쓰인 운영 기록

PART 01 · Frame하네스의 두 교훈이 RAG에도 그대로 왔습니다

짝을 이루는 하네스 편 두 편은 이렇게 적었습니다. 「AI 가드레일은 지침 문장이 아니라 집행 장치입니다」는 규칙마다 막는 장치를 짝지어야 한다고 했습니다. 「AI 운영 대시보드를 늘리기 전에 ‘끄면 무엇이 달라지는가’를 물으십시오」는 결정을 바꾸지 않는 관측에 예산을 걸어야 한다고 했습니다.

RAG에서 같은 자리를 찾으면 이렇습니다.

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

RAG는 사실을 다루므로 두 교훈이 더 날카롭습니다. 인용이 어긋나면 근거가 있는 척하는 답이 나옵니다. 쓰지 않는 인스턴스는 엔진을 고칠 때마다 함께 고쳐야 할 사본으로 남습니다.

PART 02 · Citation인용 규칙은 근거 옆에 둘 때 90%까지 지켜졌습니다

Sillok의 미리 넣기 훅(질문이 들어올 때마다 근거를 자동으로 붙이는 장치)은 근거 묶음 첫 줄에 이 규칙을 붙입니다. “인용 표기를 그대로 붙여 답하고, 근거 밖 사실은 [U] 로 표시.” 이 한 줄이 실제로 지켜지는지, 지키게 하려면 무엇이 필요한지 재 보았습니다.

입력은 공공 정보화사업 법령과 공공 AX 안내서의 보류 질문 가운데 근거가 들어가는 것을 20개씩, 모두 40개 골랐습니다. 질문마다 근거 묶음은 같고(평균 1,342자), 조건은 셋입니다.

1. 규칙 없음: 근거 묶음 머리글에서 인용 지시만 뺐습니다.
2. 규칙만: 실제 훅 머리글을 그대로 썼습니다.
3. 규칙 + 점검기: 규칙만의 답을 점검기가 보고, 어긴 문장이 있으면 목록을 돌려주며 한 번 다시 쓰게 했습니다.

점검기는 AI를 쓰지 않는 몇십 줄짜리 규칙입니다. 답을 문장으로 나누고(빈 줄·제목·목록 기호·콜론으로 끝나는 머리 문장은 빼고), 문장마다 대괄호 표기를 찾아 넷으로 가릅니다. 근거 묶음에 있는 인용, 묶음에 없는 인용, [U] 표시, 아무 표시 없음입니다. 표시 없는 문장과 묶음에 없는 인용이 하나도 없으면 형식을 지킨 답으로 셉니다. 답을 쓰는 대규모 언어 모델(LLM)은 Claude Sonnet 5.5이고, 제 개인 설정을 끈 상태로 불렀습니다.

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

규칙이 없으면 근거를 줘도 인용은 0이었습니다. 문장 173개 가운데 출처를 밝힌 문장이 하나도 없었습니다. 근거를 넣는 일과 근거를 밝히는 일은 별개였습니다.

규칙 한 줄로 90%가 지켰습니다. 하네스 편의 상시 규칙과 다른 결과입니다. 차이는 규칙이 놓인 자리로 보입니다. 상시 규칙은 세션을 시작할 때 한 번 실리고 일하는 동안 멀어집니다. 이 규칙은 근거 묶음의 첫 줄, 곧 행동하는 바로 그 자리에 있습니다. 지켰는지 기계로 확인할 수 있는 형식이라는 점도 같이 작용했다고 봅니다.

어긴 답 4개의 모습은 둘이었습니다. 3개는 인용 없는 문장을 남겼습니다. 1개는 인용 표기를 줄여 적었습니다. 원천 이름을 “07-NIA 가이드라인”처럼 바꿔 쓰면, 사람은 읽을 수 있어도 원문 읽기 명령으로는 되돌아갈 수 없습니다. 인용은 사람만이 아니라 다음 도구가 읽는 주소이기도 합니다.

점검기를 달자 40개 모두 지켰습니다. 다시 쓴 답은 모두 형식을 지켰습니다. 다만 이것은 점검기 기준의 형식 준수입니다. 인용이 문장을 실제로 뒷받침하는지는 따로 재지 않았습니다.

솔직히 적을 것이 있습니다. 실험 때 쓴 점검기 첫 판은 7개 답을 돌려보냈습니다. 실제로 어긴 4개에, “2.” 같은 번호 뒤 마침표에서 문장을 잘못 자른 오탐 3개가 섞였습니다. 추가 호출 질문당 0.18회는 이 7개를 다시 쓴 값입니다. 고친 점검기라면 4개만 돌려보내 0.10회였겠지만, 그 조건으로 다시 돌리지는 않았습니다.

첫 판에는 12자보다 짧은 문장을 세지 않는 조건도 있었습니다. 리뷰에서 이 조건이 “계약은 무효입니다.” 같은 짧은 무인용 문장을 통과시킨다는 지적을 받고 지웠습니다. 고친 점검기로 저장된 답 전부를 다시 채점한 값이 위 표입니다. 규칙만 조건에서 짧은 무인용 문장이 1개 더 잡혔지만, 이미 어긴 답 안에 있어 형식을 지킨 답의 수는 바뀌지 않았습니다. 점검기도 시험을 받아야 하는 장치입니다.

2차 리뷰에서는 두 가지를 더 지적받았습니다. 숫자나 영문 뒤 마침표에서 문장을 자르지 않아, 뒤 문장의 [U]가 앞의 무표시 문장까지 통과시킬 수 있었습니다. 본문에 실은 줄인 점검기는 ‘[근거 없음]’ 같은 아무 대괄호나 표시로 인정했습니다(실험용 점검기는 이런 문장을 표시 없음으로 셌습니다). 둘 다 고쳐 저장된 답을 다시 채점했고, 판정이 바뀐 답은 없었습니다. 실험 뒤에 점검기를 세 번 고친 셈입니다.

형식을 지켰다고 내용이 맞는 것은 아닙니다. 인용이 붙었지만 인용한 조각에 그 문장의 낱말이 3분의 1밖에 없는 문장이 1개 있었습니다. 이런 문장은 사람이 먼저 볼 후보이지 오답 판정이 아닙니다. 인용 평가 연구 ALCE(Gao 외, 2023)도 가장 좋은 모델의 답이 ELI5 데이터에서 50%는 인용으로 완전히 뒷받침되지 않았다고 보고했습니다.

검색 결과나 근거 지지를 평가해 다음 행동을 고르는 연구도 같은 방향입니다. Self-RAG(Asai 외, 2023)는 모델이 근거 지지 여부를 스스로 표시하게 했습니다. CRAG(Yan 외, 2024)는 가벼운 평가기가 검색 결과의 질을 보고 다음 검색 행동을 고르게 했습니다. Sillok 점검기는 학습된 평가기가 아니라 정규식 몇 줄입니다. 형식을 지키게 하는 데는 그것으로 충분했고, 내용 판정은 여전히 사람의 몫입니다.

PART 03 · Verify위키 인용 대조는 돌았지만, 사람에게 닿지 않았습니다

Sillok의 RAG 엔진은 원문에서 한국어 요약 위키를 만들고, 위키 문장마다 원문의 쪽·조를 인용으로 붙입니다. 엔진의 대조 명령은 위키 문장의 용어와 숫자가 인용한 쪽(앞뒤 1쪽 포함)에 실제로 있는지 봅니다.

11월 3일에 인스턴스 8개 전부에서 대조를 돌렸습니다. 대조할 인용이 있는 6개에서 인용 20,295건을 쟀습니다. 낱말 대부분이 인용한 쪽에 있는 강한 근거가 66.7%, 부분이 26.6%, 거의 없는 약한 근거가 6.8%(1,373건)였습니다.

약한 근거는 결함 판정이 아닙니다. 요약이 의역이거나 인용한 쪽이 절의 시작 쪽일 수도 있습니다. 그래서 엔진은 약한 근거를 모아 검토 대기열 파일을 만들고, 사람이 원문을 열어 확인한 뒤 위키 쪽의 상태를 ‘검토 완료’로 바꾸게 했습니다. 낱말 대조로 인용을 자동으로 고치지 말라는 경고도 붙였습니다. 2026년 9월 21일에 자동 수정 후보 7건을 확인해 보니 맞는 것이 0건이었기 때문입니다.

대기열은 인스턴스 4개에 만들어졌습니다(9월 21일~10월 6일). 그러나 위키 603쪽 가운데 검토를 마친 쪽은 0쪽이었습니다. 초안이 308쪽, 뼈대만 있는 쪽이 287쪽, 인스턴스마다 하나씩 있는 자동 생성 개요 쪽이 8쪽이었습니다. 인스턴스 2개는 아예 대조할 수 없었습니다. 하나는 위키가 뼈대뿐이었고, 하나는 원문 텍스트가 없었습니다.

하네스 편의 경고 1,698회와 같은 모습입니다. 장치는 돌았고 출력도 만들었지만, 그 출력을 받아 결정할 사람과 시점이 없었습니다.

그래도 검토 안 된 위키가 자동으로 붙는 근거에 섞이지는 않았습니다. 미리 넣기 훅은 원문과 용어집만 넣고, 위키를 넣으려면 인스턴스 설정에서 따로 켜야 합니다. 세 인스턴스 모두 이 스위치를 켜지 않았습니다. 에이전트가 직접 검색할 때는 위키 요약이 최대 2건, 원문 조각 뒤에 붙어 나옵니다. 원문을 찾아가는 길잡이로만 쓰라는 배치이고, 이 길에서는 검토 표시가 여전히 필요합니다.

검토를 강제하지 못할 때는, 검토 안 된 것이 흘러가지 못하게 막는 구조가 먼저입니다. 하네스 편은 장치를 구조·차단·탐지·문장뿐의 네 층으로 나눴고, 맨 위가 구조입니다. 그 글이 인용한 원칙도 “구조로 고칠 수 있으면 구조로만 고친다”였습니다.

다음 단계는 대기열을 결정 지점에 묶는 것입니다. 지금 스위치는 인스턴스 전체를 한꺼번에 켜고 끕니다. 이를 쪽 단위로 바꾸자고 제안합니다. 도메인 검토자가 한 쪽의 약한 근거부터 원문과 대조해 고치되, 그 쪽의 사실 주장과 인용을 모두 확인한 뒤 상태를 ‘검토 완료’로 바꾸면 그 쪽만 주입 대상이 됩니다. 운영 담당자는 검토 완료 쪽만 넣는 설정을 켭니다. 그러면 대기열은 누군가 언젠가 볼 목록이 아니라 기능을 여는 열쇠가 됩니다.

검토 용량부터 정해야 0쪽이 되풀이되지 않습니다. 예를 들어 쪽당 15분, 담당 1명, 주 10쪽으로 잡으면 초안 308쪽은 7개월 넘게 걸립니다. 그래서 첫 목표는 ‘이번 분기에 약한 근거가 많은 30쪽’처럼 작게 잡습니다. 쪽당 시간과 주당 쪽 수는 가정값이니 조직에 맞게 고칩니다.

PART 04 · Eval평가셋이 무엇이냐가 품질 판단을 바꿨습니다

인스턴스마다 평가셋이 있습니다. 대부분은 같은 문서를 보고 쓴 질문입니다. 사전과 위키를 다듬을 때 쓰는 개발 질문과, 다듬을 때는 보지 않는 보류 질문으로 나눕니다. 보류 질문에서 정답 쪽이 검색 상위 3건 안에 든 비율은 인스턴스 4개에서 75~87%였습니다.

국방 SW 사업과 공공 SI 사업 인스턴스에는 셋째 평가셋이 있습니다. 실제 사업 문서에서 떼어 와, 다듬을 때 한 번도 보지 않도록 따로 둔 봉인 문장 60개입니다. 같은 색인, 같은 한 번 검색인데 결과가 크게 달랐습니다.

개발 질문으로는 73%와 86%였지만, 봉인 문장으로는 8%와 18%였습니다. 같은 문서를 보고 쓴 질문은 문서의 낱말을 닮습니다. 실제 업무 문장은 그렇지 않습니다. 검색 평가에서 좁은 환경만 재면 분야가 바뀔 때의 성능을 알 수 없다는 문제의식은 BEIR(Thakur 외, 2021)가 18개 데이터셋 평가를 만든 이유이기도 합니다.

평가셋은 실제로 결정을 바꿨습니다. 10월 12일 두 인스턴스에 사업 문서가 인용한 법령 44종을 더하자, 국방 쪽 개발 질문의 상위 3건 적중이 77%에서 73%로 내려갔습니다. 22문항 중 1문항 차이라 잡음일 수 있었지만, 이 하락이 봉인 문장을 60개씩 두 벌 만든 계기가 됐습니다.

그 뒤 봉인셋을 검색 정책 7안을 고르는 데 썼습니다. 그래서 아래 개선 수는 선택에 쓴 셋에서의 결과이고, 선택에 쓰지 않은 별도 셋으로 다시 검증하지는 않았습니다. 공공 SI에는 두 검색의 순위를 섞는 정책을 채택했습니다. 봉인 문장을 4개 더 맞혔고, 업무 시나리오 시험 10개를 모두 통과했습니다. 국방에서는 같은 정책이 봉인 문장을 6개 더 맞혔지만, 업무 시나리오 시험 하나를 깨뜨려 기존 정책을 유지했습니다. 첫 편에서 문서 문장을 처음부터 찾으러 보내자고 한 근거도 이 봉인 문장이었습니다.

평가셋이 자동으로 막는 곳은 아직 한 곳입니다. 새 인스턴스를 만드는 공용 제작 경로는 품질 하한을 밑돌거나 지표가 떨어지면 빌드를 멈춥니다. 이미 운영 중인 인스턴스의 평가는 사람이 명령을 칠 때만 돕니다.

PART 05 · Field크린앤사이언스는 점검 단위를 답에서 문장으로 줄였습니다

고객 동의를 받아 크린앤사이언스 사내 RAG의 사례를 하나 옮깁니다. 그곳의 AI 대화에도 점검기가 있었습니다. 답에 나온 숫자와 번호가 근거 원문과 글자 그대로 맞는지 보는 장치입니다. 문제는 점검 단위였습니다. 처음에는 숫자 하나만 어긋나도 답 전체를 버리고 근거 목록만 보여 줬습니다. 지키게 하려던 장치가 쓸 만한 답까지 지운 셈입니다.

그래서 10월에 두 번 고쳤습니다. 먼저 답을 결론, 핵심 내용, 표, 다음 확인 같은 항목으로 나눠 어긋난 항목만 빼고, 뺀 개수를 화면에 알리게 했습니다. 운영 화면을 확인하는 중에 결론 문단도 같은 이유로 통째로 바뀌는 것을 찾아, 결론은 문장 단위로 검사하게 했습니다. 이 글의 점검기가 문장마다 나눠 보는 것과 같은 판단입니다. 한계도 남았습니다. 가운데 문장이 빠지면 뒤 문장의 ‘나머지는’ 같은 지시어가 앞 문장 없이 남을 수 있습니다.

평가에서도 같은 태도를 지켰습니다. 착수 때 키워드 일치로 매긴 정답 판정은 현행 기준에서 뺐습니다. 그리고 회사가 판정 질문을 검토하기 전까지는 답이 맞는 비율을 숫자로 말할 수 없다고 적었습니다(10월 중순 기준). 저는 기준이 다른 숫자를 쓰기보다 ‘미검증’으로 비워 두는 편이 판단에 덜 위험하다고 봅니다.

PART 06 · Lifecycle8개 가운데 전역 훅으로 쓰인 것은 3개였습니다

인스턴스를 만든 이유는 대개 과제였습니다. 교육 과정이나 워크숍, 제안 준비를 위해 그 분야의 표준과 법령을 묶었습니다. 그렇다면 과제가 끝난 뒤에도 쓰이고 있을까요. 전역 훅의 주입 기록과, 세션 기록에서 엔진을 명령으로 직접 부른 횟수를 셌습니다.

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

전역 훅에 등록된 3개는 지난 30일 동안 근거를 112번 넣었습니다. 나머지 5개는 누군가 명령으로 불러야만 쓰입니다. 8개를 합친 직접 호출은 60일 동안 62회였습니다. 등록되지 않은 5개 가운데 3개는 마지막 사용 뒤 22일 이상 지났고(글로벌 표준 33일 · 고객 워크숍용 25일 · 공공 SI 사업 22일), 국방 SW 사업도 21일이었습니다. 과제가 끝나면 쓰이지 않는 것은 자연스럽습니다. 빠진 것은 그다음을 정하는 규칙이었습니다.

쓰이지 않는 인스턴스도 비용을 냅니다. 인스턴스마다 엔진 사본을 하나씩 품고 있습니다. 8개 사본은 모두 판 번호 2.3.5를 달고 있지만 파일은 세 갈래였습니다. 5개가 같고, 2개가 같고, 1개가 따로입니다. 엔진을 고치면 최대 세 갈래를 따로 맞춰야 합니다.

엔진 판을 지키는 단언도 하나 있습니다. 다만 그 단언은 한 사본에 판 번호 문자열이 있는지만 봅니다. 장치가 있어도 장치가 보는 범위가 의도보다 좁으면, 하네스 편이 말한 ‘문장뿐인 규칙’과 크게 다르지 않습니다.

등록 원장에는 회수한 인스턴스가 2개 있습니다. 둘 다 교육 폴더 경로를 전역 주입에 쓴 정책 위반 때문이었습니다. 쓰이지 않아서 거둔 인스턴스는 아직 없습니다.

PART 07 · Retire퇴역 기준은 ‘끄면 무엇이 달라지는가’로 정했습니다

하네스 편은 구성요소를 “끄면 무엇이 달라지는가”로 갈랐습니다. 같은 질문을 인스턴스에 던지면 답이 분명합니다. 전역 훅에 등록되지 않은 인스턴스는 꺼도 미리 넣기에는 아무 변화가 없습니다. 누군가 직접 부를 때만 차이가 납니다. 그런데도 엔진 사본과 평가셋은 계속 관리 대상으로 남습니다.

그래서 아래 기준을 제안합니다. Sillok이 프롬프트 팩에 쓰는 퇴역 규칙(22일 무사용이면 점검, 90일이면 퇴역 후보)을 인스턴스로 옮긴 것입니다. 아직 원장에 필드를 더하지 않았고, 효과도 재지 않았습니다.

1. 등록은 보류 질문과 인용 대조가 있을 때 합니다. 같은 문서로 쓴 보류 질문이 있고, 원문 텍스트가 있어 인용 대조가 돌아야 합니다.
2. 실제 업무 문장의 봉인셋은 승격 조건으로 둡니다. 지금 전역 훅에 등록된 3개는 봉인셋이 없습니다. 이 조건을 등록에 소급하면 셋 다 유예 대상이므로, 문서 문장 같은 간접 입력에 쓰기 전까지 봉인셋을 만들기로 합니다. Sillok은 사업 문서가 「법령」 제N조로 인용한 문장에서 법령 이름과 조 번호를 지워 봉인 문장을 기계적으로 만들고, 정답은 지운 그 조로 둡니다. 업무 담당자가 평가 전에 사용 목적별 합격선과 필수 시나리오를 정하고, 그 기준을 넘어야 간접 입력에 씁니다. 원장에는 평가셋 경로와 함께 합격 기준, 결과, 승인자를 남깁니다. 봉인 문장 30개를 뽑는 일은 담당 1명이 반나절이면 됩니다(가정).
3. 등록 전에 오탐을 잽니다. 공공 AX 안내서 인스턴스의 등록 전 기록은 최근 실제 프롬프트 500개에 주입 0건, 공공 AX 질문 6개에 모두 주입이었습니다. 이 500개를 통째로 영역 밖으로 본 측정이라, 일반 조건으로 쓸 때는 영역 밖으로 분류한 프롬프트에서 오탐을, 영역 안 질문에서 정상 주입을 따로 잽니다. 500개와 6개는 이 사례의 표본 수입니다. 영역 안·밖은 사람이 실제 프롬프트 50개에 표시해 정합니다. 합격선은 예를 들어 영역 밖 오탐 0건, 영역 안 정상 주입 80% 이상으로 두고 조직에서 고칩니다.
4. 22일 이상 쓰이지 않으면 점검합니다. 과제가 끝났는지, 다른 인스턴스와 합칠 수 있는지 봅니다.
5. 90일 이상 쓰이지 않으면 보관합니다. 등록을 풀고 엔진 갱신 대상에서 뺍니다. 색인·원문·평가셋은 지우지 않습니다.
6. 전역 훅 등록은 하나 더하면 하나 뺍니다. 하네스 편의 1-in-1-out 예산을 그대로 씁니다.

원장 항목과 점검기는 이렇게 적어 둘 수 있습니다. 앞의 것은 등록 원장 항목에 더할 필드(제안)이고, 뒤의 것은 이번 실험에서 쓴 점검기를 줄인 것입니다.

[등록 원장 항목에 더할 수명주기 필드 — 제안]
- id: public-ax-standards
  enabled: true
  eval: {holdout: eval_holdout.json}       # 등록 조건
  promote_eval: {sealed: eval_sealed.json}  # 간접 입력에 쓰기 전 승격 조건
  promote_record: {criteria: "", result: "", approver: ""}   # 승격 때 합격 기준·결과·승인자
  register_check: "영역 밖 프롬프트 오탐 · 영역 안 질문 주입을 따로 잼"
  last_use: 2026-11-02                 # 훅 주입·직접 찾기 가운데 늦은 날
  idle_review_days: 22                 # 쉰 날이 이 값 이상이면 점검
  idle_archive_days: 90                # 이 값 이상이면 등록 해제·보관(지우지 않음)

[인용 점검기 — 어긴 문장을 찾아 돌려준다 · pack_cites = 그 답에 준 근거 묶음의 인용 표기 목록]
import re
BR = re.compile(r"\[[^\[\]]{1,160}\]")
CITE_LIKE = re.compile(r"§|제\s*\d+\s*조|p\.\s*\d|^\[\s*\d{2}-")   # 자기 인용 표기에 맞게 고친다
SPAN = re.compile(r"\[[^\[\]]{1,160}\]|\([^()\n]{1,200}\)|\"[^\"\n]{1,200}\"|“[^”\n]{1,200}”")
END = re.compile(r"(?<=[.!?])\s+|(?<=[.!?][\"'’”])\s+")

def check(answer, pack_cites):
    bad, unmarked = [], []
    for line in answer.splitlines():
        line = re.sub(r"^\s*(?:[-*•]|\d+[.)])\s*", "", line).strip()   # 목록 기호만 지운다
        if not line or line.startswith("#") or line.endswith(":"):     # 빈 줄·제목·머리 문장은 뺀다
            continue
        masked = SPAN.sub(lambda m: m.group(0).replace(" ", "\0"), line)   # 대괄호·괄호·따옴표 안에서는 자르지 않는다
        for s in END.split(masked):
            s = s.replace("\0", " ").strip()
            if not s:
                continue
            tags = BR.findall(s)
            cites = [t for t in tags if CITE_LIKE.search(t)]
            bad += [t for t in cites if t not in pack_cites]
            if not cites and not any(t.strip("[] ").upper() == "U" for t in tags):
                unmarked.append(s)                                     # 인용도 [U]도 없으면 표시 없음(다른 대괄호만 있어도)
    return bad, unmarked   # 둘 다 비면 통과, 아니면 목록을 붙여 한 번 다시 쓰게 한다

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

• 운영자 한 사람의 개인 체계입니다: 8개 인스턴스의 사용량은 저 혼자의 작업 방식에 달려 있습니다. 여러 부서가 함께 쓰는 조직의 사용 패턴은 재지 않았습니다.
• 표본이 작습니다: 인용 실험은 질문 40개, 조건마다 한 번, 모델 하나입니다.
• 점검기는 형식만 봅니다: 인용이 내용을 실제로 뒷받침하는지는 판정하지 않습니다. 낱말 일치율은 사람 검토의 우선순위일 뿐입니다.
• 점검기를 실험 뒤에 두 번 고쳤습니다: 고친 판으로 모든 조건을 다시 채점했지만, 다시 쓰게 할지는 첫 판이 정했습니다.
• 사용량은 명령 기록으로 셌습니다: 엔진을 모듈로 불러 쓴 실험 스크립트와, 이 글을 쓴 세션의 호출은 세지 않았습니다.
• 22일·90일은 옮겨 온 값입니다: 프롬프트 팩의 규칙이고, 인스턴스에 맞는 값인지는 아직 재지 않았습니다.
• 고객 워크숍용 인스턴스는 이름을 가렸습니다: 원천 목록과 내용은 싣지 않았습니다.

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

인용 규칙은 근거 옆에 두면 90%가 지켰고, 점검기 한 겹이 형식의 나머지를 채웠습니다.

검토 대기열은 결정 지점에 묶어야 사람에게 닿습니다. 그 전에는 흘러가지 못하게 막습니다.

인스턴스는 보류 질문으로 들이고 봉인셋으로 승격하며, 22일·90일 기준으로 거두자고 제안합니다.

이번 주에는 두 가지를 해 보시기 바랍니다. 먼저 사내 RAG의 답 20개를 모아, 위 점검기로 표시 없는 문장과 바꿔 적은 인용의 수를 세어 보십시오. 전제는 답과 함께, 그 답을 낼 때 모델에 준 근거 묶음의 인용 목록이 남아 있어야 한다는 것입니다. 남지 않는다면 개발 담당이 그 저장부터 붙입니다. 인용 표기가 대괄호가 아니라면 점검기의 정규식을 자기 표기에 맞게 고칩니다. 개발 담당 반나절, AX 담당은 결과 해석 30분으로 잡습니다(가정). 근거 묶음 첫 줄에 인용 규칙이 없다면, 한 줄을 넣기 전후로 같은 수를 비교하면 됩니다.

다음으로 RAG 인스턴스나 지식 묶음 목록에 ‘마지막 사용일’ 열을 하나 더하십시오. 22일 이상인 것부터 “끄면 무엇이 달라지는가”를 물으면, 거둘 것과 남길 것이 갈립니다.

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

• 프롬프트는 형식을, 사내 RAG는 판단을 채웠습니다 — 그리고 하네스가 둘 다의 오류를 잡았습니다
• 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가 코드를 쓰는 회사에 필요한 개발 하네스

참고 자료

• Gao, T. 외, Enabling Large Language Models to Generate Text with Citations, EMNLP 2023.
• Asai, A. 외, Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection, 2023.
• Yan, S.-Q. 외, Corrective Retrieval Augmented Generation, 2024.
• Thakur, N. 외, BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models, NeurIPS 2021.