규제 산업의 품질 관리에서 문제를 해결하는 조직의 기억은 거의 항상 고객의 이력 어딘가에 묻혀 있습니다. 작년에 조사된 유사한 결함, 근본 원인을 해결한 시정 및 예방 조치(CAPA), 동일한 공백을 지적한 감사 결과 같은 것들입니다. 이러한 지식은 어떤 인간도 언어와 형식을 넘어 의미적 유사성으로 검색할 수 없는 수십억 개의 문서 속에 있기 때문에 모든 조사가 처음부터 다시 시작됩니다. Octave Reliance는 각 조직이 여러 시스템에 걸쳐 문서를 수집하여 더 쉽게 검색하고 보유한 모든 것을 추적할 수 있도록 지원해 왔습니다. Octave Reliance 팀은 이러한 이력을 활용하는 것을 고객이 더 빠르게 작업하고 규정을 준수하도록 돕는 단일 최대 기회로 보았습니다. 장애물 또한 명확했습니다. 불만 사항 기록, 감사 결과, 시정 조치는 플랫폼의 가장 엄격한 격리 요건을 적용받으며, 그것이 바로 AI가 읽어야 하는 기록이었습니다. 의료기기, 제약, 식품 제조 분야의 14,000명 이상의 고객에게 서비스를 제공하는 플랫폼에서 한 고객에서 다른 고객으로의 단 한 번의 부주의한 정보 노출은 AI의 어떤 이점보다 훨씬 큰 규제상 결과를 초래할 것입니다.
Octave는 180개국에서 사업을 운영하며 글로벌 포춘 500대 기업의 글로벌 포춘 500대 기업의 60%에 서비스를 제공합니다. 이 회사의 클라우드 네이티브 품질 관리 시스템인 Reliance는 불만 관리 및 CAPA 추적부터 감사 관리 및 공급업체 품질에 이르기까지 40개 이상의 애플리케이션으로 650개 이상의 엔터프라이즈 고객을 지원합니다. 모든 사람이 AI가 추론할 수 있는 규제 데이터를 생성합니다. 각 고객은 별도의 테넌트이며 어떤 데이터도 테넌트 경계를 넘을 수 없습니다.
이에 직면하여 Reliance 팀은 특이한 결정을 내렸습니다. 단일 AI 기능을 출시하는 대신 첫 사이클을 모든 향후 기능이 놓이게 될 기반 구축에 투자한 것입니다. 그 기반은 이후 사용 사례당 배포 시간을 50퍼센트 단축했습니다. 데이터가 가치 있지만 격리가 타협 불가능한 소프트웨어 as a service(SaaS) 플랫폼에 AI를 도입하려는 경우, 이러한 사고방식은 품질 관리를 넘어 적용됩니다. 이 게시물에서는 설계를 형성한 네 가지 긴장 관계와 Octave가 Amazon Bedrock에서 Cohere Embed v4로 구축한 3계층 기반을 살펴봅니다. 그런 다음 20억 개의 문서를 임베딩한 파이프라인과 이를 프로덕션에서 입증한 Complaint Triage Assistant를 따라갑니다.
기능이 아닌 기반인 이유
AWS와의 비전 워크숍에서 네 가지 높은 영향력의 사용 사례가 도출되었습니다: 불만 요약 및 트리아지, 감사 준비 모니터링, 사고 서술 생성, 예측적 품질 위험 스코어링입니다. 또한 수십 개의 애플리케이션, 각기 다른 문서 유형과 워크플로를 거치며 이후의 모든 것을 형성한 통찰이 도출되었습니다. 하나를 사일로 방식으로 구축하면 다음을 위해 인프라를 다시 만들어야 한다는 것이었습니다.
그래서 팀은 계획을 뒤집었습니다: 먼저 수평 플랫폼을 구축한 다음, 그 위에 수직 기능 조각을 잘라 내는 것입니다. 불만 요약 및 트리아지가 먼저 진행되어 나머지가 뒤따르기 전에 아키텍처를 입증했습니다.
네 가지 긴장 관계
단 하나의 모델을 선택하기 전에 팀은 서로 다른 방향으로 끌어당기는 네 가지 문제에 시간을 들였습니다. 어느 것도 타협할 수 없었습니다.
부주의한 정보 노출 위험 없이 데이터를 사용 가능하게 만드는 것. 불만 사항 기록, CAPA, 표준 운영 절차(SOP), 감사 결과는 하나의 테넌트에 속하며 다른 테넌트가 접근할 수 없어야 합니다. 잘못된 AI 쿼리조차 경계를 넘을 수 없어야 합니다. 벡터 스토어, 검색 로직, 생성 컨텍스트 모두 단일 테넌트로 범위가 한정되어야 했습니다.
에이전트를 격리된 상태로 실행하는 것. 에이전트의 도구, 데이터 스토어, 모델 엔드포인트를 규율하는 권한은 공유 서비스 역할이 아닌 요청 사용자에게 범위가 한정되고, 실행 중에만 사용 가능하며, 해당 사용자의 접근 권한을 존중해야 했습니다. 정적 자격 증명을 가진 공유 에이전트 풀은 세 가지 요건을 모두 충족하지 못했습니다.
신뢰할 수 없는 콘텐츠를 읽는 것. 여기서 에이전트는 조직 외부의 불만 사항, 이메일 첨부 파일, 스캔된 PDF, 이미지를 수집합니다. 대규모 언어 모델(LLM) 애플리케이션을 위한 OWASP Top 10(2025)은 직접 적용되는 위협을 명시합니다: 수집된 콘텐츠를 통한 프롬프트 인젝션(LLM01), 민감한 정보 노출(LLM02), 부적절한 출력 처리(LLM05), 과도한 에이전시(LLM06). 이 정도의 규모에서는 첨부된 PDF 속 숨겨진 지시문은 가정이 아닙니다.
분기 대기 없이 20억 개의 문서를 임베딩하는 것. Reliance는 20억 개 이상의 문서를 호스팅하며, 개별 테넌트는 수백만 개의 Word 파일, PDF, 스캔된 양식, 스프레드시트, 이미지, 이메일을 저장합니다. 팀은 가장 큰 테넌트조차 하루 근무일 내에 온보딩하겠다고 약속했습니다. 이 문서들은 규제 결정에 반영되므로 품질을 처리량과 맞바꿀 수 없었습니다. 놓친 불만 사항 하나가 전체 시스템에 대한 신뢰를 잠식합니다.
아키텍처의 귀결점
네 가지 긴장을 동시에 충족해야 한다는 조건은 선택지를 크게 좁혔습니다. Amazon Bedrock은 이를 하나의 플랫폼으로 해결했습니다. 단일 API를 통한 멀티 모델 접근, AWS 리전 데이터 상주 요건, 그리고 AWS Identity and Access Management (IAM) 거버넌스는 AWS 계정이 이미 강제하고 있는 것이며, Guardrails는 직접 만들어야 할 것이 아니라 프로덕션 콘텐츠 제어 수단으로 제공됩니다.
이 기반은 그림 1에 표시된 세 개의 계층으로 구성됩니다. 데이터 준비 계층은 품질 문서를 Amazon Bedrock의 Cohere Embed v4 로 임베딩하여 Amazon OpenSearch Service의 테넌트별 벡터 스토어에 기록합니다. 보안 실행 계층은 사용자 요청을 AgentCore Gateway( Amazon Bedrock AgentCore의 기능)을 통과시키는데, 이 게이트웨이는 인증과 정책을 적용한 뒤 Amazon Bedrock에서 Anthropic Claude 모델을 호출하는 격리된 microVM 세션으로 요청을 전달합니다. 이 둘을 감싸는 콘텐츠 보호 계층은 Amazon Bedrock Guardrails를 두 번 적용합니다. 들어오는 입력에 대한 필터링과, 처리 담당자에게 전달되기 전의 출력 필터링입니다. 검색, 실행, 심사가 별도의 단계로 유지되므로 각각 독립적으로 강제하고 증명할 수 있습니다.
그림 1: Reliance AI 기반의 상위 수준 아키텍처
데이터 표현 방식 선택
문서를 검색할 수 있게 되기 전까지는 다른 어떤 것도 작동하지 않았습니다. 이는 여러 언어와 형식에 걸쳐 정확하게, 그리고 테넌트 경계를 넘지 않고 이루어져야 했습니다. 팀은 공개 리더보드가 아니라 자체 코퍼스를 대상으로 임베딩 모델을 평가했습니다. 결정적인 질문은 이 데이터에 특화된 것이었습니다. 균열이 간 하우징 사진이 그것을 설명하는 문단과 어떤 관계인지, 그리고 독일어 불만 사항이 영어 CAPA와 어떤 관계인지가 그것이었습니다.
Amazon Bedrock의 Cohere Embed v4는 다섯 가지 항목에서 승리했으며, 이 항목들은 서로 독립적이지 않았습니다. 가장 먼저 결정된 것은 파이프라인의 어느 부분이 불필요해지는가였습니다. 품질 기록에는 텍스트와 함께 불량 제품의 사진, 스캔된 검사 양식, 주석이 달린 다이어그램이 포함됩니다. Embed v4는 두 가지 모달리티를 하나의 벡터 공간에 배치합니다. 균열이 간 하우징 사진과 해당 결함을 설명하는 문단을 단일 쿼리로 검색할 수 있으며, 모달리티별 별도 파이프라인이 필요 없습니다. 네이티브 다국어 지원은 다른 축에서도 같은 역할을 합니다. 문서는 여러 언어로 도착하며, 종종 한 테넌트의 코퍼스 내에 함께 있지만 번역 전처리가 필요하지 않습니다. 팀이 만들지 않아도 된 파이프라인 두 개, 그리고 문서가 검색에서 누락될 수 있는 지점 두 개가 줄어든 것입니다.
나머지 세 가지 항목은 벡터가 어디에 저장될 수 있고 비용이 얼마인지로 귀결되었습니다. 고객 데이터는 추론을 위해서라도 해당 AWS 리전을 벗어날 수 없으므로, Amazon Bedrock에서의 리전 내 모델 가용성은 편의 기능이 아닌 전제 조건이었습니다. Embed v4는 미국 동부(버지니아 북부) 리전(us-east-1), 유럽(아일랜드) 리전(eu-west-1), 아시아 태평양(도쿄) 리전(ap-northeast-1)에서 리전 내 추론을 지원하여 Octave의 리전별 규정 준수 요건 세 가지를 충족합니다. 모델 및 기능 가용성은 리전에 따라 다르며 시간이 지나면서 변경됩니다. 최신 커버리지는 Amazon Bedrock 사용 설명서의 모델별 리전 가용성 을 참조하십시오. 각 리전 내에서 Amazon OpenSearch Service 비용은 차원 수에 정비례하여 증가합니다. 이 때문에 Embed v4의 256–1,536 범위의 구성 가능한 출력 차원을 기본값으로 그대로 받아들이지 않고 테스트할 가치가 있었습니다. 대표적인 프로덕션 쿼리를 대상으로 테스트한 결과, 512차원이 목표 정확도를 유지하면서 1,536 기본값 대비 스토리지를 약 66% 절감하는 것으로 나타났습니다. 128K 토큰 컨텍스트 윈도우는 완전히 다른 곳에서 효과를 발휘했습니다. 약 4K 토큰 크기의 청크를 요청 하나에 여러 개 담을 수 있어, 이것이 온보딩 처리량의 원천이 되었습니다.
런타임에서 테넌트 분리 유지
더 어려운 질문은 테넌트 분리를 어디에서 강제할 것인가였습니다. 애플리케이션 코드에서 처리하는 것도 가능했지만, 그렇게 하면 모든 향후 기능 팀이 모든 코드 경로에서 이를 올바르게 구현해야 했고, 검증 하나를 누락하면 의도치 않은 테넌트 간 정보 노출의 위험이 있었습니다. 팀은 대신 격리를 런타임으로 밀어 넣었습니다. Amazon Bedrock AgentCore의 기능인 AgentCore 런타임은 애플리케이션 계층 아래에서 분리를 강제하며, 프레임워크와 모델에 독립적이기 때문에 Complaint Triage Assistant를 위해 선택한 에이전트 프레임워크와 모델은 격리 결정의 제약을 받지 않았습니다.
각 사용자 세션은 자체 CPU, 메모리, 파일시스템을 갖춘 전용 microVM에서 실행되며, 세션이 끝나면 중지되고 정화(sanitize)됩니다. 이는 에이전트가 어떻게 동작하든 관계없이 유지되도록 설계된 하드웨어 수준의 분리입니다. AgentCore는 인증된 사용자의 신원을 전체 실행 체인을 통해 전달합니다. 사용자별 OAuth 토큰 볼트는 에이전트가 공유 서비스 신원이 아닌 해당 특정 사용자를 위해 동작함을 검증하고, 자격 증명은 에이전트별로 범위가 지정되며 세션 기간에만 존재합니다. AgentCore Gateway는 도구, 작업, 파라미터 수준에서 권한을 부여합니다. 자동화된 추론(automated reasoning)은 정의된 규칙에 대한 형식 검증을 제공합니다. 이는 IAM 및 Amazon Simple Storage Service (Amazon S3) 정책 검증 뒤에 있는 것과 같은 원칙입니다. 그림 2는 두 테넌트에 걸친 이러한 분리를 보여줍니다.
그림 2: 테넌트 간 AgentCore 세션 분리. 각 microVM은 사용 후 중지되며 메모리가 정화됩니다.
따라서 테넌트 A의 품질 담당자가 제출한 불만 사항은 Amazon Bedrock AgentCore의 기능인 AgentCore Code Interpreter 내에서 테넌트 A의 토큰 볼트, 도구, 샌드박스에만 도달합니다. 테넌트 B의 세션에는 이들 어디에도 접근할 경로가 없습니다.
수집된 콘텐츠를 신뢰할 수 없는 것으로 취급하기
이러한 긴장 관계에는 깔끔한 해답이 없었습니다. 불만 첨부 파일은 신뢰할 수 없는 입력이지만, 동시에 에이전트가 존재하는 이유 자체가 그것을 읽는 것이므로 의심스러운 콘텐츠를 거부할 수도 없었습니다. 팀은 다층 방어(defense in depth)에 합의했습니다.
Octave 적용 Amazon Bedrock Guardrails 불만 처리 워크플로의 세 지점에서 에이전트 로직 내부가 아닌 그 위에 적용했습니다. ApplyGuardrail API는 임베딩 이전에 첨부 파일에서 추출된 텍스트를 평가하고, 에이전트의 컨텍스트에 들어가기 전에 검색된 문서와 도구 출력을 평가하며, 담당자가 보기 전에 합성된 요약 보고서를 평가합니다. 첨부 파일에서 파생된 콘텐츠는 입력 태깅과 함께 전달되어 지시 사항이 아닌 데이터로 표시됩니다. 이것이 문서 중간에 숨겨진 인젝션을 탐지 가능하게 만드는 요점입니다. 개인 식별 정보(PII)는 유입 과정에서 마스킹됩니다.
탐지만으로는 충분하지 않아 그 아래에 제한된 에이전시가 자리합니다. 에이전트에게 무엇을 요청하든 AgentCore Gateway가 여전히 어떤 도구를 호출할 수 있는지 관리하며, 문서 추출은 AgentCore Code Interpreter 샌드박스에서 네트워크 이그레스 없이 세션 이후 지속되는 저장 없이 실행됩니다. PDF에 숨겨진 페이로드는 하나의 계층이 아니라 모든 계층을 뚫어야 합니다.
그 효과는 다음과 같습니다: 탐지 및 마스킹 비율이 테넌트별로 추적되므로, 스크리닝이 잡아낸 것을 Octave가 단정이 아닌 근거로 제시할 수 있습니다.
20억 개 문서를 파이프라인으로 처리하기
임베딩 모델 앞에는 더 어려운 문제가 있었습니다. Word 파일, 스프레드시트, 디지털 PDF, 스캔 페이지, 사진, 이메일 스레드에서 사용 가능한 콘텐츠를 추출하는 것이었습니다. 여러 언어가 나타나며, 때로는 하나의 레코드 안에서도 그렇습니다. 그리고 온보딩이 한 분기가 아닌 하루에 완료되도록 충분히 빠르게 실행되어야 했습니다. 그림 3은 그 결과로 만들어진 파이프라인을 처음부터 끝까지 보여줍니다.
그림 3: 수집 파이프라인: 애플리케이션 플랫폼에서 Step Functions 오케스트레이션을 거쳐 테넌트별 OpenSearch 인덱스까지의 이벤트 기반 문서 처리.
문서 이벤트는 Amazon Simple Notification Service(Amazon SNS)와 Amazon Simple Queue Service(Amazon SQS)를 통해 AWS Step Functions 상태 머신으로 분산됩니다. 이 상태 머신은 전용 Amazon Virtual Private Cloud(Amazon VPC) 내에서 동시 AWS Lambda 실행에 걸쳐 파싱, 청킹, 임베딩을 오케스트레이션합니다. 병렬성이 하나의 리소스를 확장하는 방식이 아니라 배치를 여러 실행에 분산하는 방식으로 얻어지기 때문에, 아키텍처를 다시 설계하지 않고도 처리량이 증가합니다.
파싱은 이기종성을 처리합니다: Word 파일과 스프레드시트에서 의미적 계층 구조를 보존하고, 텍스트 레이어가 없는 스캔 PDF에 광학 문자 인식(OCR)을 적용하며, 내장 이미지를 일급 콘텐츠로 취급합니다. 청크에는 메타데이터가 담깁니다: 테넌트, 문서 유형, 소스 애플리케이션, 언어, 콘텐츠 해시입니다. 이 메타데이터는 검색 필터링과 테넌트별 네임스페이스 강제 모두를 구동합니다.
처리량은 패킹에서 나왔습니다. 많은 4K 청크를 Embed v4의 128K 컨텍스트 윈도우에 대한 단일 요청으로 인리빙(interleaving)하여 대규모 코퍼스에 대한 API 호출을 약 한 자릿수 줄였습니다. Amazon Bedrock에서 진행한 Octave의 내부 테스트에서 Embed v4는 분당 2,800만 토큰을 처리했습니다. Cohere의 솔루션스 아키텍트들과 함께 메모리 병목이 해소될 때까지 배치 크기를 조정한 후, 파이프라인은 테넌트당 24시간 동안 140만 개의 문서를 처리하는 워크로드를 유지했습니다. 바로 이것이 단일 근무일 커밋먼트를 현실로 만든 요인입니다.
불만 트리아지 어시스턴트
한 병원이 의료기기 제조사에 결함이 있는 주사기를 보고하고, 그 기록에는 이메일, 손상된 제품의 사진, 지원 문서가 첨부되어 도착합니다. 품질 담당자는 이러한 형식들에 걸쳐 맥락을 조립하고, 이와 유사한 사례가 이전에 보고되었는지 파악하며, 그것을 어떻게 해결했는지 찾아야 합니다. 그 후에야 우선순위를 부여할 수 있으며, 종종 며칠 단위로 측정되는 보고 기간 내에 이루어져야 합니다.
어시스턴트는 AWS가 오픈소스로 공개한 Strands Agents SDK로 구축되었으며, 이 SDK는 에이전틱 워크플로를 그래프로 구성합니다. 노드는 도구 호출 또는 모델 호출이고 엣지는 그들 간의 데이터 의존성입니다. AgentCore 런타임이 이 그래프를 실행하고 세션별로 격리하며, 다섯 단계가 불만을 원시 첨부 파일에서 완성된 요약 보고서까지 운반합니다.
문서 추출이 먼저 옵니다. PDF, 이미지, 이메일 첨부 파일, 비디오가 모두 AgentCore Code Interpreter로 들어가며, 이는 각 아티팩트를 구조화된 중간 표현으로 파싱합니다. 그런 다음 Amazon Bedrock의 Claude 모델이 레코드를 요약하고, 그 요약이 원천의 수천 토큰 소스 대신 검색 쿼리가 됩니다. 검색은 이 쿼리를 Embed v4 임베딩의 테넌트 OpenSearch 인덱스에 대해 실행하여 유사한 과거 불만 사항과 그에 따른 CAPA를 표면화하며, AgentCore Gateway가 승인된 네임스페이스만 접근 가능하도록 강제합니다.
돌아온 결과는 유사성만으로 신뢰되지 않습니다. 별도의 모델 호출이 결과에 신뢰도 점수를 매기고, 어휘는 공유하지만 근본 원인이 다른 매칭은 폐기합니다. 살아남은 결과는 합성 단계로 가며, 여기서 Amazon Bedrock의 Anthropic Claude Sonnet이 핵심 사실, 감성, 긴급성 지표, 결과를 포함한 가장 가까운 과거 기록, 권장 트리아지 우선순위를 담은 출력을 조립합니다.
완성된 요약 보고서는 환경별 TTL(time to live)과 함께 Amazon DynamoDB에 캐시되므로, 반복 조회에는 추가 비용이 들지 않습니다. 담당자는 이제 제로에서 시작하지 않고 조직의 축적된 지식에서 시작합니다.
그림 4는 해당 엔진을 프라이빗 API 경계 뒤에 배치합니다. 포털 요청은 프라이빗 Amazon API Gateway와 Lambda 함수를 통해 AgentCore 런타임에 도달하고, 검색은 사전 서명된 URL(pre-signed URL)이 있는 역할 기반 접근으로 문서 인덱스를 읽는 한편 첨부 파일은 Amazon S3에 그대로 유지됩니다. 캐시된 요약과 OpenTelemetry 트레이스는 요약 테이블과 평가 대시보드로 나갑니다.
그림 4: 요약 엔진: 프라이빗 API 경계 내에서 문서 추출, 검색, 추론 및 종합을 처리하는 AgentCore 기반 워크플로로, 응답 캐싱과 완전한 관측 가능성을 갖추고 있습니다.
그림 5는 동일한 경로를 한 줄로 축약하여 양쪽 끝에 Guardrails 필터링을 보여줍니다.
그림 5: 수집부터 처리 담당자 출력까지 이어지는 불만 사항 분류 지원 파이프라인
에이전트가 무엇을 했는지 증명하기
여기서 관찰 가능성(Observability)은 엔지니어링 팀이 디버깅하는 방식일 뿐만 아니라, 규정 준수 요건을 충족하기 위해 시스템 감사 기능과 통합하는 방식이기도 합니다. 감사자는 특정 불만 사항이 왜 그런 방식으로 분류되었는지 물어볼 수 있으며, "모델이 결정했습니다"라는 대답은 그러한 대화에서 통하지 않을 것입니다.
AgentCore는 그래프의 모든 노드, 즉 각 모델 호출, 검색, AgentCore Code Interpreter 실행 전반에 걸쳐 OpenTelemetry 호환 트레이스를 수집합니다. 수개월 후에도 Octave는 특정 브리프를 산출한 검색된 문서와 프롬프트가 무엇이었는지 보여줄 수 있습니다. Amazon Bedrock의 모델 호출 로깅은 모든 요청과 응답에 대한 테넌트별 기록을 추가하며, 이는 AgentCore가 전파하는 IAM 자격 증명으로 범위가 지정되고, 비용은 Amazon CloudWatch에서 해당 요청을 시작한 테넌트에 귀속됩니다.
오프라인 환경에서 AgentCore Evals는 프롬프트, 모델 또는 검색 매개변수가 변경될 때마다 전문가가 주석을 단 정답(ground truth)을 기준으로 워크플로를 재실행하여 요약 충실도, 검색 정밀도(retrieval precision at K), 출력 완결성을 보고합니다. 더 읽기 좋아 보이지만 검색 성능이 떨어지는 프롬프트는 사용자가 보기 전에 걸러집니다.
결과
불만 사항 분류 도우미(Complaint Triage Assistant)가 3개월간 프로덕션 환경에서 운영되었으며, 다음 수치는 해당 기간을 반영한 것입니다.
예전에는 아무것도 없는 상태에서 조사를 시작하던 담당자가 이제는 관련 이력이 이미 정리된 상태로 조사를 시작합니다. Octave가 조사당 측정하는 4–6시간은 파이프라인이 흡수한 작업입니다. 즉, 다양한 형식에 걸친 데이터 추출, 유사 사례 검색, 그리고 진짜로 유사한 결함과 단어의 우연한 일치를 구별하기 위해 필요한 읽기 작업입니다.
이 재단은 Octave의 출시 속도도 바꾸었습니다. 자체 집계에 따르면, 새로운 AI 기능의 개발 주기가 몇 달에서 몇 주로 단축되었습니다. 공유 데이터 준비, 보안 실행, 검색은 Figure 1의 세 가지 계층입니다. 각각의 새로운 기능이 이를 새로 구축하는 대신 상속받기 때문에, 사용 사례당 배포 시간이 50퍼센트 줄었습니다. 덕분에 시맨틱 검색은 2분기에 도입되었으며, 이는 원래의 4분기 목표보다 두 분기 앞선 것입니다.
돌아보면
기반을 먼저 구축하기로 한 결정은 팀이 가장 많이 후회했던 선택이었습니다. 이해관계자들이 눈에 보이는 AI 기능을 원할 때는 수개월에 걸친 인프라 작업을 정당화하기 어렵습니다. 그러나 다음 라운드의 사용 사례들이 그 가치를 입증했습니다. 이를 떠받쳐준 것은 두 가지 선택이었습니다. 애플리케이션 코드가 아닌 microVM 세션으로 격리를 밀어넣고 신원 전파(identity propagation)를 처리한 것, 그리고 Octave 자체 코퍼스를 대상으로 임베딩 모델을 평가하여 어떤 벤치마크로도 드러나지 않았을 512차원 트레이드오프를 발견한 것입니다.
팀은 또한 넘지 않기로 선택한 선을 그었습니다. 어시스턴트는 맥락과 선례를 제시합니다. 최종 판단은 여전히 품질 담당자가 내립니다. 그 판단이 규제적 무게를 지니는 업계에서 이 경계는 무엇을 자동화하고 무엇을 자동화하지 않을지를 형성했습니다.
다음은 무엇일까
Octave은 이제 Reliance 스위트 전반에 걸쳐 이 기반을 확장하고 있습니다. 감사 대비 모니터링, 사고 서사 생성, 예측 품질 위험 스코어링이 다음 단계이며, 각각 동일한 인프라를 기반으로 구축됩니다.
귀하의 플랫폼도 비슷한 갈등, 즉 엄격한 격리 요구 사항 뒤에 있는 가치 있는 데이터 문제에 직면해 있다면요. Octave의 경험은 이러한 트레이드오프가 충분히 감당 가능하다는 것을 보여줍니다. 이 이야기의 배후에 있는 서비스에 대해 자세히 알아보려면 다음을 참조하세요. Amazon Bedrock, 이 Amazon Bedrock AgentCore 문서, 그리고 Cohere on Amazon Bedrock. 관련 아키텍처 지침은 다음을 참조하십시오: AWS 벡터 솔루션: 데이터가 있는 곳에서 에이전틱 AI 구축 그리고 벤더 종속 없이 에이전틱 AI를 확장하기: 엔터프라이즈 패턴.