저자: 0xhhh 출처: X, @hhh69251498
Eliza 원리 소개 이 시리즈는 3부로 나누어 작성됩니다:
Provider와 Action의 작동 원리
Evaluator의 작동 원리
Eliza Memory의 설계 사상
현재는 첫 번째 글로, Provider와 Action의 작동 원리를 주로 소개합니다.
1. Eliza의 아키텍처는 다음과 같이 3개 부분으로 구성됩니다
최상위 추상화 레이어에는 Provider, Evaluator, Action이 있으며, 각각 인간의 정보 획득 능력(눈으로 시각 정보, 귀로 청각 정보 등)과 정보에 따른 실행 능력(예: BTC 미래 판단), 그리고 Evaluator는 인간의 사고 능력과 유사하게 대량의 정보에서 지식을 추출하여 인지를 형성합니다.
가장 하위 레이어에는 다양한 AI 모델이 있습니다. Eliza 프레임워크는 openai, claude, 제미니, gork, xai 등 대부분의 AI 모델을 지원하며, 이는 모든 의사 결정의 핵심 처리 모듈과 유사한 인간의 뇌입니다.
메모리는 Eliza 프레임워크로 구동되는 AI 에이전트에게 콘텐츠 제한을 벗어날 수 있는 능력을 부여합니다. AI는 Provider 단계에서 환경에서 획득한 정보와 Action 실행 결과를 압축하여 메모리에 저장할 수 있으며, Evaluator를 통해 인간과의 대화나 기타 상호 작용 과정에서 핵심 정보를 추출할 수 있습니다(다음 스레드에서 자세히 설명).
2. 다음으로 「Provider」와 「Action」의 작동 원리를 자세히 설명하겠습니다
「Provider」
Provider에 대해 다음 3가지 질문을 생각해 봐야 합니다:
왜 Provider가 필요한가(Eliza 프레임워크에서 Provider 구성 요소를 설계한 이유)?
AI는 Provider가 제공한 정보를 어떻게 이해하는가?
Provider를 어떻게 호출하는가(Eliza 프레임워크 내 AI가 Provider를 통해 정보를 얻는 방법)?
왜 Provider가 필요한가?
Provider는 프롬프트를 통해 AI가 정보를 얻는 것이 정확하지 않고 충분하지 않은 문제를 해결하기 위해 도입되었습니다. 현재 사용되는 모델은 범용 대규모 모델이므로, 특정 분야의 정보 획득에 때때로 충분하지 않은 문제가 있습니다.
예를 들어 아래 코드는 Eliza의 TokenProvider 구현으로, 제공된 API를 통해 토큰의 다양한 핵심 정보(예: 상위 10명 홀더와 각자의 토큰 점유율, 24시간 가격 변동 등)를 가져와 텍스트 형태로 AI 모델에 반환합니다. 이를 통해 AI 모델은 밈 토큰 구매 여부에 대한 핵심 의사 결정을 내릴 수 있습니다.
그러나 만약 우리가 프롬프트를 통해 AI에게 이러한 정보를 직접 요청한다면, AI는 해당 정보를 가져오는 코드를 제공할 것입니다(때로는 실행 오류가 발생하여 수정 후 재실행해야 함). 하지만 우리는 여전히 이를 블록체인 환경에 배포해야 하고 신뢰할 수 있는 API 키를 제공해야 합니다.
예를 들면 다음과 같습니다:
따라서 데이터 획득의 원활성을 보장하기 위해 Eliza 프레임워크에서는 이 데이터 획득 코드를 Provider 정의에 캡슐화했습니다. 이를 통해 우리는 솔라나 상의 자산 정보를 쉽게 가져올 수 있게 되었습니다. 이것이 Why need Provider의 핵심 이유입니다.
AI는 Provider가 제공한 정보를 어떻게 이해하는가?
Eliza 프레임워크는 Provider를 통해 얻은 정보를 최종적으로 자연어 형태의 텍스트로 AI 모델에 반환합니다. 이는 AI 모델이 요구하는 정보 요청 형식이 자연어이기 때문입니다.
Provider를 어떻게 호출하는가(Eliza 프레임워크 내 AI가 Provider를 통해 정보를 얻는 방법)?
현재 Eliza 프레임워크에서 Provider는 인터페이스 추상화를 제공하지만, Provider 호출 방식은 모듈화되어 있지 않습니다. 대신 특정 Action이 자신의 정보 요구에 따라 해당 Provider를 직접 호출합니다. 관계도는 다음과 같습니다:
예를 들어 BuyToken Action이 사람의 추천에 따라 토큰을 구매할지 판단할 때, 이 Action 실행 과정에서 TokenProvider와 WalletProvider를 요청합니다. TokenProvider는 토큰 구매 판단에 도움이 되는 정보를 제공하고, WalletProvider는 거래 서명에 필요한 개인 키 정보와 지갑의 가용 자산 정보를 제공합니다.
「Action」
Action의 정의는 다음 GitHub 링크에서 쉽게 찾을 수 있지만, 코드를 깊이 살펴보지 않으면 이해하기 어려울 것입니다:
왜 Action이 필요한가?(Eliza 프레임워크에서 Action이 필요한 이유)
Action을 어떻게 호출하는가?(Eliza 프레임워크에서 AI가 Action을 호출하는 방법)
Eliza 프레임워크의 Action은 구체적으로 무엇을 실행하는가?
AGI가 방금 호출한 Action이 무엇을 했는지 어떻게 이해할 수 있는가?
왜 Action이 필요한가?(Eliza 프레임워크에서 Action을 추상화한 이유)
예를 들어 내가 AI에게 말한다면:
내 개인 키는
0xajahdjksadhsadnjksajkdlad12612
여기에 10 SOL이 있는데, 100개의 Ai16z 토큰을 구매해 줄 수 있나요?
Claude의 답변은 다음과 같습니다:
이처럼 개인 키를 직접 제공하는 것은 안전하지 않으며, AGI도 이러한 온체인 작업을 실행하기 어렵습니다.
여기서 우리는 AGI에게 다음과 같이 물어볼 수 있습니다: 내 지갑에 SOL이 있을 때, 모든 SOL을 내가 지정한 밈 토큰으로 구매할 수 있는 실행 코드를 작성해 줄 수 있나요?
물론 Claude는 이 기능을 구현할 수 있지만, 우리가 여러 번 안내해야 합니다.
따라서 우리는 AI가 제공한 코드를 Eliza의 Action으로 캡슐화하고, 프롬프트 예시를 제공하여 AI가 어떤 경우에 이 Action을 호출해야 하는지 이해할 수 있도록 도와줄 수 있습니다.
(실제 사용 시나리오에서 우리가 원하는 작업은 이보다 훨씬 복잡합니다. 예를 들어 스왑 거래 시 슬리피지 제한 등의 조건 제한을 AI 대규모 모델이 완벽하게 만족시키기는 어렵습니다.)
Action을 어떻게 호출하는가?(Eliza 프레임워크에서 AI가 Action을 호출하는 방법)
다음은 Eliza 프레임워크에서 AI 모델이 Pumpfun에서 밈 토큰을 생성하고 구매하도록 하는 프롬프트 예시입니다. 우리가 해당 Action에 이러한 예시를 제공하면, AI 에이전트는 향후 사람과의 상호 작용 과정에서 유사한 내용이 나오면 이 Action을 호출할 것입니다.
그리고 Eliza 프레임워크는 다음과 같은 HandlerMessageTemplate를 제공하여, AI 모델이 상황에 맞는 적절한 Action을 선택할 수 있도록 합니다.
실제로 이 템플릿은 데이터를 논리적으로 재구성하여 AI 모델에 제공함으로써, AI 모델이 이 미리 정의된 Action을 더 정확하게 호출할 수 있게 합니다(이는 AI 모델 클라이언트를 직접 사용하는 것보다 쉽습니다).
Eliza 프레임워크의 Action은 구체적으로 무엇을 실행하는가?
https://github.com/elizaOS/eliza/blob/main/packages/plugin-solana/src/actions/pumpfun.ts#L279
여기서도 Pumpfun Action의 예를 들어 설명하겠습니다. 그 흐름은 다음과 같습니다:
WalletProvider와 TokenProvider에서 정보를 가져옵니다.
밈 토큰 생성 및 구매 거래를 생성합니다.
거래에 서명하고 체인에 전송합니다.
콜백 함수를 호출하여 Action 실행 결과를 처리합니다.
핵심은 두 부분입니다. 하나는 Provider에서 정보를 가져오고, 다른 하나는 실행 동작을 생성하는 것입니다.
AGI가 호출한 Action이 무엇을 했는지 어떻게 이해할 수 있는가?
이 문제를 해결하지 않으면 AI가 관련 작업을 이해하고 실행할 수 없습니다.
해결책은 다음과 같습니다: Action 실행 후 결과를 요약한 텍스트를 AI의 메모리에 추가합니다.
세부 사항은 다음과 같습니다: Action의 Handle 함수
