지도와 레일: 기업 AI를 위한 안전한 아키텍처 구축

첫 번째 부분은 다음과 같은 주장으로 끝났다: 기업 AI는 기관이 루프 자체를 구축하는 방법을 배우면 성공할 것이다. 이 에세이는 루프가 서 있는 것에 대해 다룬다. 실제 회사에서 일하는 에이전트는 두 가지를 필요로 한다. 회사에서 거의 가지고 있지 않은 두 가지: 작업에 대한 지도와 결과에 대한 레일.

지도

대부분의 중단된 AI 프로그램의 아래에는 다음과 같은 불편한 사실이 있다: 회사가 에이전트에게 자신의 작업에 대한 설명을 제공할 수 없다. 왜냐하면 그런 설명이 존재하지 않기 때문이다. 대부분의 회사는 명사를 매핑했지만 — 고객, 청구서, 청구, 계약에 대한 데이터베이스가 가득 차 있다. 그러나 거의 никто가 작업을 매핑하지 않았다: 무엇을 그 것들에 대해 할 수 있는지, 누가, 어떤 조건에서, 그리고 무엇이 그 후에 일어나는지에 대한 지식은 경험 많은 사람들의 머리 속에 있고, 5년 전 작업이 설계된 방식에 대한 프로세스 차트에 있다. 오늘날 작업이 실제로 작동하는 방식은 아니다.

인간의 새로운 채용은 견습생으로 그 간격을 닫는다 — 관찰, 시도, 질문. 에이전트는那样으로 배우지 않는다. 그것은 작업을 서면으로 필요로 한다: 비즈니스에서 다루는 것과 각 하나가 현재 어떤 위치에 있는지, 수행되는 작업, 경로를 선택하는 결정, 누가 다음 단계를 진행할 수 있는지, 그리고 누가 진행할 때 무슨 일이 일어나는지 — 기록이 변경되는 방식, 필요한 승인, 그것을 되돌리는 방법. 이러한 서면 설명이 바로 지도이다.

지도를 유지하기 위한 세 가지 규칙이 있다. 작업을 소유한 사람들이 작성해야 하며, 엔지니어가 안전하게 유지해야 한다 — 엔지니어가 업데이트할 수 있는 지도는 구식이 되며, 작업자만 편집할 수 있는 지도는 안전하지 않다. 버전 관리되어야 한다. 에이전트는 의미가 조용히 변경된 경우에 대해 행동해서는 안 된다. 또한 게시되어야 한다 — 에이전트, 검토자, 감사员 모두가 읽을 수 있어야 한다. 에이전트가 API 호출을 통해 비즈니스를 발견해야 한다면, 시스템이 노출된 것이지, 작업이 설명된 것이 아니다. API는 작업을 실행하는 방법이다. 지도는 작업을 이해하는 방법이다.

지도는 어떤 제품 주기보다 더 오래 지속되는 이유로 중요하다: 에이전트가 아닌 지도가 내구성이 있는 자산이다. 모델은 개선되고 교체될 것이며, 에이전트 프레임워크는 나타나고 사라질 것이다 — 그러나 자신의 작업에 대한 설명, 규칙, 예외, 누적된 수정과 함께, 모든 미래 에이전트가 첫째 날에 상속받을 것이다.

레일

지도는 무엇이 일어날 수 있는지 말한다. 레일은 그것을 정확하게 일어나게 하는 것이다.

에이전트가触れる 일부 작업은 판단이다: 메시지를 읽고, 예외를 평가하고, 경로를 추천한다. 그러나 대부분의 작업은 반복이다 — 같은 검사, 같은 업데이트, 같은 게시, 수천 번이다. 반복에는 지능이 필요하지 않다. 정확성이 필요하다. 모델은 설계에 의해 확률적이며, 실행을 위해 확률적으로 올바르지는 않다: 결제 게시에는 허용할 수 있는 편차가 없다. 안정적인 작업은 레일에 속한다 — 결정적인 자동화는 매번同じ 방식으로 실행되며, 실행당 비용이 없으며, 깨끗한 감사 추적을 남긴다.

여기서 두 곡선이 발산하고 있다. 레일을 구축하는 것은 더 쉬워지고 있다. 왜냐하면 작업을 설명하고, 코드를 생성하고, 테스트를 작성하고, 고장난 경로를 수리하는 것은 모두 AI가 가속화하는 작업이기 때문이다. 그러나 결과적인 프로세스 내에서 자유로운 에이전트를 배치하는 것은 같은 속도로 더 쉬워지지 않는다. 왜냐하면 에이전트가 행동에 가까워질수록, 경계, 증거, 승인, 감사, 소유자가 더 필요하기 때문이다. 결과는 어렵고, 어려움을 유지한다. 따라서 에이전트가 탐색하도록 하며, 팀이 작업을 배우도록 도와주면, 경로를 레일로 이동한다. 에이전트가 유행하는 이유로 높은 볼륨의 안정적인 작업을 확률적 루프 내에 두지 마라.

결과에 따라 통치하다

지도와 레일이 자리에 있으면, 에이전트가 실제 작업을触れる 전에 남은 질문은 하나이다: 에이전트가 무엇을 할 수 있게 해야 하는가? 업계의 습관은 다음과 같이 플럼빙 용어로 대답하는 것이다 — 에이전트는 “도구를 사용한다” — 정책을 조회하는 것, 편차를 계산하는 것, 서신을 작성하는 것, 청구서를 승인하는 것, 그것을 지불하는 것이 모두 같은 종류의 일이라는 것을 암시한다. 그러나 그것들은 같지 않다. 정책을 조회하는 모델은 청구서를 거부하는 모델과 다르다. 금액을 계산하는 모델은 그것을 지불하는 모델과 다르다. 정보를 읽는 것, 입장을 취하는 것, 행동을 준비하는 것, 기록을 변경하는 것, 돈을 이동하는 것은 모두 다른 종류의 작업이며, 그 차이는 결과이다 — 회사에 비용이 얼마나 들는지.

관리 구조는 플럼빙이 아닌 결과에 따라 따라야 한다. 읽기 전용 작업에는 접근 제어가 필요하다. 추천 작업에는 실제로 결정하는 사람이 필요하다. 기록을 변경하는 작업에는 승인이 필요하며, 감사 추적이 필요하며, 그것을 되돌릴 수 있는 방법이 필요하며, 명명된 소유자가 필요하다. 돈을 이동하는 작업에는 모두 그것이 필요하며, 또한 반쪽으로 완료된 변경이 회사에 단순히 잘못된 상태를 남기지 않는다는 보장이 필요하다. 결과에 따라 통치하다는 안전한 AI 사용을 빠르게 열어준다; 모든 것을 같은 방식으로 통치하면 마비되거나 사건이 발생한다.

신뢰는 워크플로우에 의해 획득된다

그 그래디언트는 또한 신뢰가 어떻게 성장하는지 보여준다. 지도와 레일이 있으면, 신뢰는 모델에 대한 감정에서 작업의 속성이 된다. 워크플로우 — 하나의 설명된 비즈니스 조각, 첫 번째 부분의 게이트와 함께 —는 단계별로 허가를 얻는다. 먼저 초안을 작성하고, 추천하고, 인간이 승인하는 작업을 준비하고, 루틴 사례를 실행하고, 예외를 승격시키고, 마침내 감사 아래서 실행하며, 결과를 관찰하는 사람이 클릭하는 대신 사람들을 관찰한다.

각 단계는 게이트에서 증거와 함께 획득된다 — 검사된 결정, 수정, 이유 — 그리고 각 단계는 성능이 떨어지면 자동으로 되돌아간다. 모델이 개선되어도 행동 권한을 얻을 수 없다.

모델을 승진시키지 마라. 워크플로우를 승진시켜라.

하나의 워크플로우에서 시작한다

이 모든 것은 기업 전체 프로그램을 필요로 하지 않으며, 그렇게 시작해서는 안 된다. 실제 볼륨, 실제 오류 비용, 수정하고 싶은 소유자가 있는 하나의 결과적인 워크플로우를 선택한다. 그 하나의 작업 조각을 매핑한다. 안정적인 단계를 레일에 올린다. 게이트를 설정한다. 그런 다음 9가지 평범한 질문에 대한 설명을 확인한다:

• 어떤 비즈니스 객체가 이동하고 있는가?
• 현재 각 하나가 어디에 있는가?
• 어떤 작업이 수행되고 있는가?
• 다음 경로를 선택하는 결정은 무엇인가?
• 승인될 때 무슨 일이 일어나는가?
• 에이전트가 무엇을 사용할 수 있는가?
• 자동으로 실행되는 것은 무엇인가?
• 누가 제안하고, 누가 승인하고, 누가 실행하고, 누가 책임이 있는가?
• 何か 잘못되면, 다음 실행 전에 무엇이 변경되는가?

작업을 소유한 사람들이 하나의 워크플로우에 대해 그 9개를 대답할 수 있다면, 에이전트는 안전하게 작업할 수 있다 — 제안, 검증, 레일이 실행한다. 만약 못한다면, 모델의 품질은 배포를 구할 수 없다.

실패는 패턴과 마찬가지로 인식할 수 있다. 작업에 대한 지도가 없는 채트봇이 민감한 시스템에 접근할 수 있다. 정책 질문에 답할 수 있지만 정책 출처를 보여줄 수 없는 검색 레이어. 승인을 할 수 있지만 승인 소유자를 말할 수 없는 에이전트. 승인하는 결과를 볼 수 없는 검토자. 모델이 개선된 이유로 자율성을 얻은 워크플로우, 신뢰를 얻은 것이 아니다.

지도, 레일, 게이트: 그것이 바로 아키텍처이다. 남은 질문은 하나의 워크플로우에서 그것을 구축하는 방법이다 — 그리고 그것은 세 번째 부분이다.