로드리고 디에고(Rodrigo Diego)는 2026년 7월 31일 품질관리 제품의 문서 검색 코파일럿이 특정 인물이 작성한 문서 수를 묻는 질문에 잘못 답했다고 밝혔다. 데이터베이스의 실제 집계는 84건이었지만, RAG 코파일럿은 기록 원장이 아니라 검색, 필터링, 표시 처리 뒤 자신이 볼 수 있는 문서를 기준으로 답했다.

이 코파일럿은 LangGraph와 Bedrock으로 만든 멀티 에이전트 시스템이었다. “X가 작성한 문서” 같은 메타데이터 질문에서 검색 에이전트는 문서 서비스에 질의하고, 결과를 재정렬하며, 보기 권한 게이트를 적용하고, 여러 문서 버전을 카드 1개로 합친 뒤 최대 30개 결과를 표시했다. 이 단계들은 검색에는 적절했지만 “몇 개냐”의 의미를 바꿨다. SQL은 실제 총계 84건을 갖고 있었고, 검색은 제한된 top-k 행만 반환했으며, 권한 검사는 보이는 행을 줄였고, 버전 병합은 한 문서의 5개 버전을 카드 1개로 만들었으며, 최종 표시 집합은 항상 최대 30개였다.

이 실패는 답이 그럴듯해 보여 충돌보다 발견하기 어려웠다. 27건처럼 제한되고 중복 제거된 집계도 품질관리 업무에서는 보고서에 넣을 만한 숫자로 보일 수 있었다. 디에고는 LLM이 개수, 합계, “가장 최근” 값 같은 집계를 계산해서는 안 되며, 기록 원장이 이를 계산하고 모델은 결과를 문장으로 표현해야 한다고 주장했다.

문서 서비스는 이미 필터링된 각 질의와 함께 실제 총계를 반환했고, 검색 노드는 이를 `total_available_results`로 저장했다. 이후 권한 게이트 노드는 같은 필드를 다른 의미, 즉 사용자에게 표시되는 보기 권한 통과 및 버전 병합 완료 카드 수로 재사용했다. 주석에는 UI 집계가 표시 카드와 일치해야 한다고 되어 있었고, 예컨대 5개 버전이 4개 문서가 되는 식이었다. 그러나 공유 상태 필드는 상류에서는 “데이터베이스의 일치 항목”, 하류에서는 “화면의 카드”를 뜻하게 됐다.

디에고의 수정은 30개 카드 제한과 버전 병합 이전 문서 서비스의 실제 일치 총계를 담는 별도 권위 필드 `total_matching_records`를 추가했다. 기존 `total_available_results` 필드는 표시 카드와 페이지네이션에 묶어 뒀다. 이에 따라 결과 노드는 `total_matching_records`를 사용해 “일치 문서 84건 중 5건 표시” 같은 사용자용 헤드라인과 전체 84개 문서가 일치한다는 도구 메시지를 생성했다.

에이전트 프롬프트도 모델이 “몇 개” 질문에 답할 때 제한이 걸린 표시 카드 수가 아니라 도구가 보고한 권위 있는 총계를 쓰도록 지시했다. 디에고는 실제 숫자를 에이전트 컨텍스트와 UI 헤드라인 양쪽에 넣는 구조라고 설명했다. 따라서 모델이 지시를 무시하더라도 인터페이스는 답변 옆에 데이터베이스 집계를 보여준다.

테스트 3개는 변경 사항을 검증했다. 표시된 문서보다 더 많은 문서가 일치하면 집계 안내가 나타나고, 모든 문서가 표시되면 사라지며, 콘텐츠 전용 의미 검색에는 절대 나타나지 않는다. 의미 검색 사례는 similarity ranking(의미의 가까운 정도로 정렬) 때문에 정확한 일치 집합이 없으므로, 정확한 숫자를 제시하면 오해를 부를 수 있다.

같은 릴리스는 “지난 10일 동안 생성된 문서” 같은 질문과 관련된 날짜 버그도 수정했다. 모델은 상대 날짜를 필터로 바꾸기 위해 현재 날짜가 필요했기 때문에, 디에고는 모든 모델 호출에 오늘의 UTC 날짜를 주입하고 “today”, “yesterday”, “the last 10 days”, “since March”를 필터 생성 전에 구체적인 ISO-8601 날짜로 풀도록 지시하는 LangGraph 미들웨어를 추가했다.

미들웨어는 날짜를 저장된 대화 기록에 붙이지 않는다. “today is 2026-07-30” 같은 저장 문장은 다음 주에 대화를 재개하면 오래된 정보가 되기 때문이다. 디에고는 남은 한계도 제시했다. 모델의 문장이 권위 있는 집계를 쓰도록 강제하는 장치는 없고, 콘텐츠 전용 검색은 여전히 표시 집계로 되돌아가며, 합계, 평균, “어느 작성자가 가장 많은가” 같은 질문에는 서비스 쪽의 실제 집계 엔드포인트가 필요하다.

로드리고 디에고(Rodrigo Diego)는 2026년 7월 31일 품질관리 제품의 문서 검색 코파일럿이 특정 인물이 작성한 문서 수를 묻는 질문에 잘못 답했다고 밝혔다. 데이터베이스의 실제 집계는 84건이었지만, RAG 코파일럿은 기록 원장이 아니라 검색, 필터링, 표시 처리 뒤 자신이 볼 수 있는 문서를 기준으로 답했다.

이 코파일럿은 LangGraph와 Bedrock으로 만든 멀티 에이전트 시스템이었다. “X가 작성한 문서” 같은 메타데이터 질문에서 검색 에이전트는 문서 서비스에 질의하고, 결과를 재정렬하며, 보기 권한 게이트를 적용하고, 여러 문서 버전을 카드 1개로 합친 뒤 최대 30개 결과를 표시했다. 이 단계들은 검색에는 적절했지만 “몇 개냐”의 의미를 바꿨다. SQL은 실제 총계 84건을 갖고 있었고, 검색은 제한된 top-k 행만 반환했으며, 권한 검사는 보이는 행을 줄였고, 버전 병합은 한 문서의 5개 버전을 카드 1개로 만들었으며, 최종 표시 집합은 항상 최대 30개였다.

이 실패는 답이 그럴듯해 보여 충돌보다 발견하기 어려웠다. 27건처럼 제한되고 중복 제거된 집계도 품질관리 업무에서는 보고서에 넣을 만한 숫자로 보일 수 있었다. 디에고는 LLM이 개수, 합계, “가장 최근” 값 같은 집계를 계산해서는 안 되며, 기록 원장이 이를 계산하고 모델은 결과를 문장으로 표현해야 한다고 주장했다.

문서 서비스는 이미 필터링된 각 질의와 함께 실제 총계를 반환했고, 검색 노드는 이를 `total_available_results`로 저장했다. 이후 권한 게이트 노드는 같은 필드를 다른 의미, 즉 사용자에게 표시되는 보기 권한 통과 및 버전 병합 완료 카드 수로 재사용했다. 주석에는 UI 집계가 표시 카드와 일치해야 한다고 되어 있었고, 예컨대 5개 버전이 4개 문서가 되는 식이었다. 그러나 공유 상태 필드는 상류에서는 “데이터베이스의 일치 항목”, 하류에서는 “화면의 카드”를 뜻하게 됐다.

디에고의 수정은 30개 카드 제한과 버전 병합 이전 문서 서비스의 실제 일치 총계를 담는 별도 권위 필드 `total_matching_records`를 추가했다. 기존 `total_available_results` 필드는 표시 카드와 페이지네이션에 묶어 뒀다. 이에 따라 결과 노드는 `total_matching_records`를 사용해 “일치 문서 84건 중 5건 표시” 같은 사용자용 헤드라인과 전체 84개 문서가 일치한다는 도구 메시지를 생성했다.

에이전트 프롬프트도 모델이 “몇 개” 질문에 답할 때 제한이 걸린 표시 카드 수가 아니라 도구가 보고한 권위 있는 총계를 쓰도록 지시했다. 디에고는 실제 숫자를 에이전트 컨텍스트와 UI 헤드라인 양쪽에 넣는 구조라고 설명했다. 따라서 모델이 지시를 무시하더라도 인터페이스는 답변 옆에 데이터베이스 집계를 보여준다.

테스트 3개는 변경 사항을 검증했다. 표시된 문서보다 더 많은 문서가 일치하면 집계 안내가 나타나고, 모든 문서가 표시되면 사라지며, 콘텐츠 전용 의미 검색에는 절대 나타나지 않는다. 의미 검색 사례는 similarity ranking(의미의 가까운 정도로 정렬) 때문에 정확한 일치 집합이 없으므로, 정확한 숫자를 제시하면 오해를 부를 수 있다.

같은 릴리스는 “지난 10일 동안 생성된 문서” 같은 질문과 관련된 날짜 버그도 수정했다. 모델은 상대 날짜를 필터로 바꾸기 위해 현재 날짜가 필요했기 때문에, 디에고는 모든 모델 호출에 오늘의 UTC 날짜를 주입하고 “today”, “yesterday”, “the last 10 days”, “since March”를 필터 생성 전에 구체적인 ISO-8601 날짜로 풀도록 지시하는 LangGraph 미들웨어를 추가했다.

미들웨어는 날짜를 저장된 대화 기록에 붙이지 않는다. “today is 2026-07-30” 같은 저장 문장은 다음 주에 대화를 재개하면 오래된 정보가 되기 때문이다. 디에고는 남은 한계도 제시했다. 모델의 문장이 권위 있는 집계를 쓰도록 강제하는 장치는 없고, 콘텐츠 전용 검색은 여전히 표시 집계로 되돌아가며, 합계, 평균, “어느 작성자가 가장 많은가” 같은 질문에는 서비스 쪽의 실제 집계 엔드포인트가 필요하다.