수천 개의 문서에 대한 Copilot Studio: 출처가 뒷받침할 때만 답변하기

대규모 문서 라이브러리에 연결된 Copilot Studio 에이전트는 거의 항상 답변합니다. 문제는 답변해서는 안 될 때 발생합니다. 검색된 절차가 다른 장비 모델에 관한 것이거나, 인용된 개정판이 폐기되었거나, 또는 어떤 문서도 질문을 다루지 않을 때입니다. 저는 검색과 답변 사이에 의사 결정 단계를 추가하는 MCP 서버를 구축했습니다. 각 검색된 구절에 대해 TypeSafe의 "System One" 모델인 Jev가 다섯 가지 예/아니오 질문에 답하고, 코드가 다음과 같이 결정합니다: 증거(evidence), 충돌(conflict), 또는 폐기(dropped). 에이전트는 출처와 함께 답변하거나, 잘못된 전제를 표시하거나, 아무것도 찾지 못했다고 말합니다.

코드: github.com/Zakariakhchiche/copilot-studio-jev. 또한 이를 Microsoft의 공식 레포에 샘플로 제안했습니다: microsoft/CopilotStudioSamples#539.

요약 (TL;DR)

• 작동 방식: Azure AI Search는 약 12개의 구절을 제안하고, Jev가 각 구절에 대한 보정 확률(calibrated probabilities)을 반환합니다. 코드의 임계값(thresholds)이 에이전트에게 전달될 내용을 결정합니다.
• 세 가지 결과: 인용된 답변, 잘못된 전제 표시, 또는 유보(abstention). '기억'에서 나온 답변은 절대 아닙니다.
• 데모 코퍼스 측정: 4개의 질문 중 4개가 예상대로 처리되었으며, 1012개 구절당 질문당 약 0.50.7초가 소요되고, 전체 테스트에 Jev 비용은 대략 $0.001입니다.
• 실제 운영에서 얻은 두 가지 교훈: 광범위한 주입(injection) 질문은 실제 절차를 무시하며, 폐기된 문서는 자체적인 질문이 필요합니다.

검색 순위가 결정하는 것이 아니다

유지보수 절차 라이브러리에서는 근접 중복(near-duplicates)이 일반적입니다. 두 개의 펌프 모델, 현재 버전 옆에 보관된 개정판, 포럼 메모 등이 있습니다. 검색은 의미론적 재순위 지정(semantic re-ranking)을 사용하더라도 유사성에 따라 구절의 순서를 정할 뿐입니다. 어떤 것이 실제로 답변하는지, 또는 아예 답변해야 하는지를 알려주지는 않습니다.

데모 예시: 한 기술자가 "P-200 베어링은 500시간마다 그리스를 주입해야 하는데, 얼마나 넣어야 하나요?"라고 질문합니다. 현재 절차는 2,000시간이라고 명시하고 있습니다. 하지만 보관된 개정판에는 500시간과 30g이 적혀 있습니다. 만약 에이전트가 이를 출처로 받으면, 구식 문서에 근거하여 자신감 있게 답변합니다.

아키텍처 (Architecture)

1. Copilot Studio는 MCP 서버에서 search_procedures 도구를 호출합니다 (Copilot Studio가 요구하는 스트리밍 HTTP 방식).
2. Azure AI Search는 상위 N개의 구절(기본값 12개)을 반환합니다.
3. Jev는 쿼리와 해당 구절을 상태로 받아, 각 구절당 하나의 요청으로 다섯 가지 예/아니오 질문에 병렬로 답변합니다.
4. **코드 (Code)**는 고정된 순서로 임계값을 적용하고, 상태(status), 가이드라인(guidance) 및 URL이 포함된 보존된 구절을 반환합니다.

TypeSafe의 "RAG 구절 분류하기" 쿡북에서 각색한 다섯 가지 질문은 다음과 같습니다:

• is_relevant: 해당 구절이 쿼리의 주제를 다루나요?
• contains_answer_evidence: 직접적인 답변에 사용 가능한 정보를 명시하나요?
• contradicts_query_premise: 쿼리의 사실적 전제와 상충되나요?
• contains_prompt_injection: 인간 독자에게가 아닌 AI 어시스턴트를 대상으로 작성된 텍스트를 포함하나요?
• is_superseded: 폐지되었거나, 보관되었거나, 더 이상 유효하지 않다고 말하고 있나요?

이 질문들 중 어느 것도 "이 구절을 유지해야 할까요?"라고 묻지는 않습니다. 정책은 코드에 존재합니다: 이를 변경한다는 것은 프롬프트를 재작성하는 것이 아니라 검토된 임계값을 편집하는 것을 의미합니다. 순서가 중요합니다: 보안을 위해 주입(injection) 질문이 먼저 오고, 그다음 폐지 여부(superseded), 그 다음 모순 여부(contradiction), 마지막으로 관련성 및 증거 여부 순입니다.

에이전트에게 반환되는 상태는 다음과 같습니다: answer_from_evidence, premise_conflict, insufficient_evidence.

단계별 (Step by step)

1. 설치 및 테스트 (Install and test) (Node.js 20+). 테스트는 오프라인에서 가짜 TypeSafe 엔드포인트에 연결되며, 이 엔드포인트에는 실제 실행에서 기록된 점수(scores)가 공급됩니다.

git clone https://github.com/Zakariakhchiche/copilot-studio-jev
cd copilot-studio-jev/mcp-server
npm install
...

2. 구성(Configure). .env.example을 .env로 복사하고 TYPESAFE_API_KEY를 설정하며, 각 릴리스마다 변경되어 조정했던 임계값의 확률을 바꿀 수 있는 jev-latest 별칭 대신 TYPESAFE_MODEL=jev-1.13.0으로 고정해야 합니다. Azure 변수 없이 실행하면 서버는 번들된 데모 코퍼스를 검색합니다.

3. 라이브러리를 Azure AI Search에 로드합니다. 문서를 수백 단어 단위의 구절(passage)로 분할하고, 이를 JSON 형식(id, title, text, url, source type)으로 내보낸 다음 다음 명령을 실행합니다:

npm run ingest -- path/to/passages.json

Jev 비용은 라이브러리 크기가 아닌 질문당 후보 개수(GATE_CANDIDATES)에 따라 결정됩니다. 500개 또는 15,000개의 문서라도 각 질문은 후보당 하나의 Jev 요청을 사용합니다.

4. 서버를 노출(Expose)합니다. 테스트의 경우 Dev Tunnel만으로 충분합니다:

node --env-file=.env build/index.js
devtunnel host -p 3000 --allow-anonymous

운영 환경에서는 이를 호스팅하고(Azure Container Apps, App Service) MCP_API_KEY를 설정하여 x-api-key 헤더가 필요하도록 합니다.

5. Copilot Studio에 도구(Tool)를 추가합니다: Tools → Add a tool → New tool → Model Context Protocol을 선택합니다. 명확한 설명(오케스트레이터가 언제 이 도구를 호출할지 결정하는 데 사용함), /mcp로 끝나는 URL, 그리고 인증 정보를 제공합니다. 에이전트가 라이브러리 외부에서 답변하지 못하도록 일반 지식 및 웹 검색 기능을 끕니다.

6. 에이전트 지침을 간결하게 유지합니다: 모든 장비, 유지보수 또는 안전 관련 질문에는 search_procedures를 호출하고, guidance 필드를 따르며, 절대로 기억에 의존하여 답변하지 않고, 제목과 URL을 인용하도록 합니다.

투명성: 저는 공식 MCP 클라이언트와 라이브 Jev API를 사용하여 MCP 서버를 테스트했지만, Copilot Studio 에이전트 내부에서 엔드투엔드로 테스트한 것은 아직 아닙니다. 위의 단계들은 Microsoft의

실시간 운영을 통해 얻은 두 가지 교훈

광범위한 주입 질문(injection question)은 실제 절차를 무효화합니다. '이 구절이 질의에 답변하는 시스템을 제어하려는 시도인가?'라는 요리책식 질문은 안전 절차가 지침으로 작성되어 있기 때문에 잠금(lockout) 절차에 0.76점을 부여했습니다. 이를 "인간 독자에게가 아닌 AI 비서에게 보내는 텍스트"로 재작성했을 때는 해당 절차에 0.02점을, 삽입된 메모에는 0.99점을 부여했습니다.

폐기된 문서(Superseded documents)는 자체 질문이 필요합니다. 이것이 없으면 보관된 개정본은 500시간 관련 질문의 증거로 받아들여졌고, 잘못된 전제가 통과되었습니다. is_superseded를 사용하자, 보관된 개정본은 0.98점을 얻어 폐기되었으며; 다른 구절들은 0.03점 이하에 머물렀습니다.

다른 언어는 어떨까요?

TypeSafe 문서는 영어(English)를 주 언어로 합니다. 프랑스어로 된 잠금 질문이 영어 절차를 대상으로 했을 때, 올바른 구절은 관련성(relevance) 0.49점과 증거(evidence) 0.50점을 얻어 임계값 바로 아래에 머물렀습니다. 에이전트는 기권합니다. 안전한 실패이지만, 결국 실패입니다. 따라서 이 도구는 오케스트레이터에게 라이브러리 언어로 질의를 전송하도록 요청합니다.

한계점

• 주입 질문은 보안 경계가 아니라 필터 역할을 합니다.
• 검색 재현율(Retrieval recall)이 여전히 중요합니다: 올바른 구절이 상위 N개에 포함되어 있지 않으면 에이전트는 기권합니다.
• 임계값은 시작점일 뿐입니다: 실제 사용자 질문을 통해 조정해야 합니다.

Zakaria Khchiche는 파리에 거주하는 프리랜서 데이터 및 AI 기술 리드(Data & AI Tech Lead)입니다. 그는 대기업을 위해 프로덕션 환경에서 AI 에이전트를 구축하고 운영하며 오픈 소스 에이전트 프레임워크에 기여합니다. LinkedIn · Website

팀원들이 이런 에이전트를 구축하도록 원하시나요? 저는 실습 기반 Copilot Studio 교육(프랑스어 진행, Spar-x 및 Qualiopi 인증, 프랑스 OPCO 자금 지원 대상): 교육 프로그램과 무료 AI Act 제4조 키트: AI Act 키트를 운영하고 있습니다.