대부분의 보건 의료 기관은 직원들에게 업무 수행 방법을 안내하는 수백에서 수천 개의 내부 문서를 보유하고 있습니다. 동의서, 사고 에스컬레이션 (Incident escalation), 근무 편성 규칙 (Rostering rules), 감염 관리 절차 (Infection control procedures), 어떤 양식을 어느 위원회에 언제까지 제출해야 하는지 등이 이에 해당합니다. 이러한 문서들은 존재하며 대부분 최신 상태를 유지하고 있지만, 거의 아무도 5분 이내에 적절한 문서를 찾아내지 못합니다. 그래서 사람들은 병동 사무원이나 품질 관리자, 혹은 그곳에서 가장 오래 근무한 사람에게 전화를 걸고, 그 사람은 매주 똑같은 12가지 질문에 답하게 됩니다.

이것은 보건 의료 분야에서 가장 화려하지는 않지만, 아마도 가장 훌륭한 첫 번째 AI 활용 사례일 것입니다. 이 사례는 전적으로 행정적인 측면에 위치하며, 소스 자료는 이미 소유하고 제어할 수 있는 텍스트이고, 문제가 발생했을 때 그 실패가 조용히 숨겨지기보다는 눈에 띄게 나타납니다. 이 포스트는 우리의 Practical AI in Health 시리즈의 일부이며, 이를 위해 우리가 실제로 구축하는 것, 즉 인용 (Citations), 단호한 거절 (Hard refusals), 그리고 프로젝트 팀 외부의 누구도 사용하기 전에 실행하는 평가 (Evaluation)를 포함한 내부 문서 세트에 대한 검색 증강 생성 (Retrieval-Augmented Generation, RAG)에 대해 다룹니다.

의도적으로 범위를 좁게 설정하기

첫 번째 설계 결정은 어시스턴트가 무엇에 답하지 않을 것인가에 대한 것이며, 이는 제품에 대한 결정이라기보다 컴플라이언스 (Compliance)에 대한 결정입니다.

TGA의 임상 의사 결정 지원 소프트웨어에 대한 가이드라인은 2021년 2월 25일부터 시행된 2002년 의료기기(Therapeutic Goods (Medical Devices) Regulations 2002)의 Schedule 4 Part 2에 따라 세 가지 부분으로 구성된 면제 테스트를 설정하고 있습니다. 소프트웨어는 반드시 의료 전문가에게 권장 사항을 지원해야 하며, 의료 영상이나 다른 장치로부터의 신호를 처리해서는 안 되고, 임상적 판단 (Clinical judgment)을 대체해서는 안 됩니다. 이 세 가지 조건을 모두 충족해야 하며, TGA는 어떤 것을 "의사 결정 지원 (Decision support)"이라고 부른다고 해서 면제되는 것은 아니라고 명시하고 있습니다. 면제가 적용되는 경우에도 스폰서 (Sponsors)는 공급 후 영업일 기준 30일 이내에 TGA에 통지해야 하며, 필수 원칙 (Essential Principles)을 준수하고, 이상 사례 (Adverse events)를 보고해야 합니다.

"투약 오류를 기록하는 우리의 절차는 무엇인가요?"라는 질문에 답하는 챗봇은 행정적 도구입니다. 하지만 동일한 챗봇이 "어떤 용량을 투여해야 하나요?"라는 질문에 답하기 시작한다면, 이는 다른 규제 영역으로 넘어간 것입니다. 따라서 거절 동작은 단순히 예의를 차리는 것이 아닙니다. 그것은 시스템을 당신이 설정한 범위 (Scope) 내에 유지하기 위한 통제 장치입니다. 답변이 임상적으로 인접한 어떤 것이라도 건드리는 경우, 설계 요구 사항은 답변이 실행되기 전에 지정된 사람이 승인해야 한다는 것이며, 인터페이스는 하단(Footer)이 아닌 사용 시점에 이를 명시해야 합니다.

더 넓은 규제 환경 측면에서, 연방 정부의 보건 의료 분야의 안전하고 책임 있는 AI 검토 (최종 보고서, 2025년, 69건의 서면 제출물 기반)는 기존의 보건 포트폴리오 법률이 경미하고 기술적인 수정만으로도 AI를 대부분 수용할 수 있다고 결론지었습니다. 준수해야 할 새로운 AI 법안은 없습니다. 당신의 의무는 개인정보 보호 (Privacy), 기록 (Records) 및 임상 거버넌스 (Clinical governance)와 관련하여 이미 가지고 있는 의무들입니다.

아키텍처 (The architecture)

시스템의 형태는 특별할 것이 없으며, 그것이 바로 핵심입니다:

• 수집 (Ingestion). SharePoint, 인트라넷, 정책 관리 시스템 등 문서가 존재하는 모든 곳에서 문서를 가져옵니다. 모든 청크 (Chunk)에 문서 ID, 버전, 소유자, 승인 날짜 및 검토 날짜를 메타데이터 (Metadata)로 유지합니다.
• 청킹 (Chunking). 고정된 토큰 수 (Token counts)가 아닌 문서 구조에 따라 분할합니다. 정책 문서는 번호가 매겨진 조항과 제목이 있으며, 사용자가 참조하고 싶어 하는 지점은 바로 그 경계선입니다.
• 임베딩 및 인덱스 (Embedding and index). 메타데이터 필터 (Metadata filters) 기능이 있는 벡터 저장소 (Vector store)를 사용하여, 검색 범위를 최신 버전이나 특정 역할이 볼 수 있도록 허용된 문서 세트로 제한할 수 있습니다.
• 검색 (Retrieval). 하이브리드 검색 (Hybrid search, 밀집 벡터 (Dense vectors)와 키워드 검색의 결합)은 일반적으로 정책 텍스트에서 단독 방식보다 성능이 뛰어납니다. 직원이 정확한 양식 번호나 내부 약어를 사용하기 때문입니다.
• 생성 (Generation). 모델이 검색된 청크 (Chunks)만을 사용하여 답변하고, 조항을 인용하며, 검색된 텍스트에 답이 없는 경우 모른다고 말하도록 지시하는 프롬프트 (Prompt)를 사용합니다.
• 인용 렌더링 (Citation rendering). 답변의 모든 주장은 문서, 버전 및 섹션과 연결되어 있어, 독자가 클릭 한 번으로 출처를 열어볼 수 있습니다.
• 로깅 (Logging). 질문, 검색된 청크 ID, 답변, 인용, 사용자 피드백을 기록합니다. 이것이 귀하의 감사 추적 (Audit trail)이자 평가 데이터가 됩니다.

청크 (Chunk) 레코드는 대략 다음과 같습니다:

{
  "chunk_id": "POL-CG-014-v3.2#4.1.2",
  "doc_id": "POL-CG-014",
...

review_due (검토 예정일) 정보를 답변까지 전달하는 것은 보기보다 훨씬 중요합니다. 8개월 전에 만료된 정책을 자신 있게 인용하는 어시스턴트는 검색창보다 더 나쁩니다. 왜냐하면 독자가 표지에서 날짜를 확인했을 순간을 놓치게 만들기 때문입니다.

파인튜닝 (Fine-tuning) 대신 RAG를 사용하는 이유

거의 모든 프로젝트에서 이 질문을 받습니다. 보통 "우리 정책으로 모델을 그냥 학습시키면 안 되나요?"라는 식으로 질문이 들어옵니다.

Ovadia 등은 EMNLP 2024에서 바로 그 비교를 테스트하며, 베이스 모델 (base model), 비지도 미세 조정 (unsupervised fine-tuning), RAG, 그리고 미세 조정 (fine-tuning)과 RAG의 결합을 지식 집약적 작업 (knowledge-intensive tasks)에 대해 대조했습니다. RAG는 기존 지식과 완전히 새로운 지식 모두에서 미세 조정 (fine-tuning)보다 일관되게 우수한 성능을 보였으며, 두 가지를 결합하는 것이 RAG 단독 사용보다 확실하게 더 나은 성능을 보여주지는 않았습니다.

실무적인 논거는 벤치마크 논거보다 더 강력합니다. 미세 조정 (fine-tuning)은 지식을 가중치 (weights)에 구워 넣는 방식이므로, 답변이 어떤 문서에서 왔는지 알려줄 수 없으며, 위치를 찾을 수 없는 정보는 인용할 수도 없습니다. 정책이 개정될 때, RAG는 재색인 (re-index)이 필요하지만 미세 조정 (fine-tuning)은 재학습 (retraining) 사이클이 필요합니다. 또한 정책이 철회될 때, RAG는 해당 청크 (chunk)를 삭제하지만, 미세 조정 (fine-tuning)은 이전 텍스트를 가중치 어딘가에 남겨두며 이를 제거할 신뢰할 수 있는 방법이 없습니다.

정확도는 검색 품질 (retrieval quality)에서 결정됩니다. 우리가 문헌에서 본 내부 정책 어시스턴트와 가장 유사한 사례인 병원 EMR 매뉴얼 기반의 공개된 RAG 챗봇은, LLM을 변경하는 대신 임베딩 모델 (embedding model)을 미세 조정함으로써 5,931개의 질문-문서 평가 세트를 구축하고 top-k 검색 정확도를 97.6%까지 끌어올렸습니다.

인용은 안전 장치이지만, 거짓말을 할 수도 있습니다

"우리는 RAG를 사용합니다"라는 말은 안전을 보장하는 주장이 아닙니다. 2025년 Journal of Empirical Legal Studies에 발표된 Stanford RegLab의 상용 법률 조사 도구에 대한 사전 등록 연구에 따르면, 202개의 쿼리를 수동으로 채점한 결과 Lexis+ AI는 약 17%, Westlaw AI-Assisted Research는 33%의 환각 (hallucination) 발생률을 보였으며, 이는 GPT-4의 43%와 대조되었습니다. RAG가 도움이 된 것은 사실입니다. 하지만 벤더들이 "환각 없는 (hallucination-free)" 인용을 광고함에도 불구하고, RAG가 문제를 완전히 제거하지는 못했습니다.

당신의 설계를 바꿔야 할 발견은 바로 인용 환각 (citation hallucination)에 관한 것입니다. 이는 실제 존재하지만 틀린 출처를 인용하는 답변을 의미하며, 저자들은 이것이 노골적인 허구보다 훨씬 더 해로울 수 있다고 주장합니다. 왜냐하면 참조(reference)가 존재한다는 사실 자체가 검토자가 확인을 멈추게 만들기 때문입니다. 이는 호주 보건 의료 안전 및 품질 위원회 (Australian Commission on Safety in Health Care)가 자동화 편향 (automation bias)이라고 설명하는 것과 동일한 함정이며, 여기에는 작위 오류 (errors of commission, 잘못된 권고에 따라 행동함) 및 부작위 오류 (errors of omission, 도구가 무언가를 놓쳤을 때 행동하지 않음)가 포함됩니다.

따라서 우리는 답변의 정확성 (answer correctness)과 별개로 인용의 정확성 (citation correctness)을 점수화하며, 단순한 참조 번호 대신 인용된 절의 텍스트를 본문 내에 (inline) 보여줍니다. 독자가 답변이 추출된 문장을 직접 볼 수 있다면, 확인에 드는 시간은 3분이 아니라 3초로 줄어듭니다.

출시 전 평가

단순한 느낌 (vibes)과 데모 버전만 가지고 경영진에게 출시하지 마십시오. 우리가 사용하는 평가 설계는 발표된 2025년 RAG 배포 가이드를 따릅니다. 두 명의 주제 전문가 (subject matter experts)가 검토한 정답 (ground-truth answers)을 포함하여 약 100개의 질문으로 구성된 테스트 세트를 구축한 다음, 검색 실패 (retrieval failure: context precision, context recall)와 생성 실패 (generation failure: faithfulness, answer relevancy)를 구분하는 RAGAS 지표로 점수를 매깁니다.

이러한 분리가 수치를 실행 가능한 정보로 만들어 줍니다. 검색 결과는 좋으나 충실도 (faithfulness)가 낮다면 모델이 내용을 지어내고 있다는 의미이므로 프롬프트 (prompt)나 모델을 수정해야 합니다. 문맥 재현율 (context recall)이 낮다면 정책이 검색되지 않았다는 의미이므로 청킹 (chunking), 임베딩 (embeddings) 또는 인덱스 (index)를 수정해야 합니다. 여기에 테스트 세트가 놓치기 쉬운 두 가지 카테고리를 추가하십시오. 바로 거절해야 하는 범위를 벗어난 질문 (out-of-scope questions)과, 답변이 폐기된 문서에 있는 질문입니다. 후자의 경우 현재 버전을 인용하는 것이 올바른 동작입니다.

위원회의 가이드는 "사용 전(before you use)", "사용 중(while you use)", "사용 후(after you use)"를 중심으로 구성되어 있으며, 이는 평가 게이트(evaluation gate), 피드백 수집을 포함한 감독 하의 파일럿(supervised pilot), 그리고 문서 변경에 따른 정기적인 재평가라는 배포 계획(rollout plan)과 깔끔하게 매칭됩니다.

개인정보 보호, 호스팅 및 비용

OAIC의 2024년 10월 지침은 상업용 AI 제품을 사용하는 모든 조직을 1988년 개인정보 보호법(Privacy Act 1988) 및 13가지 호주 개인정보 보호 원칙(Australian Privacy Principles)에 따른 의무를 지는 "배포자(deployer)"로 취급하며, 이는 순수하게 내부적으로만 사용하는 경우를 포함합니다.
정책 문서는 대개 개인정보(personal information)가 아니지만, 쿼리 로그(query logs)는 개인정보가 될 수 있습니다. 왜냐하면 "내가 이런 실수를 했다면 어떻게 해야 하나요?"와 같은 질문은 개인에 관한 질문이기 때문입니다.

이는 인덱스(index)와 로그를 호주 내에 호스팅되고 접근 제어(access-controlled)가 이루어지는 인프라에 보관할 것을 주장하며, 모델 제공업체와의 계약에는 사용자의 트래픽을 학습에 사용하는 것을 금지하는 데이터 보유(data-retention) 조항이 포함되어야 합니다. 위험 맥락은 추상적이지 않습니다. 보건 서비스 제공업체는 2025년 달력 연도 기준 호주에서 가장 많은 침해를 당한 부문이었으며, 1,205건의 통지 중 225건을 기록하여 금융 부문의 157건을 앞질렀고, 전체 통지 건수는 사상 최고치를 기록했습니다.

비용에 대한 솔직한 버전은 다음과 같습니다. 수천 권 미만의 문서 말뭉치(corpus)의 경우, 추론(inference) 및 벡터 저장(vector storage) 비용은 보통 한 달에 수백 달러 수준이며 때로는 그보다 적게 듭니다. 실제 지출은 그 주변 작업에서 발생합니다. SharePoint에서 깨끗하고 버전이 관리된 문서 세트를 추출하고, 해당 분야 전문가(subject matter experts)와 함께 평가 질문을 구축하며, 파일럿을 실행하는 작업이 예산의 대부분을 차지할 것입니다. 첫 빌드는 몇 달이 아닌 몇 주 정도 걸릴 것으로 예상해야 하며, 문서 정제 작업이 소프트웨어 구축보다 더 오래 걸릴 것임을 예상해야 합니다.

미리 언급할 만한 한계점은 다음과 같습니다: 이 시스템은 귀하의 정책 라이브러리(policy library)가 최신 상태인 만큼만 유효합니다. 만약 문서의 절반이 검토 기한이 지났다면, 어시스턴트는 그 문제를 모든 사람에게 동시에 드러낼 것입니다. 여러 고객들은 이 점이 유용하다고 느꼈습니다. 반면, 몇몇 고객들은 이를 불편하게 느끼기도 했습니다.

PicNet은 호주 기관들을 위한 프로덕션 AI (production AI) 시스템을 구축합니다. 첫 번째 프로젝트가 어떤 모습일지에 대해 저희에게 문의하세요.

원문은 picnet.com.au에 게시되었습니다.