답변이 돌아온 뒤에 필요한 검증
여기어때 공통플랫폼개발팀은 사내 지식 검색 프로젝트의 세 번째 글에서 관측과 평가, MCP 서빙 과정을 공개했다. 기술블로그는 랭퓨즈(Langfuse)를 사용해 검색부터 프롬프트 구성, 생성까지 요청 흐름을 추적했다고 설명했다. 프롬프트와 응답, 토큰·비용·지연시간을 함께 기록해 어느 단계가 자원을 사용하는지 확인하는 방식이다.
요청 기록이 보인다고 답이 옳다는 사실까지 확인되는 것은 아니다. 팀은 사내 지식 질문을 일곱 유형으로 나눠 정답과 정답 문서를 준비했다. 랭퓨즈 공식 문서도 데이터셋을 입력과 기대 출력의 모음으로 설명하고, 운영 트레이스에서 테스트 사례를 만들 수 있다고 안내한다. 제품의 관측 기능과 팀이 만든 평가 기준을 구분할 필요가 있다.
검색 성공과 최종 답변을 두 층으로 평가
팀은 정답 문서가 상위 결과에 들어왔는지 보는 Recall@5와 Hit Rate, 정답의 순위를 보는 MRR을 계산했다. 이어 MCP를 연결한 에이전트가 실제 답을 만들게 하고, 생성 모델과 분리한 LLM에 정답과 응답을 전달해 0~1 범위의 정확도 점수를 매겼다고 밝혔다. 문서를 찾는 단계와 문서를 읽어 답하는 단계를 나누어 실패 원인을 살핀 것이다.
기술블로그에 따르면 프롬프트나 도구 매개변수를 바꿀 때도 평가를 돌려 적용 여부를 정했다. 보통 세 번 이상 반복해 평균을 내고 정확도와 함께 시간·토큰·비용을 남겼다. 이는 해당 사내 문서와 평가셋에서 사용하는 운영 절차다. 점수가 좋아졌다는 이유만으로 다른 조직의 문서나 모든 질문에서 같은 품질이 나온다고 보장하지는 않는다.
MCP 명세를 실제 사용 흐름에 맞추다
서빙에는 FastMCP와 Streamable HTTP를 선택했다. 팀은 LLM 호출과 검색 접근 권한을 서버에 두고 여러 사내 클라이언트가 원격으로 연결하게 했다고 설명했다. 에이전트가 청크를 한 번 찾고 바로 답하던 문제에는 서버 instructions로 의미 검색, 주변 계층 조회, 필요한 원문 읽기의 흐름을 안내했다. 공식 MCP 초기화 명세에는 서버가 선택적 instructions를 반환하는 형식이 있다.
팀은 문서 읽기 도구를 여러 문서의 목록 대신 한 문서씩 받도록 바꾸고, 제목이 포함된 경로 대신 고유 ID로 문서를 식별하게 했다. 기술블로그는 이 명세 변경으로 모델에 따라 정확도가 3~9%포인트 움직였다고 밝혔다. 이 수치는 내부 평가의 결과이며, 공식 프로토콜이 그 개선 폭이나 도구 사용 순서의 준수를 보장하는 것은 아니다.
평가 점수에는 정답과 실패 유형을 함께 남기기
ARCH.B의 관점에서 이 사례의 실용적인 부분은 검색이 틀린 경우와 답변이 틀린 경우를 나란히 비교할 수 있다는 데 있다. 정답 문서는 찾았는데 답이 틀렸다면 문맥 구성이나 읽기 과정을 살필 수 있고, 문서 자체가 빠졌다면 적재와 검색을 먼저 확인할 수 있다. 단일 총점만 보면 서로 다른 원인의 변경을 한꺼번에 처리하기 쉽다.
LLM 채점도 검토 가능한 평가 절차여야 한다. 정답의 작성 시점, 심판 모델과 채점 지침을 기록하고 대표적인 오답을 사람이 확인하면 점수 변화의 뜻을 설명하기 쉬워진다. 특히 문서가 갱신되면 기존 정답이 낡을 수 있으므로, 같은 데이터셋에서의 개선과 새 문서에서의 대응력을 따로 살펴야 한다. 반복 평균은 편차를 보는 데 도움이 되지만 평가셋의 편향까지 없애지는 않는다.
도구 설명과 관측 기록도 운영 자산이다
문서 ID 변경은 검색 모델을 교체하지 않고도 오류를 줄일 수 있는 지점을 보여준다. 사람이 읽기 편한 경로에는 슬래시와 표기 규칙이 섞이지만, 도구가 기대하는 식별자는 정확히 일치해야 한다. 모델이 이름을 정리해도 괜찮은 설명 영역과 한 글자도 바꾸면 안 되는 호출 값을 구분해 설계하면 문제를 더 좁은 범위에서 고칠 수 있다.
또한 서버 instructions는 실행을 안내하는 문맥이지 권한이나 강제 절차를 대신하는 장치가 아니다. 중요한 접근 통제는 서버에서 확인하고, 실제 에이전트가 어떤 도구를 호출했는지는 트레이스로 확인해야 한다. 이번 글을 아카이빙할 때도 최종 구성도와 함께 평가셋 버전, 실패 사례, 명세 변경 이유를 남기면 다음 모델이나 문서 범위로 확장할 때 비교할 출발점이 된다.
출처
여기어때 기술블로그의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
사내 지식으로 Agentic RAG 만들기 (3/3) : 관측 가능한 RAG, 운영되는 도구로 (새 창)
