월요일에 상품 카탈로그가 바뀌었다고 가정합니다. 어시스턴트의 프롬프트에는 여전히 금요일 목록이 있습니다. 팀이 프롬프트를 고칩니다. 하지만 모델 학습에 사용된 예시에도 오래된 목록이 하나 더 있습니다. 어시스턴트는 이제 같은 대화에서 최신 답과 낡은 답을 번갈아 냅니다.
예시적인 실패지만 원인은 흔합니다. 같은 사실의 보관 장소가 둘 이상 생긴 것입니다.
프롬프트, 검색, 모델 가중치에 관한 강연은 유용한 경계를 그립니다. 프롬프트는 어시스턴트의 행동을 정하고, 검색은 현재의 출처를 밝힐 수 있는 지식을 개별 과제에 가져옵니다. 모델 조정은 안정적인 패턴을 가르칠 수 있습니다. 이 셋을 프롬프트에서 검색으로, 그래도 답이 틀리면 미세 조정으로 올라가는 사다리로 보면 사실 오류를 잘못 진단합니다.
프롬프트는 카탈로그로 부적합합니다
프롬프트는 수정하기 쉬워 매력적입니다. 문단을 추가하면 다음 요청에 포함됩니다. 하지만 편의 뒤에는 두 가지 비용이 숨어 있습니다. 관련 없는 호출에서도 그 사실을 매번 보냅니다. 또 긴 프롬프트에서는 모델이 어느 규칙 사본을 사용했는지 알기 어렵습니다.
“캠페인을 보내기 전에 승인받기”처럼 오래 유지될 행동 지침은 에이전트 가까이에 둬야 합니다. 반면 이 매장의 현재 사용자 정의 필드 목록은 다릅니다. 계정 관리자가 속성을 추가하면 바뀌고, 테넌트마다 다를 수 있으며 한 워크스페이스에는 보이고 다른 곳에는 금지될 수 있습니다.
Brevo 커넥터 가이드는 연락처 동기화에서 필드 정의가 왜 중요한지 보여 줍니다. 대상 계정에 속성이 선언되지 않았다면 이름만 보고 그럴듯하게 만든 매핑으로 의도한 필드가 생기지 않을 수 있습니다. 에이전트는 학습에서 일반적인 필드 목록을 떠올리지 말고 그 계정의 현재 계약을 조사해야 합니다.
유용한 검색 결과는 반박할 수 있을 만큼 작아야 합니다. 어느 계정이나 테넌트에 적용되는지, 언제 읽었는지, 어떤 작업이나 필드를 설명하는지 나타냅니다. 서로 다른 검색 문구가 충돌한다면 더 유창한 쪽을 조용히 고르지 말고 충돌을 드러내야 합니다. 다음 단계는 프롬프트를 더 강하게 쓰는 것이 아니라 새 조회나 검토일 수 있습니다.
사실과 그 범위를 함께 가져옵니다
유용한 지식 기록은 텍스트 이상을 담습니다. 출처, 버전이나 조회 시각, 계정 범위, 제거하거나 바꿀 명확한 방법이 있어야 합니다. 한 매장 계정에서 찾은 필드 정의를 다른 매장에도 적용되는 보편 규칙으로 삼아서는 안 됩니다.
연락처 속성에 관한 질문은 답하는 데 필요한 가장 작은 부분만 가져올 수 있습니다. 필드 이름과 형식, 존재하는 계정이 그것입니다. 답은 출처를 다시 가리킬 수 있습니다. 매핑이 실패하면 사실이 낡았는지, 다른 계정의 결과를 가져왔는지, 모델이 올바른 문구를 오해했는지 확인할 수 있습니다.
각각 수리 방법이 다릅니다. 테넌트 경계를 넘는 검색 필터는 프롬프트 수정으로 고칠 수 없습니다. 더 큰 모델도 아무도 가져오지 않은 속성 정의를 제공할 수 없습니다.
MCP 설명은 에이전트가 도구를 조회하는 방법을 다룹니다. 도구는 관련 계약을 돌려주고 애플리케이션은 누가 볼 수 있는지 강제해야 합니다. “다른 테넌트 내용을 밝히지 마라”는 텍스트 지침은 범위를 제한한 조회를 대신하지 못합니다.
이런 분리는 수리도 빠르게 합니다. 대상 필드의 이름이 바뀌면 스키마 출처를 업데이트하고 영향을 받는 매핑을 무효화합니다. 안정적인 지침을 에이전트가 반복해서 오해하면 지침을 바꾸거나 표적 학습을 시험합니다. 검색기가 잘못된 계정을 고른 경우 모델 가중치를 고쳐도 원인은 남습니다. 오류의 종류마다 담당자와 수리 경로가 다릅니다.
- 지속되는 지침
어시스턴트의 행동 방식
- 범위 제한 검색 계정 · 버전 · 시각
지금 사실인 내용
- 매핑 판단
이번 과제에 현재 사실 사용
- 제약이 적용되는 쓰기
코드가 허가와 범위를 확인
패턴이 안정된 뒤 가르칩니다
“계속 사용하는 사실이라면 작은 모델에 학습시키면 되지 않는가?”라는 반론은 타당합니다. 반복만으로는 부족합니다. 모델을 업데이트하는 간격 동안 사실이 맞아야 하고 모델이 문맥을 구분할 수 있어야 합니다.
안정된 분류 방식은 언젠가 조정할 가치가 있습니다. 공급업체의 현재 필드 목록은 부적합합니다. 드물게 바뀌더라도 오래된 답 하나가 많은 레코드에 잘못된 매핑을 퍼뜨릴 수 있습니다. 사람이 조사하고 수정할 수 있는 곳에 사실을 둡니다.
출처의 강연은 모든 추론 실패를 검색으로 해결하지 말라고도 경고합니다. 모델이 관련 문서 두 개를 올바르게 비교하지 못한다면 50개를 더 줘도 비교를 배우지 못합니다. 먼저 올바른 부분이 왔는지 묻고 다음으로 그 부분에 대한 판단이 건전했는지 묻습니다.
연동을 만드는 사람에게는 수리 순서가 생깁니다. 잘못된 주장을 찾고 검색된 필드나 API 부분을 살피며 계정과 버전을 확인합니다. 필요하면 출처나 검색 경로를 고치고 판단을 다시 시험합니다. 그 후에야 모델 변경을 고려합니다.
실제 지식 계층을 유지하는 비용은 있습니다. 출처 업데이트, 접근 검사, 인용이 필요합니다. 얻는 것은 한곳에서 고칠 수 있는 사실입니다.
변한 계약을 모델이 잊을 때까지 기다리게 해서는 안 됩니다.
자주 묻는 질문
에이전트 프롬프트에는 무엇이 들어가야 합니까?
행동과 경계에 관한 작고 오래 유지되는 지침입니다. 변하는 카탈로그, 테넌트별 필드 목록, 최신 공급업체 규칙은 필요할 때 허용된 출처에서 가져와야 합니다.
현재 문서로 모델을 미세 조정하면 안 됩니까?
변하는 사실이 조사하고 수정하기 어려운 가중치에 들어갈 수 있습니다. 판단 시점에 올바른 문서를 가져와 인용했는지 먼저 확인합니다.
잘못된 사실 답변은 어떻게 수리합니까?
원본 문서와 버전, 검색 필터, 반환된 문구를 조사합니다. 모델을 바꾸기 전에 사실이나 검색 경로를 바로잡습니다.