경험으로부터 학습한다고 주장하는 대부분의 에이전트 (Agent) 시스템은 사실상 단순히 기록 (Logging)을 하고 있을 뿐입니다. 이들은 발생한 일을 기록하고, 그중 일부를 다음 프롬프트 (Prompt)에 다시 입력하며 이를 메모리 (Memory)라고 부릅니다. 그렇게 해서 단 한 번 더 나은 결과가 나오면 그 방식은 검증된 것으로 취급됩니다. 반대로 단 한 번 더 나쁜 결과가 나오면 버려집니다. 어느 쪽이든 단 한 번의 실행이 미래의 행동을 결정하게 되는데, 단 한 번의 실행은 노이즈 (Noise)일 뿐입니다.

흥미로운 설계 질문은 에이전트가 경험으로부터 학습할 수 있는지 여부가 아닙니다. 그 경험이 에이전트의 행동을 변화시키도록 허용되기까지 얼마나 많은 증거가 요구되어야 하는가 하는 점입니다.

보류 중인 패턴 (Pending Patterns) 과 확정된 패턴 (Confirmed Patterns)

우리가 결정한 방식은 패턴 (Pattern)을 규칙 (Rule)과 분리하는 것입니다.

시스템이 과거의 작업 내용을 검토할 때, 유사한 결과가 나타나는 유사한 상황들의 클러스터 (Clusters)를 찾습니다. 동일한 접근 방식이 계속 성공하거나 계속 실패한다면, 이는 '보류 (Pending)' 상태의 잠정적인 패턴으로 기록됩니다. '보류'란 인지되었으나 신뢰되지는 않았음을 의미합니다.

보류 중인 패턴이 '확정 (Confirmed)' 상태로 승격되어 에이전트가 실제로 따르는 지침으로 취급되려면, 이후 작업에서 다섯 번의 별도 확인 관찰 (Confirming observations)이 필요합니다. 만약 모순되는 증거가 세 번 나타나면, 해당 패턴은 자동으로 비활성화됩니다.

이 두 숫자가 전체적인 안전장치 역할을 합니다. 다섯 번의 확인은 패턴이 우연히 작동했던 단 한 번의 상황이 아니라, 독립적인 상황들에 걸쳐 유지되어야 함을 의미합니다. 세 번의 모순은 더 이상 사실이 아니게 된 규칙이 누군가 버그 (Bug)를 보고할 필요 없이 스스로 집행을 중단함을 의미합니다.

하나의 로그가 아닌, 열 가지 종류의 메모리

검색 (Retrieval) 품질은 당신이 어떤 종류의 것을 찾고 있는지 아는 것에 달려 있습니다. 따라서 메모리 뱅크 (Memory bank)는 구별되지 않은 하나의 역사적 더미가 아니라 유형화 (Typed)되어 있어야 합니다.

기술 (Skills)은 문제 범주에 대해 재사용 가능한 접근 방식을 저장합니다. 도구 (Tools)는 시스템이 실행할 수 있는 모든 스크립트와 절차를 카탈로그화합니다. 프로젝트 (Projects)는 진행 중인 작업을 추적하여 시스템이 이미 가지고 있는 것을 다시 만들지 않도록 합니다. 기억 (Memories)은 결과와 함께 단기적인 사건들을 기록합니다. 경험 (Experience)은 무기한으로 유효한 지식을 보유합니다. 보상 (Rewards)은 인간이 설정한 규칙과 관찰을 통해 학습된 규칙 모두를 포함하는 행동 규칙을 보유합니다. 질문 (Questions)은 질문된 내용을 추적하며, 답변이 알려진 경우 답변을 함께 저장합니다. 아이디어 (Ideas)는 테스트되지 않은 제안들을 보관합니다. 상호 참조 (Cross references)는 정보가 어디에 있는지 가리킵니다. 사람 (People)은 시스템이 함께 협업하는 인간에 대해 알고 있는 정보를 저장합니다.

모든 쿼리 (Query)는 키워드 매칭이 아닌 로컬 벡터 임베딩 (Local vector embeddings)을 사용하여 의미론적 관련성 (Semantic relevance)에 따라 순위가 매겨집니다. 코드를 배포 (Deploy)하는 방법을 검색하면, 해당 항목들에 'deploy'라는 단어가 포함되어 있지 않더라도 프로덕션 배포 (Pushing to production), 빌드 프로세스 (Build processes), 릴리스 관리 (Release management)에 관한 항목들이 나타납니다. 시스템은 에이전트가 항상 작업할 수 있는 무언가를 가질 수 있도록 최소 3개의 결과를 반환하며, 많은 항목이 실제로 관련이 있는 경우에는 최대 20개까지 반환합니다.

당신 없이도 실행되는 학습

세 가지 파이프라인 (Pipelines)이 요청을 기다리는 대신 지속적으로 실행됩니다.

자기 학습 (Self learning) 파이프라인은 세 단계로 최근 작업을 검토합니다. 먼저 제한 없이 개선 사항을 브레인스토밍하고, 그다음 비판적인 사고방식으로 전환하여 각 아이디어를 정직하게 평가하여 추구할 가치가 없는 것들을 폐기하며, 마지막으로 살아남은 것들을 시스템의 동작 방식에 대한 실제 변경 사항으로 구현합니다.

적응형 코딩 (Adaptive coding) 파이프라인은 소프트웨어를 구축하고 수정하는 작업을 처리합니다. 무엇이 존재해야 하는지 식별하고, 이를 계획하고, 작성하며, 버그와 품질 문제를 확인하기 위해 자신의 출력을 검토하고, 발견된 것을 수정하며, 작업을 완료하기 전에 결과를 검증합니다.

적응형 연구 (Adaptive research) 파이프라인은 시스템이 아직 알지 못하는 것을 찾아가서 학습합니다. 주제를 광범위하게 탐색하고, 세부 사항을 검색하며, 정확성을 위해 발견 내용을 교차 검증하고, 살아남은 내용을 다른 모든 에이전트가 접근할 수 있는 검색 가능한 지식으로 분류합니다.

브레인 에이전트 (brain agent)는 이 세 가지 모두의 상위에 위치하여, 로그를 검토하고, 작업의 일관성을 확인하며, 행동 패턴을 추출하고, 사용자의 목표에 따라 다음에 무엇을 우선시할지 결정합니다.

임계값(Threshold)이 곧 제품이다

무언가를 기억하는 에이전트를 만드는 것은 쉽습니다. 하지만 그 기억을 신뢰할 수 있는 에이전트를 만드는 것은 더 어려우며, 그 차이는 거의 전적으로 에이전트에게 어떤 증거 기준 (standard of evidence)을 적용하느냐에 달려 있습니다.

모든 결과로부터 학습하는 에이전트는 일주일 안에 자신 있게 헛소리를 내뱉을 것입니다. 반대로 전혀 업데이트하지 않는 에이전트는 그저 값비싼 스크립트일 뿐입니다. 유용한 범위는 그 사이에 있으며, 확인 임계값 (confirmation threshold)을 어디에 설정하느냐가 진정한 설계 결정 사항입니다.

파이프라인, 메모리 유형 및 보상 엔진 (rewards engine)에 대한 전체적인 분석은 https://www.aiappsapi.com/autonomousagents/에서 확인할 수 있습니다.