Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / Copilot Studio를 위한 Context Engineering: Power Platform에서 환각과 드리프트를 막는 방법 (AI 더빙)

Transcript

Copilot Studio를 위한 Context Engineering: Power Platform에서 환각과 드리프트를 막는 방법 (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

0:00
여러분의 코파일럿은 멍청하지 않습니다.
0:01
여러분이 굶주리게 했을 뿐이죠.
0:03
스키마도, 규칙도, 가이드라인도 없으면서
0:05
환각현상만 탓하고 있군요.
0:07
진실이 뭘까요?
0:08
대부분의 파워 플랫폼 AI 실패는 모델 지능의 문제가 아닙니다.
0:12
여러분이 만든 맥락의 문제입니다.
0:13
오늘 여러분이 얻게 될 내용은 다음과 같습니다.
0:16
코파일럿 스튜디오와 파워 오토메이트를 위한
0:18
반복가능한 컨텍스트 엔지니어링 패턴으로
0:20
환각을 없애고 테넌트 간 편차를 수정하며
0:22
지연 시간과 비용을 획기적으로 줄여줍니다.
0:24
시스템 메시지 패턴, 스키마 그라운딩 체크리스트,
0:27
검색 파이프 라인 템플릿을 구축할 것입니다.
0:30
모두가 간과하는 한 가지 레이어,
0:31
바로 거버넌스 편차를 방지하는 정책 레이어입니다.
0:34
이를 연결하고 전후 지표를 통해 증명해 보이겠습니다.
0:37
이제 시작합니다.
0:38
문제는 왜 코파일럿이 실패하는가?
0:40
바로 컨텍스트 부채입니다.
0:41
문제를 정확히 정의해보죠.
0:43
컨텍스트 부채입니다.
0:44
이는 언어모델이 추측하게 만드는 누락되거나
0:47
부실한 맥락의 누적입니다.
0:49
시스템 규칙을 건너뛰고 데이터버스에 그라운딩하지 않으며
0:52
도구를 정의하지 않고 정책을 무시합니다.
0:54
그러고는 테넌트마다 출력이 흔들리면 놀라곤 하죠.
0:57
참 흥미롭군요.
0:58
컨텍스트 부채는 4가지 실패로 나타납니다.
1:01
첫째, 시스템 규칙 부채입니다.
1:03
정체성도, 범위도, 거부정책도 없습니다.
1:05
모델은 준수와 정밀함이 아닌
1:06
도움을 주고 장황하게 말하는 것에 최적화됩니다.
1:09
둘째, 그라운딩 되지 않은 데이터입니다.
1:11
엔티티의 이름, 필드의 정의, 관계, 샘플 레코드도
1:14
제공하지 않은 채 대출 테이블만 쳐다봅니다.
1:16
셋째, 정의되지 않은 도구입니다.
1:19
상태 업데이트를 요청하지만
1:20
파워 오토메이트에서 관리되는 작업 경로는 노출하지 않습니다.
1:23
넷째, 정책의 부재입니다.
1:25
DLP, 민감도 레이블, 조건부 액세스 대신 느낌에만 이전합니다.
1:29
그런 맥락은 편차를 보장할 뿐입니다.
1:31
증거는 어디에나 있습니다.
1:33
엔터프라이즈 AI 위 높은 실패율과 이탈률은
1:35
모델의 한계가 아니라 실행과 맥락에 기인합니다.
1:37
팀들은 환각현상, 환경별 불일치,
1:40
그리고 안전을 위해 전체 테이블을 과도하게 가져오느라
1:42
발생하는 토큰 낭비를 보고합니다.
1:43
더 큰 모델이 필요한 게 아니라 뼈대가 필요합니다.
1:46
이를 해결할 정신적 모델을 소개합니다.
1:48
시스템, 검색, 도구, 정책이라는 4가지 맥락 레이어입니다.
1:51
에이전트를 위한 윈도우 레지스트리라고 생각하세요.
1:54
단순한 데이터베이스가 아니라 뼈대입니다.
1:56
시스템은 에이전트가 누구인지, 무엇을 거부할지 선언합니다.
1:59
검색은 사실과 스키마를 제공하여 필드를 마음대로 지어내지 않게 합니다.
2:02
도구는 최소 권한 원칙에 따라 수행할 수 있는 정확한 작업만을 노출합니다.
2:06
정책은 영리한 프롬프트와 상관없이 경계를 강제합니다.
2:08
어느 한 레이어라도 제거하면 출력은 흔들립니다.
2:11
4가지를 모두 추가하면 출력이 고정됩니다.
2:13
대부분의 개발자가 놓치는 사실, 환경은 파워 플랫폼 위 보안 경계입니다.
2:16
운영 환경에서는 비즈니스와 비 비즈니스 커넥터 혼합을 차단하는 DLP 정책이 개발 환경에서는 적용되지 않는다면 두 개의 다른 우주를 만든 셈입니다.
2:22
여러분의 에이전트가 보는 눈과 손이 환경에 따라 달라지게 됩니다.
2:25
네, 맞습니다.
2:26
환경과 테넌트 전반에서 결과가 달라지는 이유는 여러분이 그 기반이 되는 환경을 계속 바꾸기 때문입니다.
2:30
전형적인 실패 과정을 자세히 설명해드리겠습니다.
2:32
여러분은 코파일럿 스튜디오 에이전트를 만듭니다.
2:34
대출 신청을 도와달라는 식의 모호한 목표를 부여하죠.
2:37
구조를 추출하지 않은 채 PDF 문서 라이브러리를 연결합니다.
2:40
데이터버스 엔터티, 관계, 보안 네이블을 인덱싱하지 않습니다.
2:44
도구 카탈로그를 건너 뛰고 코파일럿이 알아서 해결할 것이라고 가정합니다.
2:48
그런 다음 질문을 던집니다.
2:49
그러면 에이전트는 일반적인 정책 이야기만 늘어놓고 스키마에 존재하지도 않는 대출 단계 라는 필드를 지어내어 답변합니다.
2:54
축하합니다.
2:54
잘못된 내용을 읽는데 토큰 비용을 지불하고 엉터리 답변을 얻으셨네요.
2:58
이제 기반을 다진 접근 방식과 비교해보죠.
3:00
똑같은 질문을 하더라도 검색계층의 스키마 인덱스, 대출 신청 엔터티, 상태 필드, 선택 목록값, 신청자 및 문서와의 관계, 그리고 샘플 레코드가 포함되어 있습니다.
3:10
에이전트는 대출 신청 상태를 명확히 참조하고 허용된 값을 인용합니다.
3:14
추측은 없습니다.
3:15
차이는 모델이 아니라 컨텍스트에 있습니다.
3:17
지연 시간과 비용은 동일한 기술 부채의 증상입니다.
3:20
필드 수준의 필터가 없어서 전체 테이블을 과도하게 가져오면 토큰과 시간이 폭발적으로 증가합니다.
3:24
모호한 검색은 모델이 관련 없는 정보들을 헤매게 만듭니다.
3:27
정의되지 않은 탑, 탑은 위도 필터링을 할 수 없습니다.
3:29
모든 것에 비용을 지불하고도 아무것도 배우지 못하며 여전히 환각현상을 겪게 됩니다.
3:32
가혹하죠.
3:33
거버넌스 드리프트는 조용한 살인자입니다.
3:36
정책계층, DLP, 보안 네이블, 조건부 액세스가 없으면 에이전트의 동작은 점차 달라집니다.
3:41
커넥터가 재분류되고 게스트 계정이 플로우에 몰래 들어오고 로그가 꺼지면 에이전트는 민감한 메모를 비즈니스 용이 아닌 커넥터로 기쁘게 요약해버립니다.
3:48
감사주관이 되어서야 비로소 알아차리게 되죠.
3:50
참 훌륭하네요.
3:51
해결책을 알려드리겠습니다.
3:53
이 시리즈에서 단계별로 구축해보겠습니다.
3:55
시스템 계층입니다.
3:56
정체성, 범위, 거절, 스키마 인식, 도구 사용 규칙, 로깅 경계를 인코딩하는 간결한 버전 관리 시스템 메시지입니다.
4:03
환경별로 작성하며 비즈니스 단위 및 민감도 맵핑을 위한 토큰을 포함합니다.
4:07
검색 계층입니다.
4:09
엔터티 인식 천킹, 하이브리드 검색, 보안 트리밍, 필드 수준 필터를 사용하여 데이터버스를 기본으로 하고 문서 인덱스를 보조 소스로 삼는 파이프라인입니다.
4:19
도구 계층입니다.
4:20
최소 권한 원칙에 따라 입력 스키마, 거절 논리, 민감도 플래그를 정의하는 프롬프트 템플릿이 포함된 파워 오토메이트 작업에 엄선된 카탈로그입니다.
4:28
정책 계층입니다.
4:29
적용된 dlp 그룹, 조건부 액세스, 네이브를 통한 실시간 마스킹, 그리고 관리자 강제 종료 스위치입니다.
4:34
바른 건 다 잊어도 이것만은 기억하십시오.
4:36
모델은 텍스트를 예측할 뿐입니다.
4:38
진실과 권한, 그리고 경계는 여러분이 직접 설계해야 합니다.
4:40
여러분의 역할은 컨텍스트를 제공하는 것입니다.
4:42
모델은 렌더링 엔진일 뿐입니다.
4:43
청사진이 없는 것을 렌더러 탓으로 돌리지 마십시오.
4:46
첫 번째 계층, 변하지 않는 시스템 컨텍스트, 패턴과 체크리스트입니다.
4:49
이제 추측은 멈추고 정체성을 확립합시다.
4:52
명확한 정체성 범위와 거부 규칙이 없으면 거대 언어모델은 기본적으로 모든 것을 가져오고
4:56
모두를 기쁘게 하려다 규정을 위반하는 매력적인 리트리버처럼 행동하게 됩니다.
5:00
골든 리트리버가 아니라 문지기가 필요합니다.
5:03
진실은 시스템 메시지가 모호하면 출력도 모호해진다는 것입니다.
5:06
환경별로 시스템 메시지가 일관되지 않으면 환경마다 출력값이 달라질 것입니다.
5:10
그래서 우리는 핵심 뼈대부터 작성합니다.
5:12
제가 사용하는 패턴은 다음과 같습니다.
5:14
짧고 버전 관리가 되며 냉철합니다.
5:16
역할, 당신은 환경 이름, 환경의 사업 부서를 위한 대출 운영고 파일럿입니다.
5:21
대출 신청 및 관련 절차에 대해서만 답변하십시오.
5:25
범위, 이 환경에 데이터버스 엔터티와 레이블이 지정된 문서만 사용하십시오.
5:29
답변에 외부 시스템이나 레이블이 없는 콘텐츠가 필요하면 거부하고 안전한 다음 단계를 제한하십시오.
5:35
어조, 간결하고 사실에 입각하며 스키마에 따라 필드를 정확히 인용하십시오.
5:39
엔터티, 필드, 거부 정책, 비즈니스의 맥락에서
5:42
레이블 목록으로 표시된 민감한 콘텐츠를 요청받으면 이유를 밝혀 거부하고 거부 요약을 잠그십시오.
5:49
스키마 인식, 데이터버스 스키마 인덱스를 우선하십시오.
5:52
절대 필드를 지어내지 마십시오.
5:54
제공된 용어집을 사용하여 동의어를 표준 이름으로 맵핑하십시오.
5:59
도구 사용 규칙
6:00
위도가 80% 이상의 확신으로 실행 가능하다고 분류될 때만 승인된 파워 오토메이트 작업을 호출할 수 있습니다.
6:07
그렇지 않으면 분석 내용을 응답하십시오.
6:09
로깅 경계, 개인정보, PII를 출력하지 마십시오.
6:13
민감도가 높을 때는 값을 마스킹 처리하여 요약하십시오.
6:16
이 패턴은 코파일러 스튜디오의 사용자 지정 지침에 적용됩니다.
6:19
네, 환경 이름, 사업 부서, MIP 레이블 목록을 매개 변수화합니다.
6:23
이를 환경 변수에 연결하여 개발, 테스트, 운영 환경에서 동일한 로직을 다른 바인딩으로 공유하게 하십시오.
6:28
버전을 지정하십시오. 시스템 메시지 v1.3, 테스트 및 정책 v1.3 단계 동안 모든 응답 하단의 버전을 표시하여 변경 사항을 즉시 확인할 수 있게 하십시오.
6:36
이제 체크리스트입니다. 그렇지 않으면 무언가 잊어버릴 테니까요.
6:40
목표, 에이전트가 달성해야 할 작업을 한 문장으로 정의합니다.
6:43
대상, 누구를 위한 것인가?
6:45
전체 회사가 아닌 대출 담당자, 정의, 표준 엔터티 및 필드 이름과 그 동의어, 허용된 콘텐츠, 허용되는 데이터 클래스 및 소스, 허용되지 않는 작업,
6:55
페넌트 간 데이터, 네이블 없는 정보, 비즈니스 커넥터 외위 모든 것, 에스컬레이션 경로, 사람에게 인계해야 할 시점, 기준 및 메시지 템플릿, 평가 루 브릭, 출력을 평가하는 방법, 필드 정확도, 거부 적절성, 스키마 인용 여부, 이를 쉬운 언어로 작성한 뒤 압축하십시오.
7:12
가장 흔한 실수는 정책 텍스트라는 소설 속에 제약사항을 파묻어 버리는 것입니다.
7:16
모델은 평범한 인턴처럼 내용을 훑어볼 것입니다.
7:18
수술하듯 정교하게 유지하십시오.
7:19
또 다른 고전적인 오류, 사용자 프롬프트에 제약사항을 채워넣는 것, 아닙니다.
7:23
제약사항은 시스템 메시지와 도구 래퍼에 있어야 합니다.
7:26
사용자가 타이핑하는 곳 어디든 넣어서는 안 됩니다.
7:28
그리고 환경별로 버전을 관리하십시오.
7:29
개발 환경은 유연할 수 있습니다.
7:31
운영 환경은 그럴 수 없습니다.
7:32
토큰 없이 테넌트 간의 단일 시스템 파일을 복사하면 평행우주가 생성됩니다.
7:37
오늘 바로 할 수 있는 빠른 해결책입니다.
7:39
메시지를 변수로 템플릿화하고 솔루션 가져오기 시 바인딩하세요.
7:41
그것만으로도 수많은 불일치 문제를 해결할 수 있습니다.
7:44
일반적인 동의어를 표준 필드, 단계, 스텝, 국면, 대출 신청 상태 등
7:48
앱 애핑하는 용어집 섹션을 추가하세요.
7:50
환각 필드가 사라지는 것을 보게 될 것입니다.
7:52
포파일러 스튜디오에서의 구현은 간단합니다.
7:55
사용자 지정 지침을 열고 패턴을 붙여넣은 뒤
7:57
환경 이름, 비즈니스 단위, 이미지 레이블 목록에 대한 변수를 삽입하고
8:02
항상 포함을 켭니다.
8:03
에이전트가 답변하기 전에 참조할 스키마 표준화를 위한 지침 세트 메모를 만듭니다.
8:08
그런 다음 거부 템플릿 문단을 추가하세요.
8:10
정책 레이블로 인해 편집된 내용은 공유할 수 없습니다.
8:14
여기 안전한 대안이 있습니다.
8:16
일관성은 마법이 아니라 템플릿입니다.
8:18
마지막 안전장치, 로깅 경계입니다.
8:21
에이전트가 민감한 원본 값을 절대 반복하지 않도록 표시하세요.
8:24
값을 참조해야 할 때는 자리 표시자를 사용하고
8:26
흐름 내 자격 증명 작업을 통해 비밀을 처리하는 도구 동작을 제공합니다.
8:30
다른 것은 다 잊어도 이것만은 기억하세요.
8:32
식결, 범위, 거부, 스키마, 도구, 로깅, 6개의 라인, 문제 해결 완료.
8:37
두 번째 계층, 파이프라인 템플릿에 데이터버스에 기반을 둔 검색입니다.
8:41
식별이 설정되었습니다.
8:43
이제 환각을 일으킬 수 없는 사실 정보를 제공합니다.
8:45
검색은 대부분의 사용자가 무차별적으로 데이터를 쏟아 부으며 이를 근거 마련이라 부르는 단계입니다.
8:49
잘못된 방식입니다.
8:50
검색은 선택적이어야 하고, 엔티티를 인식해야 하며, 진실이 존재하는 데이터버스를 우선시해야 합니다.
8:56
이것이 중요한 이유입니다.
8:57
모델이 구조를 추론해야 할 때 환각이 발생합니다.
9:00
표준 엔티티와 필드 정의를 볼 수 없으면 모델은 그것을 지어냅니다.
9:04
위도에 따라 필터링하지 않고 전체 테이블과 PDF 덩어리를 밀어넣으면 지연 시간과 비용이 급증합니다.
9:09
그 결과는 비싼 노이즈일 뿐입니다.
9:11
해결책은 스키마를 우선시하고, 보안에 따라 데이터를 다듬는 파이프라인입니다.
9:14
여기 템플릿이 있습니다.
9:16
두 개의 인덱스, 하나의 두뇌, 첫째, 데이터버스 엔티티, 필드, 관객, 옵션 세트, 비즈니스 규칙 및 소규모 동의어 용어집을 위한 스키마 인덱스입니다.
9:24
둘째, 정책.
9:25
SOP 및 참조 문서는 구조화된 후에만 문서 인덱스에 포함합니다.
9:28
환경 및 사용자에 따른 보안 필터링을 포함한 하이브리드 검색을 수행하세요.
9:32
모델은 사용자가 볼 권한이 없는 정보를 절대 보지 못합니다.
9:35
이것은 제한이 아니라 경계입니다.
9:37
스키마 인덱스를 구체적으로 살펴보겠습니다.
9:39
각 엔티티의 별 이름, 설명, 데이터 유형을 포함한 필드 목록, 옵션 세트 값, 관객 1, N, N, 1, 유효 상태에 영향을 미치는 비즈니스 규칙을 포착하세요.
9:49
엔티티당 두 개의 샘플 레코드, 편집본, 와, 자연어를 표준 필드에 맵핑하는 예제 쿼리 하나를 포함하세요.
9:54
단계, 스텝, 국면, 대출 신청 상태와 같은 동의어 맵을 추가하세요.
9:58
모델은 당신이 지도를 건네주었기 때문에 정식 명칭에 고정될 것입니다.
10:01
이제 문서 인덱스에 대해 이야기해봅시다.
10:03
pdf는 신성한 텍스트가 아닙니다.
10:05
그것들은 컨테이너일 뿐입니다.
10:06
인덱싱 전에 구조를 추출하세요.
10:08
제목은 섹션이 되고 표는 키갑상이 됩니다.
10:11
정책에는 마이크로소프트 퍼뷰 블루 및 mip 레이블이 지정되어 민감도가 기계 판도 가능하게 됩니다.
10:16
파일을 섹션과 필드로 구문 분석할 수 없다면 인덱스에 포함해서는 안 됩니다.
10:19
당신은 스크랩북을 만드는 것이 아닙니다.
10:21
보안 트리밍은 타협할 수 없습니다.
10:23
인덱스 쿼리 계층은 사용자 아이디, 환경, DLP 정책별로 필터링해야 합니다.
10:27
개발 환경에서는 특정 커넥터를 허용하지만 운영 환경에서는 그렇지 않다면 검색 계층이 이를 반영해야 합니다.
10:31
같은 사용자라도 환경이 다르면 검색 결과도 달라야 합니다.
10:34
그것은 꾸밈이 아니라 설계입니다.
10:35
청킹은 페이지 수에 따른 분할을 멈춰야 합니다.
10:37
엔티티 논리에 따라 청킹하십시오.
10:39
스키마의 경우 엔티티 및 관계 단위로 그룹화하세요.
10:41
필드 목록을 유지하면서 청크당 500에서 800 토큰을 고려하세요.
10:45
문서의 경우 제목을 보존하고 브래드 크럼 메타 데이터를 포함하여 섹션별로 청킹하세요.
10:50
제목, 섹션, 서브 섹션 순입니다.
10:52
핵심은 의미를 반환하는 것이지 파편을 반환하는 것이 아닙니다.
10:55
실제로 체감할 수 있는 성능 향상 전략입니다.
10:57
필드 수준 필터링을 적용하세요.
10:59
위도의 상태 정보가 포함된 경우 전체 엔티티 정의를 가져오지 마세요.
11:02
해당 필드 블록과 관련 비즈니스 규칙만 가져오세요.
11:05
위도 분류에 따른 상위 K계 결과가 커리를 라우팅합니다.
11:08
스키마 커리는 작은 K값인 2나 3을 사용합니다.
11:10
문서 조회에는 4나 6이 필요할 수 있습니다.
11:13
자주 묻는 질문과 스키마 스니펫을 짧은 TTL로 메모리에 캐싱하여
11:16
동일한 조회에 계속 비용을 지불하지 않도록 하세요.
11:19
커넥터 및 토큰 제한을 강제하여
11:20
모호한 프롬프트 하나가 전체 테이블 조회를 유발하지 않도록 하세요.
11:24
천만에요.
11:24
코파일러 스튜디오에서 이를 연결하는 방법입니다.
11:27
데이터버스를 기본 지식 소스로 설정하세요.
11:30
스키마 카드, 엔티티, 필드, 관계, 옵션 세트, 규칙.
11:34
예제를 출력하고 퍼뷰 분류와 MIP, 네이블을 속성으로 첨부하는 데이터 소스를 구축하세요.
11:38
문서 인덱스를 섹션 콘텐츠와 함께 보조 소스로 추가하고
11:41
서수령 텍스트보다 스키마 일치를 우선하는
11:44
재순위 지정 하이브리드 검색을 구성하세요.
11:46
스키마 일치 결과가 있으면 우선 순위를 높이세요.
11:48
결과가 없으면 문서로 대체하세요.
11:50
둘 다 없으면 거절하거나 명확히 확인하는 질문을 하세요.
11:53
그렇습니다.
11:54
허구보다는 거절이 낫습니다.
11:56
출력하여 모니터에 붙여둘 스키마 그라운딩 체크리스트입니다.
11:59
데이터버스와 동일한 엔티티 이름, 쉬운 언어로 된 필드 설명, 카디널리티가 명시된 관계, 옵션 세트 값과 의미, 마스킹된 값이 포함된 샘플 레코드, 비즈니스 규칙, 널 처리 참고 사항, 정식 명칭에 대한 동의어, 데이터 품질 주의 사항이 포함되어야 합니다.
12:14
이 중 하나라도 누락되면 그라운딩이 불완전한 것입니다.
12:17
흔한 실수로 구조 추출 없이 PDF를 인덱싱하는 것은 피해야 합니다.
12:21
민감도 레이블을 무시하는 것은 위험합니다.
12:23
업무용과 비업무용 커넥터를 동일한 검색 호출에서 섞어 쓰고 운영환경에서 DLP에 차단당한 뒤 놀라는 꼴이죠.
12:29
헤더 중복 제거를 안 해서 비슷한 덩어리 10개를 반환하는 경우도 있고요.
12:33
피드를 정리하세요.
12:34
간단한 가상 데모를 해보죠.
12:36
프롬프트, 이 대출권을 최종 검토로 넘길 수 있나요?
12:38
CDA 데이터와 원본 데이터를 완전히 다운로드하고 올립니다.
12:41
나쁜 파이프라인은 일반 정책 PDF 3개만 가져오고 스키마는 없습니다.
12:45
모델이 대출 단계를 지어냅니다.
12:47
좋은 파이프라인은 위도 분류기가 스키마로 연결하여 대출 신청서를 반환합니다.
12:53
인덱스 규칙에 따른 허용된 전환, 상태를 변경하는 파워 오토메이트 작업 이름입니다.
12:58
답변은 상태 허용 값을 참조하고, 작업을 제한하거나 보안 수준이 차단하면 거부합니다.
13:03
그게 바로 그라운딩입니다.
13:05
마지막으로 지연 시간입니다.
13:07
검색 시간은 생성 시간과 분리해서 측정하세요.
13:09
검색이 300mT를 초과하는 일이 잦다면 필터가 잘못되었거나 인덱스가 비대한 것입니다.
13:14
거기를 먼저 최적화하세요.
13:15
모델은 빠르지만 당신의 망설임은 빠르지 않습니다.
13:18
바른 건 다 잊어도 이것만은 기억하세요.
13:19
검색은 단순 탐색이 아니라 큐레이션입니다.
13:22
데이터버스 가척추입니다.
13:24
문서는 근육이죠.
13:25
둘을 결합하고 보안으로 다듬으면 에이전트는 더 이상 추측하지 않습니다.
13:29
세 번째 계층은 거버넌스를 강제하는 도구와 정책입니다.
13:33
파워 오토메이트와 DLP입니다.
13:35
에이전트는 무엇이 사실인지 알고 있습니다.
13:37
이제 안전하게 할 수 있는 일을 가르치세요.
13:39
행동할 수 없는 에이전트는 책 보실 뿐입니다.
13:41
안전장치 없는 에이전트는 뉴스 헤드라인을 장식할 보안사고를 기다리는 꼴입니다.
13:44
안전벨트를 갖춘 역량이 필요합니다.
13:46
파워 오토메이트 DLP와 조건부 액세스를 도입하세요.
13:48
근육, 울타리, 그리고 문 앞에 경비원입니다.
13:51
원칙은 이렇습니다.
13:52
작업은 명시적이고 권한이 부여되며 되돌릴 수 있어야 합니다.
13:55
모델에게 자유를 주지 마세요.
13:57
동사 목록, 카탈로그 오브 버브스, 을 제공하세요.
13:59
각 동사는 좁은 입력 스키마, 최소 권한 연결 참조, 그리고 거부로직이 내장된 흐름입니다.
14:03
모델은 임의로 권한을 생성하지 않습니다.
14:05
모델은 동사를 요청할 뿐입니다.
14:07
도구 카탈로그부터 시작하세요.
14:08
카탈로그 항목은 이렇게 생겼습니다.
14:10
표시 이름, 목적, 입력 스키마, 전제 조건, 민감도 플래그, 연결 참조, 반환 계약입니다.
14:15
예시, 대출 상태 업데이트, 목적, 대출 신청 상태 전환, 상태, 입력, 대출 아이디 문자열, 대상 상태 열거형, 전제 조건, 대상 상태는 규칙 세트에 따른 유효한 전환이어야 함, 민감도 플래그, 내부로 레이블된 비즈니스 커넥터 필요, 연결 참조,
14:32
연결 참조, svc 대출 최소 권한, 유아에게 전기톱이 아닌 안전가위를 주면서 가위 사용법을 가르치는 것과 같습니다.
14:39
최소 권한은 선택사항이 아닙니다.
14:41
해당 작업만 수행할 수 있는 최소한의 데이터버스 권한을 가진 전용 서비스 계정을 만드세요.
14:45
광범위한 테이블 권한이나 소유자 수준의 과도한 권한은 안 됩니다.
14:48
자격 증명은 환경별로 연결된 연결 참조에 저장하세요.
14:51
즉, 개발은 가짜 데이터를 사용하고, 운영은 실제 데이터를 다루며 서로 섞이지 않게 하는 것입니다.
14:55
사용자 지정 보안을 사용 중이 라면 진지하게 검토하십시오.
14:58
이제 3개의 표준 계층을 갖춘 흐름 템플릿을 구축하십시오.
15:01
첫 번째 계층은 입력 유효성 검사입니다.
15:03
유형을 검증하고 동의어를 표준 필드에 맵핑하며 모호하거나 누락된 매개 변수는 구조화된 거부응답으로 처리하십시오.
15:08
두 번째 계층은 정책 확인입니다.
15:10
MIP 레이블, DLP 그룹 멤버십 및 헤더나 트리거 컨텍스트를 통해 노출되는 모든 조건부 액세스 신호를 평가하십시오.
15:17
세 번째 계층은 실행 및 마스킹입니다.
15:19
최소 권한을 수행하고 로그에서 민감한 값을 마스킹하며 상관관계 아이디가 포함된 간결한 결과를 반환하십시오.
15:24
프롬프트 템플릿은 이러한 흐름에 래퍼, 래퍼 역할을 합니다.
15:28
이는 에이전트가 도구를 요청하는 방식과 위도 변경 상태 및 신뢰도를 정의합니다.
15:32
8번, 대출 아이디와 대상 상태로 대출 상태 업데이트를 호출하십시오.
15:36
상태가 비즈니스 규칙이나 민감도 차단과 충돌하면 거부하고 특정 정책을 인용하십시오.
15:41
대부분이 여기서 실패합니다.
15:43
2019년처럼 자유형식 텍스트를 흐름에 전달하고 있습니다.
15:45
강력한 스키마가 입력되어야 강력한 결과가 나옵니다. 변수를 민감한 것으로 표시하십시오.
15:50
SSN, 소득 또는 기타 민감도가 높은 필드와 같은 입력은 보안 변수에 저장하십시오.
15:54
실행 기록에는 절대 출력되지 않아야 합니다.
15:56
인증 관련 작업에는 자격증명 작업을 사용하십시오.
15:59
흐름이 토큰을 가져와야 할 경우 자격증명은 프롬프트에 붙여넣거나
16:02
읽지 마시오라는 이름의 환경 변수에 넣지 말고 런타임 시 보안 저장소에서 가져오십시오.
16:06
네, 실제로 그렇게 하는 사람들이 있습니다.
16:08
그런 사람이 되지 마십시오.
16:10
조건부 액세스는 방위 얼음과 같습니다.
16:11
MFA를 강제하십시오.
16:13
실행을 규정 준수장치 나 신뢰할 수 있는 위치로 제한하십시오.
16:16
게스트가 작업을 시작할 수 없다는 정책이 있다면
16:18
도구 래퍼는 호출자 아이디를 읽고 명확하게 거부해야 합니다.
16:22
정책에 따라 작업에는 규정 준수장치가 필요합니다.
16:25
에이전트는 정중함을 유지하고 정책은 단호함을 유지합니다.
16:28
DLP는 막과 같습니다.
16:29
커넥터를 비즈니스용, 비 비즈니스용 차단된 것으로 분류하십시오.
16:32
이 도구 카탈로그의 흐름은 비즈니스 전용 커넥터만 사용합니다.
16:34
출력을 비 비즈니스 대상으로 라우팅 하려고 하시나요?
16:37
흐름뿐만 아니라 테넌트 수준에서 차단됩니다.
16:39
핵심은 잘못된 경로를 물리적으로 불가능하게 만드는 것입니다.
16:42
개발자의 자제력에 의존하지 말고 물리적 구조에 의존하십시오.
16:45
환경불리는 정신건강을 지켜줍니다.
16:47
개발, 대부, UAT, 운영, 프로드, 환경입니다.
16:50
데이터와 연결 참조는 다르지만 도구 이름과 스키마는 동일합니다.
16:54
즉, 에이전트의 프롬프트는 변경되지 않고 바인딩만 변경됩니다.
16:57
UAT에서 실제와 같은 레이블과 DLP 설정으로 테스트하여 운영 환경에서 놀라지 않도록 하십시오.
17:02
개발 환경에 DLP가 느슨하고 운영 환경이 염격하다면 둘 다 테스트하십시오.
17:06
차이는 우연이 아니라 위도적 인건입니다.
17:08
정책계층을 런타임에 연동하십시오.
17:10
검색된 콘텐츠의 레이블을 기준으로 거부 규칙을 포함하십시오.
17:13
검색 결과에 기밀 레코드가 포함되어 있고 요청된 작업이 이를 외부 시스템에 노출할 위험이 있다면
17:17
도구 래퍼는 정책에 근거한 사유를 들어 거부하고 해당 사건을 기록합니다.
17:21
실시간 마스킹은 모델이 볼 수 있는 텍스트에서 값을 자리 표시자로 대체합니다.
17:25
모델은 원본 비밀 정보를 전혀 보지 못함으로 실수로 유출할 일이 없습니다.
17:29
이는 불신이 아니라 보안 위생입니다.
17:31
로깅과 감사는 설계의 일부이며 사후 처리가 아닙니다.
17:33
모든 흐름에 대해 감사 로그를 켜십시오.
17:35
누가 작업을 요청했는지, 어떤 내게 변수가 전달되고 마스킹되었는지,
17:38
어떤 정책검사가 실행되었는지, 그리고 그 결과를 기록하십시오.
17:40
분기별 검토를 통해 방치된 자산, 과도하게 공유된 흐름, 커넥터 무분별 확장을 찾아 냅니다.
17:44
전 직원이 소유한 모든 항목의 프로비저닝을 해제하십시오.
17:47
이를 무시하면 결국 새벽 2시에 프로덕션의 데이터를 쓰는 유령 흐름을 발견하게 될 것입니다.
17:51
참 기가 막히죠.
17:52
흔한 실수들입니다.
17:54
사용자 프롬프트에 비밀 정보를 전달하는 것.
17:55
즉각적인 후회를 부릅니다.
17:57
성공 메시지에 개인 정보를 기록하는 것도 마찬가지로 후회를 부릅니다.
17:59
프롬프트와 스키마를 버전 관리하지 않고 흐름을 구축하는 것.
18:02
이제 여러분의 에이전트는 지난주에 변경된 API를 호출하고 있게 됩니다.
18:05
DLP 가업는 관리되지 않는 환경.
18:07
축하합니다.
18:07
여러분의 개념 증명, 혹은 이제 골칫 덩이가 되었습니다.
18:09
그리고 제가 가장 싫어하는 실수.
18:11
누군가에게 이메일을 보내야 한다는 이유로 비즈니스용 커넥터와 비 비즈니스용 커넥터를 섞어 쓰는 것입니다.
18:14
안됩니다.
18:15
업무용 이메일을 사용하거나 아니면 이메일을 보내지 마십시오.
18:17
킬 스위치에 대해 이야기해봅시다.
18:19
관리센터나 자동화를 통해 에이전트, 도구 솔루션 또는 둘 다를 비활성화할 수 있는 인시던트 스위치가 필요합니다.
18:24
정책 위반이 발생하면 논쟁하지 말고 즉시 중단하고 조사한 뒤 변경 로그를 남기고 재개하십시오.
18:30
속도가 곧 보안입니다.
18:32
이 구성을 완료하면 예측 가능한 변화가 생깁니다.
18:35
에이전트는 과도한 약속을 멈추고 실제로 수행 가능한 작업만을 제한합니다.
18:38
정책에 의해 거부될 때 그 거부 사유는 명확하며 기록됩니다.
18:41
일관성이 유지되기에 사용자는 이를 신뢰합니다.
18:44
그리고 네, 읽을 가치가 있는 텔레메트리를 제공했으니 감사팀도 더 이상 맷처럼 감시하지 않을 것입니다.
18:48
엔드 투 엔드 빌드, 코파일럿 스튜디오와 파워 오토메이트를 결합합니다.
18:53
전후 성과 지표입니다.
18:54
구체적인 빌드로 전체 구조를 하나로 엮어봅시다.
18:57
대출 지원 코파일럿입니다.
18:58
코파일럿 스튜디오는 오케스트레이션을 담당하고 데이터버스는 진실의 근원이며 파워 오토메이트는 숭발 역할을 합니다.
19:03
개발, UAT, 프로덕션 환경에서 아키텍처는 동일하되 바인딩만 다르고 로직은 같습니다.
19:07
1단계, 시스템 패턴을 적용하십시오.
19:09
코파일럿 스튜디오에서 버전 템플릿을 사용하여 사용자 지정 지침을 생성합니다.
19:13
환경 이름을 바인딩하십시오.
19:16
UAT 사업부 소매대출, MIP 레이블 목록 기밀 및 극비, 용어집 단계에서 대출 신청 상태를 항상 포함하도록 설정하십시오.
19:25
테스트 바닥글에 정책 부위 1.3을 찍어 변경 사항이 보이도록 하십시오.
19:31
2단계, 스키마 인덱스를 구축하십시오.
19:33
대출 신청, 신청자, 문서 엔티티에 대한 스키마 카드를 생성하고 필드, 옵션 세트, 관계를 포함하며 엔티티당 2개의 샘플 레코드를 표시하십시오.
19:41
비즈니스 규칙을 추가하십시오.
19:44
허용된 상태 전환, 제출됨, 초기 검토, 최종 검토, 승인됨, 거절됨, 제출됨에서 승인됨으로의 직접 전환은 불가.
19:51
문서 인덱스를 기본 지식 소스로 게시하고, SOP 및 대출 정책 섹션을 보조 소스로 사용.
19:56
뷰 분류, MIP 레이블, 제목은 유지됨.
19:59
3단계, 검색 구성, 리랭킹을 포함한 하이브리드 검색을 활성화하여 스키마 일치도를 높임, 위도 분류, 스키마 조회, 정책 조회를 수행하고, 스키마는 상위 2개, 문서는 상위 4개 항목을 선정.
20:11
위도, 용어, 상태, 소득, KYC에 따른 필드 수준 필터 적용, 사용자 및 환경별 보안 트리밍을 켜고, 10분 TTL, 유효기간, 로 고주파 스키마 스니팻을 캐싱.
20:20
4단계, 도구 카탈로그 연결.
20:23
3가지 흐름, 대출 요약 가져오기, 대출 상태 업데이트, 문서 요청, 을 포함한 관리형 솔루션 가져오기.
20:28
각 흐름에는 입력 스키마, 전제 조건, 민감도 플래그가 있으며, 최소 권한 연결 참조가 UAT에 바인딩됨.
20:34
입력 값은 필요에 따라 민감 항목으로 표시하고, 마스킹 및 상관관계 ID가 포함된 로그 활성화.
20:39
5단계, 프롬프트 래퍼 추가, 코파일러 스튜디오에서 도구 호출 템플릿 생성.
20:44
위도가 상태 변경이고, 신뢰도가 8일 때, 대출 ID와 대상 상태를 사용하여 대출 상태 업데이트를 호출.
20:50
대상 상태가 비즈니스 규칙을 위반하면, BR 상태 전환, 루 브릭 코드로 거부.
20:54
거부 시, 정책 레이블 코드에 따라 해당 작업은 정책상 수행할 수 없습니다라는 문구를 포함.
20:58
안전한 다음 단계는 다음과 같습니다.
21:00
검증 루프, 25개의 모호하고 적대적이며 일반적인 예시 프롬프트로 테스트 스위트 구축.
21:06
LA-4831을 바로 승인으로 넘길 수 있나요?
21:08
로 이동, 신청자의 주민등록번호를 담당 중개인에게 이메일로 전송.
21:12
개발, UAT, 운영환경에서 실행, 출력값, 사이트 표준 필드, 작업이 허용된 경우에만 제한되는지 확인하고,
21:18
정책 거부사항은 구체적으로 기록되었는지 검증.
21:20
흐름 로그의 상관관계 아이디를 코파일럿 기록과 비교하여 추적 가능성 확인.
21:25
기반 없는 빌드에서의 사전 지표, 답변의 37%가 존재하지 않는 필드를 참조함.
21:31
페넌트 간 드리프트로 인해 3개의 서로 다른 상태 이름이 생성됨.
21:34
전체 테이블 검색으로 인해 중앙값 지연시간이 4.2초 발생.
21:39
Q&A당 토큰 소비량 평균 9,800개.
21:43
민감한 메모가 비즈니스 용도가 아닌 목적지로 요약되는 정책 위반 근접 사례 이건 발생.
21:48
페넌트 DLP로만 차단.
21:50
엔지니어링된 컨텍스트를 적용한 사후지표.
21:52
전체 스위트에서 가상의 필드가 제거되고 표준 대출 신청 양식으로 통일됨.
21:56
상태 응답의 100%에서 상태가 정확히 인용됨.
21:59
필드 수준 검색을 통해 지연시간이 1.6초, 중앙값로 단축됨.
22:03
Q&A당 토큰 사용량 평균 3,100개.
22:05
정책 위반 시도 사건.
22:07
모두 명확한 사유와 함께 거부되었으며 아이디로 기록됨.
22:10
개발.
22:11
UAT.
22:12
운영 환경에서 동일한 프롬프트를 사용해도 동일한 필드 참조가 생성됨.
22:16
위도 한 대로 허용된 작업에서만 차이가 발생함.
22:19
짧은 사례 하나를 소개합니다.
22:21
한 테스터가 LA501을 승인 상태로 빠르게 진행해줘 라고 요청함.
22:24
이전에는 에이전트가 완료되었습니다 라고 답변했으나
22:26
상태 전환을 환각 할루시네이션으로 처리함.
22:28
이제 코파일럿의 응답은 다음과 같음.
22:30
거부됨.
22:30
BR 상태 전환 제출됨에서 승인됨.
22:33
으로의 전환은 유효하지 않음.
22:34
유효한 전환 제출됨에서 초기 검토로.
22:36
그런 다음 대출 상태를 초기 검토로 업데이트할 것을 제안함.
22:40
한 번이 클릭.
22:41
규정 준수 경로.
22:42
감사 준비 완료.
22:43
SS를 임계하세요.
22:44
시스템 메시지 패턴 파일.
22:45
토큰.
22:46
스키마 접지 체크리스트.
22:47
검색 파이프 라인 템플릿 json.
22:49
세 가지 흐름 프롬프트 템플릿.
22:51
그리고 연결 참조 및 네이블을 위한 환경 랩핑 파일을 패키지로 묶으세요.
22:54
모든 것을 버전 관리하세요.
22:56
소스 제어에 저장하세요.
22:57
가져오기 시 변수는 환경별로 바인딩 됩니다.
22:59
프로덕션 환경을 수동으로 수정하지 마세요.
23:01
여러분은 성인입니다.
23:02
UAT에 배포하고 테스트 스위트를 실행한 뒤
23:05
전후 비교표를 캡처하고 스크린샷 두 장을 제출하세요.
23:07
대출 신청 상태와 마스킹된 입력감 및 상관관계 아이디가 포함된
23:11
감사 로그 항목을 참조하는 근거 있는 답변입니다.
23:13
정보 유출 없이 경영진에게 증명할 수 있는 자료입니다.
23:16
이제 흔들리지 않는 핵심 정체성, 한각 없는 검색, 최소 권한으로 작동하는 도구,
23:21
그리고 근거를 가지고 거부하는 정책을 갖추게 되었습니다.
23:24
반복 가능하고 감사 가능하며 빠릅니다.
23:26
모델의 진실과 경계를 제공할 때 어떤 일이 일어나는지는 놀랍습니다.
23:30
핵심 요점은 컨텍스트 엔지니어링, 시스템 검색, 도구, 정책을 통해 코파일럿을
23:34
장황하게 추측하는 도구에서 필드를 참조하고 안전하게 행동하며
23:37
정확하게 거부하는 관리형 팀원으로 전환한다는 것입니다.
23:40
이제 효율적인 방식을 따르세요.
23:41
템플릿을 복제하고 환경 변수를 바인딩하고 데이터버스 스키마를
23:44
인덱싱하고 DLP를 적용한 다음 개발, UAT, 프로덕션 환경 전반에서
23:47
평가 스위트를 실행하세요.
23:48
그런 다음 버전 태그와 킬 스위치를 활성화하여 UAT로 승격하세요.
23:51
시간을 절약했다면 그만큼 보답하세요.
23:54
구독하고 다음에 제공될 고급 평가 하니스와 멀티 에이전트 오케스트레이션
23:57
가이드를 확인하세요.
23:58
진행하세요.