Orca Security Discovery AI, 자연어 보안 쿼리 비용 절감

Orca Security Discovery AI는 이제 일반 영어로 작성한 보안 질문을 Sonar 쿼리로 변환하면서 초기 설계보다 입력 토큰을 93% 적게 사용한다. Orca는 또한 Amazon Bedrock 기반으로 시스템을 재구축한 뒤 쿼리 비용이 90%, 지연 시간이 75% 줄었다고 밝혔다.

이 수치는 단순한 모델 업그레이드 이상의 의미를 갖는다. Orca는 거대한 단일 프롬프트를, 각 요청을 규칙·검색·소형 모델·심층 추론 중 무엇이 처리해야 하는지 결정하는 9단계 파이프라인으로 대체했다.

이 결과는 모든 스키마, 예시, 지침을 하나의 대형 컨텍스트 윈도에 넣는 일반적인 엔터프라이즈 AI 전략에 의문을 제기한다. Orca의 사례는 더 많은 컨텍스트가 비용을 높이는 동시에 관련성을 낮추고 애플리케이션을 느리게 만들 수 있음을 시사한다.

이 대안은 언어 모델을 통제된 쿼리 컴파일러 내부의 한 구성 요소로 다룬다. 결정론적 매칭은 명확한 입력을 처리하고, 검색은 검증된 예시를 제공하며, 검증은 생성된 필터를 반환하기 전에 점검한다.

이 설계가 중요한 이유는 자연어 보안 쿼리가 민감하고 고도로 구조화된 정보를 대상으로 작동하기 때문이다. 생성된 필터가 잘못된 자산을 가리키거나, 권한 경계를 넘거나, 핵심 조건을 누락한다면 유창한 답변은 별다른 가치가 없다.

Orca, 거대 단일 프롬프트를 프로덕션 파이프라인으로 대체

핵심 변화는 아키텍처였다. Orca는 매 요청마다 하나의 모델이 전체 보안 스키마를 이해하도록 요구하는 방식을 중단했다.

Orca의 Sonar 쿼리 시스템은 900개가 넘는 클라우드 인프라 및 애플리케이션 모델을 포괄한다. 이 모델들은 컴퓨팅 인스턴스, 스토리지 버킷, ID, 취약점과 이들을 연결하는 관계 같은 리소스를 나타낸다.

Discovery AI 이전에는 사용자가 정확한 JSON 필터를 구성해야 했다. 또한 정확한 모델 이름을 알고, 중첩된 관계를 탐색하며, 18개의 필터링 연산자 중에서 선택해야 했다.

이 요구 사항은 보안 질문은 이해하지만 Sonar의 전체 스키마는 알지 못하는 분석가에게 사용성 장벽을 만들었다. 이에 Orca는 분석가의 요청을 유효한 필터로 번역하는 자연어 인터페이스를 구축했다.

첫 번째 개념 검증은 가장 직접적인 생성형 AI 접근법을 사용했다. Orca는 대형 모델용 단일 프롬프트에 900개 이상의 모델 정의, 관계 유형, 예시 쿼리를 담았다.

회사에 따르면 설계 파트너와 내부 사용자는 출력 품질을 긍정적으로 평가했다. 그러나 이 설계는 비슷한 워크로드에서 약 200만 입력 토큰을 소비했고 약 60초가 걸렸다.

복잡한 요청은 정확도 한계도 드러냈다. 여러 리소스 모델, 중첩된 관계 또는 복수 조건이 포함된 질문은 추가적인 보정이 필요한 경우가 많았다.

이후 Orca와 AWS는 프로덕션 9단계 파이프라인을 개발했다. 이 시스템은 2026년 3월부터 매일 수천 건의 쿼리를 처리해 왔으며, 응답 시간은 약 15초라고 전해진다.

파이프라인은 요청을 조직 컨텍스트와 결합하는 것으로 시작한다. 이 컨텍스트에는 연결된 클라우드 제공업체, 요청 메타데이터, 사용자 환경을 해석하는 데 필요한 세부 정보가 포함될 수 있다.

다음으로 결정론적 매처가 구조화된 식별자를 찾는다. 여기에는 IP 주소, CVE 식별자, 파일 해시, 리소스 이름, URL, 경보 ID가 포함된다.

일치하는 식별자는 비용이 큰 모델 호출 없이 미리 정의된 필터를 실행할 수 있다. 이 빠른 경로는 예측 가능한 작업을 확률적 시스템에서 분리한다.

해석이 필요한 요청은 가드레일을 통과한다. Orca는 이 단계가 쿼리 생성에 도달하기 전에 프롬프트 인젝션 시도, 관련 없는 질문, 지원되지 않는 입력을 차단한다고 밝혔다.

그런 다음 시스템은 검증된 예시 라이브러리를 검색한다. Amazon Titan 임베딩은 의미적으로 유사한 후보 20개를 검색하고, Cohere Rerank 3.5는 이를 5개로 줄인다.

모델 선택기는 900개가 넘는 Sonar 모델 중 현재 요청과 관련된 모델로 범위를 좁힌다. 생성기는 이 더 작은 그룹과 그 관계에 대해서만 상세 스키마를 받는다.

Anthropic Claude Haiku 4.5는 선택 및 생성 단계를 구동한다. Amazon Nova 2 Lite는 Orca가 더 빠르고 저렴한 추론을 우선시하는 가드레일 및 검증 작업을 처리한다.

생성된 필터가 자동으로 최종 결과가 되는 것은 아니다. 정적 검사는 선택된 스키마를 기준으로 각 모델, 필드, 연산자를 확인한다.

Orca는 Sonar API를 통해서도 필터를 확인한다. 검증에 실패하면 오류가 문제 요소를 식별하고 이를 수정할 수 있도록 생성기로 되돌린다.

이 루프는 생성을 제약된 프로세스로 바꾼다. 모델은 필터를 제안할 수 있지만, 그 제안이 사용 가능한 스키마를 준수하는지는 결정론적 시스템이 판단한다.

Orca Security Discovery AI, 의도적으로 컨텍스트 축소

Orca Security Discovery AI는 컨텍스트를 확장하는 대신 선택함으로써 보고된 경제성을 개선했다.

초기 프로토타입은 Sonar의 전체 스키마를 필수 컨텍스트로 취급했다. 모델이 수백 가지 리소스 유형과 그 관계를 이해해야 했기 때문에 이는 합리적인 선택으로 보였다.

문제는 대부분의 질문이 그 스키마 중 일부만 다룬다는 점이었다. 매 요청마다 모든 정의를 보내면 모든 정의가 유용해지지 않은 채 토큰 사용량만 늘어났다.

현재 Orca의 모델 선택기는 사용 가능한 모델의 압축된 설명을 기반으로 작동한다. 각 설명은 모델의 이름, 목적, 중요한 필드, 중요한 관계를 요약한다.

선택기는 질문에 필요한 모델을 식별한다. 이후 생성기는 해당 선택 항목과 이를 연결하는 데 필요한 관계에 대해서만 전체 스키마를 받는다.

이 변화는 비슷한 워크로드에서 보고된 입력 사용량을 약 200만 토큰에서 14만 토큰으로 줄였다. 이는 언급된 93% 감소에 해당한다.

Orca는 90%의 비용 절감이 토큰량 감소와 단계별 모델 배분에서 비롯됐다고 설명한다. 각기 다른 작업이 더 이상 사용 가능한 최대 모델을 기본값으로 사용하지 않는다.

지연 시간은 약 60초에서 15초로, 75% 줄었다고 전해진다. 더 빠른 경로에도 여러 단계가 포함되어 있어, 단계 수만으로 응답 시간을 결정할 수 없음을 보여준다.

하나의 긴 추론은 여러 개의 좁은 작업보다 느릴 수 있다. 시스템이 알려진 패턴을 인식할 경우 규칙과 검색은 생성 단계를 건너뛸 수도 있다.

이것이 보고된 성과의 핵심 메커니즘이다. Orca는 심층 추론이 필요한 자료의 양을 줄인 뒤, 요청에서 해결되지 않은 부분에만 생성형 작업을 할당했다.

검색 설계도 같은 원칙을 따른다. 순수한 top-K 의미 검색은 빨랐지만, Orca는 이것이 유사한 중복 예시를 자주 반환한다는 사실을 확인했다.

이러한 중복은 많은 범위를 추가하지 않은 채 컨텍스트를 차지했다. Maximal Marginal Relevance는 다양성을 높였지만, 때로는 가장 관련성 높은 예시를 최상위 순위에서 밀어냈다.

Orca는 인접한 예시 20개를 검색한 뒤 5개로 재순위화하는 방식을 택했다. 더 큰 1차 패스는 재현율을 중시하고, 재순위화는 최종 컨텍스트를 더 강한 일치 항목에 집중시킨다.

신뢰도가 높은 일치 항목은 이미 검증된 필터를 직접 재사용할 수 있다. 그렇지 않다면 5개의 예시는 생성기에 검증된 질문이 과거에 어떻게 번역됐는지 보여준다.

이 접근법은 제한 없는 생성보다 사례 기반 추론에 가깝다. 모델은 성공적인 과거 동작에서 가져온 압축된 스키마와 예시를 바탕으로 작업한다.

이 아키텍처는 모델 선택도 교체 가능하게 유지한다. Amazon Bedrock은 공유 서비스 계층을 통해 여러 모델 제품군에 접근할 수 있게 해 별도의 통합 작업을 줄인다.

이 유연성은 한 단계에 가장 빠르거나 정확한 모델이 바뀔 수 있기 때문에 중요하다. Orca는 전체 애플리케이션을 재설계하지 않고도 단계별 모델을 교체할 수 있다고 전해진다.

더 넓은 교훈은 모든 시스템에 9단계가 필요하다는 것이 아니다. 프로덕션 프롬프트에서 컨텍스트는 그 자리를 차지할 이유가 있어야 한다는 점이다.

스키마, 예시, 대화 기록은 모델이 큰 컨텍스트 윈도를 지원하더라도 비용을 발생시킨다. 관련 없는 자료는 중요한 증거와 경쟁할 수도 있다.

자연어 보안 쿼리에는 여전히 명확한 경계가 필요하다

대화형 인터페이스는 쿼리 언어의 마찰을 줄일 수 있지만, 권한 부여, 검증, 보안 전문성을 대체할 수는 없다.

자연어 보안 쿼리는 분석가가 조사 아이디어에서 구조화된 필터로 이동하도록 도울 수 있다. 그러나 질문 자체가 권한을 갖췄거나 완전하다는 보장은 하지 않는다.

Orca의 파이프라인에는 요청 컨텍스트, 가드레일 스크리닝, 제약된 생성, 두 가지 형태의 검증이 포함된다. 이 순서는 모델 출력을 실행 가능한 진실로 취급하는 위험을 인식한 것이다.

Amazon Bedrock 가드레일 평가는 구성된 정책에 따라 프롬프트와 응답을 검사할 수 있다. 사용 가능한 제어 항목에는 콘텐츠 필터, 금지 주제, 민감 정보 필터, 프롬프트 공격 탐지가 포함된다.

그러나 가드레일은 권한 부여 시스템이 아니다. 입력을 분류할 수는 있지만 액세스 결정에 필요한 사용자 신원과 리소스 권한은 여전히 갖추지 못할 수 있다.

AWS 보안 가이드는 이 차이를 명시한다. 해당 권한 부여 제어 지침은 언어 모델 외부에서 데이터 액세스를 강제하고 연결된 시스템을 통해 사용자 신원을 전파할 것을 권장한다.

이 분리는 클라우드 보안 데이터에서 특히 중요하다. 쿼리는 자산 이름, 취약점, 계정 관계, 네트워크 경로, 내부 구성 세부 정보를 노출할 수 있다.

광범위한 백엔드 액세스 권한을 가진 어시스턴트는 혼동된 대리인이 될 수 있다. 이는 권한이 더 낮은 사용자가 권한이 더 높은 중개자를 통해 정보를 얻을 때 발생한다.

안전한 아키텍처는 모델에 도달하는 데이터를 제한해야 한다. 또한 결과 Sonar 쿼리가 요청 사용자에게 적합한 권한으로 실행되도록 해야 한다.

공개된 아키텍처에 따르면 Orca는 요청을 조직 및 클라우드 제공업체 컨텍스트와 결합한다. 해당 게시물은 테넌트 격리나 사용자 수준 권한 부여 강제에 대한 자세한 설명을 제공하지 않는다.

이 누락이 취약점을 입증하는 것은 아니다. 다만 보고된 성능 결과를 완전한 보안 평가로 해석해서는 안 된다는 의미다.

검증은 또 하나의 중요한 경계를 만든다. Orca는 먼저 구문을 확인한 다음 Sonar API를 통해 생성된 필터를 검증한다.

검사가 실패하면 생성기는 구조화된 오류를 받는다. 따라서 또 다른 제약 없는 추측을 시작하는 대신 특정 필드, 연산자 또는 관계를 수정할 수 있다.

이 접근법은 존재하지 않는 스키마 요소를 참조하는 환각의 한 유형을 줄인다. 하지만 모든 유효한 쿼리가 분석가의 의도를 정확하게 포착한다는 것을 입증하지는 않는다.

필터는 구문적으로 유효하면서도 의미적으로 불완전할 수 있다. 올바른 모델을 선택하더라도 예외, 관계, 시간 경계 또는 환경 조건을 누락할 수 있다.

간결한 요청에 모호성이 숨겨져 있을 때 이 문제는 더 심각해진다. “노출된 데이터베이스를 보여줘”는 노출, 데이터베이스 유형, 네트워크 도달 가능성, 허용 위험의 정의에 따라 달라질 수 있다.

강력한 인터페이스는 가정을 드러내거나 검토할 수 있도록 생성된 필터를 보여줘야 한다. AWS 게시물은 필터 생성과 검증에 초점을 맞추며, 전체 검토 경험은 다루지 않는다.

보안 팀은 따라서 쿼리의 유효성과 조사 결과의 정확성을 구분해야 합니다. 전자는 스키마를 기준으로 기계적으로 검증할 수 있지만, 후자는 대체로 도메인 판단이 필요합니다.

시스템의 결정론적 종료 경로에도 주의가 필요합니다. 검증된 예시를 재사용하면 지연 시간을 낮출 수 있지만, 표면적으로 비슷한 질문이 부적절한 필터를 공유하지 않도록 일치 임곗값을 설정해야 합니다.

Orca는 신뢰도가 낮은 쿼리를 도메인 전문가에게 라우팅한다고 말합니다. 이러한 피드백 프로세스는 도움이 되지만, 그 효과는 샘플링, 검토 범위, 수정 품질에 달려 있습니다.

자연어 접근 방식은 보안 조사 참여 범위를 넓힐 수 있습니다. 동시에 이러한 안전장치를 구현하는 쿼리 작성자에서 플랫폼 설계자로 책임을 이동시킵니다.

진짜 상대는 단일 모델·단일 프롬프트 설계다

Orca가 가장 의미 있게 비교하는 대상은 다른 벤더가 아니라, 자신이 대체한 모놀리식 프로토타입입니다.

생성형 AI 제품은 흔히 성능 좋은 모델에 연결된 프롬프트 하나로 시작합니다. 이러한 구조는 모델이 작업을 이해하는지 검증하는 데 잘 작동합니다.

하지만 애플리케이션이 실제 트래픽, 변화하는 스키마, 엄격한 지연 시간 요구사항, 민감한 조직 데이터를 마주하면 이 구조를 방어하기가 더 어려워집니다.

Orca의 기준선은 이러한 전환을 드러냈습니다. 프로토타입은 고무적인 답변을 생성했지만, 매 요청마다 방대한 스키마를 전송했고 복잡한 관계를 처리하는 데도 어려움을 겪었습니다.

프로덕션 시스템은 생성기 밖으로 여러 책임을 옮겼습니다. 정규식은 정확한 식별자를 인식하고, 검색은 예시를 찾으며, 재순위화는 노이즈를 줄이고, 검증기는 형식이 잘못된 필터를 거부합니다.

이러한 분리는 중요한 역전 효과를 만들어 냅니다. 구성 요소를 추가했지만, 불필요한 생성 작업을 막았기 때문에 전체 비용과 지연 시간은 줄었습니다.

이 파이프라인은 모델 중심 조달 방식에도 의문을 제기합니다. 가장 큰 모델을 선택하는 것만으로는 프로덕션 문제를 해결할 수 없었습니다.

대신 Orca는 작업 요구사항에 따라 모델을 배정했습니다. 추론 비중이 큰 단계에는 Claude Haiku 4.5를, 더 좁은 범위의 선별 및 검증 단계에는 Nova 2 Lite를 배정했습니다.

Amazon Titan은 의미 검색용 임베딩을 만들었습니다. Cohere Rerank 3.5는 생성 전에 검색된 예시의 점수를 매겼습니다.

이러한 조합은 운영 복잡성을 만듭니다. 팀은 하나의 API 호출 대신 여러 모델, 검색 동작, 검증 루프, 의존성을 모니터링해야 합니다.

그러나 단일 호출 아키텍처는 복잡성을 거대한 프롬프트 안에 숨길 뿐입니다. 스키마 관리, 평가, 권한 부여, 오류 처리를 없애지는 않습니다.

Amazon Security Lake를 위한 이전 AWS의 자연어 조사 작업은 유사한 패턴을 보여줬습니다. 에이전트는 분석가의 질문을 SQL로 변환하고 보안 로그에 대한 후속 분석을 지원했습니다.

Orca의 구현은 자체 Sonar 데이터 그래프와 도메인별 필터를 대상으로 합니다. 차별점은 생성 전 스키마와 예시를 과감하게 축소한다는 점입니다.

이 패턴은 클라우드 보안을 넘어 적용될 수 있습니다. 엔터프라이즈 시스템은 흔히 수백 개의 객체, 필드, 관계, 허용된 작업을 제공합니다.

고객 지원 플랫폼, 분석 도구, 개발자 포털, 지식 시스템도 모든 정의를 프롬프트에 넣고 싶은 같은 유혹에 직면합니다. 이 접근법은 데모에서는 작동할 수 있지만, 프로덕션 경제성 아래에서는 실패할 수 있습니다.

대안은 컴파일러 파이프라인과 비슷합니다. 시스템은 요청을 파싱하고, 관련 구조를 식별하며, 선례를 검색하고, 중간 표현을 생성한 뒤 검증합니다.

언어 모델은 모호성과 번역을 처리합니다. 결정론적 구성 요소는 강제 가능한 규칙을 처리합니다.

이러한 분배는 실패 원인을 더 쉽게 찾도록 합니다. 팀은 검색이 관련 예시를 놓쳤는지, 선택 단계가 스키마를 누락했는지, 검증이 연산자를 거부했는지 판단할 수 있습니다.

단일 프롬프트는 대체로 덜 유용한 실패 신호를 만듭니다. 답변은 그저 틀렸거나, 비싸거나, 느리거나, 혹은 이 세 가지가 모두 겹친 결과입니다.

Orca는 평가 하니스가 정확성, 완전성, 참조 쿼리와의 의미적 동등성을 측정한다고 말합니다. 또한 질문 및 모델 카테고리에 따라 결과를 슬라이스로 나눕니다.

이는 하나의 종합 점수보다 더 많은 정보를 제공합니다. 시스템은 전체적으로는 잘 작동하면서도 드문 멀티클라우드 관계나 복잡한 취약점 조건에서는 실패할 수 있습니다.

이 설계는 다른 엔터프라이즈 AI 팀에도 시스템 수준의 결과를 보고하도록 압박합니다. 모델 벤치마크 점수만으로는 애플리케이션 지연 시간, 검색 품질, 검증 비율, 수정 작업량을 설명할 수 없습니다.

수치는 강력하지만 정확성 근거는 불완전하다

비용 및 지연 시간 개선 수치는 구체적이지만, 공개된 정확성 주장은 같은 수준의 측정 세부 정보를 제공하지 않습니다.

AWS와 Orca는 토큰, 비용, 응답 시간에 대한 명확한 전후 수치를 제공합니다. 그러나 평가 데이터셋, 표본 규모, 통과율, 정확성의 정확한 개선 폭은 공개하지 않습니다.

게시물은 복잡한 멀티모델 쿼리에서 정확성이 향상됐다고 말합니다. 또한 정확성, 완전성, 의미적 동등성을 평가하는 LLM-as-a-judge 시스템도 설명합니다.

LLM-as-a-judge는 생성된 결과를 평가하기 위해 다른 모델을 사용하는 방식입니다. 빠른 반복을 지원할 수 있지만, 결론은 루브릭, 참조 답변, 평가 모델의 신뢰성에 달려 있습니다.

Orca는 내부 전문가와 고객 피드백으로 자동 채점을 보완합니다. 제품 관리자, 지원 엔지니어, 보안 연구원은 결과에 플래그를 지정하고 수정된 예시를 추가할 수 있습니다.

신뢰도가 낮은 프로덕션 쿼리는 매일 라벨링 큐로 들어간다고 알려졌습니다. 수정 내용은 소프트웨어 배포 없이 이후 검색 실행에 반영됩니다.

Orca의 AI 디렉터인 Or Gabay는 이 라벨링 인터페이스를 팀의 가장 중요한 장기 품질 투자라고 평가했습니다. 이 발언은 또 다른 모델 업그레이드가 아니라 인간 중심 프로세스를 강조합니다.

이 프로세스는 개선 메커니즘으로서 신뢰할 만합니다. 하지만 외부 구매자와 엔지니어링 팀에는 여전히 몇 가지 미답의 질문이 남습니다.

공개 게시물은 생성이 재시도 한도에 도달하는 빈도를 공개하지 않습니다. 또한 결정론적 경로나 예시 재사용 경로를 이용하는 요청 수를 보고하지 않습니다.

중앙값 지연 시간과 꼬리 지연 시간도 구분하지 않습니다. 15초라는 수치는 일반적인 워크로드를 설명할 수 있지만, 더 느린 복잡한 요청을 감출 수 있습니다.

“비슷한 워크로드”라는 표현에는 더 많은 정의가 필요합니다. 토큰 및 비용 감소는 요청 구성, 선택된 모델, 캐시 동작, 출력 길이, 재시도 횟수에 따라 달라집니다.

보고된 비용 절감은 프로덕션 파이프라인을 Orca 자체의 초기 기준선과 비교한 것입니다. 다른 클라우드 보안 제품이나 쿼리 생성 시스템과의 벤치마크는 아닙니다.

독자는 이 비율을 회사가 보고한 운영 결과로 받아들여야 합니다. AWS와 공동 작성한 사례 연구는 기술적 세부 정보를 제공하지만 독립 감사는 아닙니다.

2026년 3월 프로덕션 도입 시점과 하루 수천 건의 쿼리는 유용한 채택 신호를 제공합니다. 하지만 고유 사용자 수, 수용률, 이탈, 분석가의 절감 시간은 드러내지 않습니다.

이러한 지표는 자연어가 조사 행동을 바꾸는지 판단하는 데 도움이 됩니다. 추론 비용 절감은 중요하지만, 사용자 가치는 궁극적으로 더 나은 더 빠른 보안 의사결정에 달려 있습니다.

시스템의 피드백 루프는 또 다른 상충 관계를 도입합니다. 프로덕션 예시는 범위를 넓히지만, 전문가가 공유된 정책을 따르지 않으면 수정 사항이 일관되지 않은 해석을 담을 수 있습니다.

늘어나는 예시 저장소에도 거버넌스가 필요합니다. 팀에는 버전 관리, 품질 검토, 제거 절차, 검색된 예시에 민감한 정보가 유입되지 않도록 하는 보호 장치가 필요합니다.

생성형 AI 애플리케이션을 위한 AWS 지침은 모델에 도달하기 전에 검색 데이터를 제한할 것을 권고합니다. 해당 보안 통제는 데이터 계층의 ID 전파와 접근 제어 시행을 강조합니다.

이러한 우려가 Orca의 결과를 부정하는 것은 아닙니다. 다른 조직이 이 아키텍처를 재사용 가능한 템플릿으로 취급하기 전에 필요한 근거를 정의할 뿐입니다.

가장 강력한 공개 결론은 제한적이지만 유용합니다. Orca는 컨텍스트 선택, 모델 전문화, 검색, 검증이 기존 설계를 크게 개선했다고 보고합니다.

이 근거는 모든 스키마 중심 에이전트에 대한 보편적 감소를 입증하지는 않습니다. 팀은 자체 워크로드와 권한 부여 요구사항에 맞춰 이 패턴을 측정해야 합니다.

Orca의 Amazon Bedrock 배포 이후 주목할 점

다음 시험대는 스키마, 사용자 행동, 모델 버전이 계속 변화하는 상황에서도 Orca가 품질을 유지할 수 있는지입니다.

첫 번째 신호는 공개되는 정확성 세부 정보입니다. 향후 기술 보고서에는 데이터셋 규모, 쿼리 카테고리, 통과 임곗값, 사람 검토와의 일치도가 공개되어야 합니다.

슬라이스 수준 결과는 특히 가치가 있습니다. 멀티모델 관계 쿼리는 가장 어려운 카테고리이자 Orca 아키텍처의 가장 강력한 시험대로 보입니다.

더 투명한 평가는 새 설계가 효율성뿐 아니라 정확성도 개선했다는 주장을 강화할 것입니다. 수정 또는 재시도 비율이 상승하면 이 결론은 약화됩니다.

두 번째 신호는 지속적인 프로덕션 도입입니다. Orca는 Discovery AI가 하루 수천 건의 쿼리를 처리한다고 말하지만, 장기 사용 패턴은 분석가들이 인터페이스를 신뢰하는지 보여줄 것입니다.

유용한 지표에는 반복 사용, 수용된 필터, 수동 편집, 절감된 시간, 에스컬레이션 없이 해결된 질문의 비율이 포함됩니다. 이 측정값들은 모델 동작을 보안 운영과 연결합니다.

세 번째 신호는 파이프라인이 변화를 처리하는 방식입니다. Sonar의 스키마는 진화하고, 고객은 낯선 질문을 하며, 파운데이션 모델에는 새 버전이 나올 것입니다.

Orca의 모델 독립적 설계는 교체를 더 쉽게 해야 합니다. 하지만 각 변경 사항은 여전히 검색, 생성, 검증, 권한 부여 경계 전반에 걸쳐 회귀 테스트가 필요합니다.

따라서 지속적 평가 하니스는 초기 아키텍처만큼 중요합니다. 모든 프롬프트, 모델, 검색 설정, 예시는 예상치 못한 슬라이스에서 동작을 바꿀 수 있습니다.

시스템은 변화하는 위협 행위에도 유용성을 유지해야 합니다. 분석가들은 클라우드 위협 프레임워크에 맞춰 조사를 매핑할 수 있지만, 공격자들은 새로운 경로와 리소스 조합을 채택합니다.

정적인 예시 라이브러리는 이러한 조건에서 노후화됩니다. Orca의 전문가 라벨링 루프는 검색 저장소가 새롭게 등장하는 질문과 정렬된 상태를 유지하도록 설계됐습니다.

엔지니어링 팀이 즉시 취할 수 있는 조치는 대형 프롬프트에 대부분의 요청이 결코 사용하지 않는 자료가 어디에 담겨 있는지 살펴보는 것입니다. 그러한 자료는 선택, 검색 또는 결정론적 라우팅 뒤에 배치될 수 있습니다.

팀은 또한 세 가지 테스트를 분리해야 합니다. 쿼리가 유효한지, 사용자의 의도를 나타내는지, 사용자가 그 결과에 접근할 권한이 있는지입니다.

Orca Security Discovery AI는 이러한 계층형 접근법의 주목할 만한 프로덕션 사례를 제공합니다. 보고된 효율성 향상은 상당하지만, 더 깊은 기여는 시스템 설계의 변화입니다.

이제 문제는 Orca가 이러한 효율성이 변화하는 스키마와 적대적 사용 환경에서도 유지된다는 점을 보여줄 충분한 운영 근거를 공개하는지입니다. 그 근거가 이 패턴이 엔터프라이즈 에이전트를 위한 더 넓은 표준이 될지를 결정할 것입니다.