오랫동안 저를 괴롭혔던 문제가 하나 있습니다.

모든 프로덕션 에이전트(production agent)는 어떤 형태로든 메모리(memory)를 가지고 있습니다. 사실, 제약 조건, 사용자 선호도를 저장하고, 에이전트는 이를 검색(retrieve)합니다. 작업이 성공하거나 실패하면, 여러분은 반복(iterate) 과정을 거칩니다.

하지만 루프(loop)에는 공백이 존재합니다. 어떤 메모리 결정이 좋았는지 전혀 알 수 없다는 점입니다.

그 제약 조건이 실제로 도움이 되었을까요? 해당 선호도를 검색함으로써 낭비되는 토큰(token)을 줄였을까요? 오래된 세션 사실을 유지한 것이 작업의 조용한 실패(fail silently)를 유발했을까요? 여러분은 알 수 없습니다. 에이전트는 끊임없이 메모리 결정을 내리지만, 그중 어느 것도 학습할 수 있는 흔적을 남기지 않습니다.

저는 이 문제를 다르게 생각하기 시작했습니다. 에이전트가 무엇을 기억할지 결정할 때마다, 그것은 하나의 결정입니다. 그리고 결정은 강화학습 (Reinforcement Learning, RL) 관점에서 상태(state), 보상(reward), 그리고 측정 가능한 결과(outcome)를 가진 행동(action)으로 취급될 수 있습니다.

그래서 저는 memcell-rl을 구축했습니다.

이것이 실제로 하는 일
memcell-rl의 모든 메모리 셀(memory cell)은 타입(typed)이 지정되어 있습니다. 단순히 문자열이 아닙니다. cell_type (제약 조건, 선호도, 사실, 에피소드), scope (전역, 세션, 작업), 중요도 점수(criticality score), 그리고 민감도 수준(sensitivity level)을 가집니다. 이 메타데이터(metadata)가 바로 정책(policy)이 결정을 내리는 데 사용하는 요소입니다.

에이전트가 "지금 무엇을 기억해야 할까?"라고 물을 때, 시스템은 정책을 실행하고, 셀을 선택하며, — 이 부분이 핵심입니다 — 전체 전이(transition)를 기록합니다:

상태 (State): 어떤 셀을 사용할 수 있었는지, 토큰 예산(token budget), 컨텍스트 내의 셀 타입
행동 (Action): 어떤 셀이 선택되거나 억제(suppressed)되었는지
보상 (Reward): 작업이 성공했는가? 오래된 메모리 오류(stale memory error)가 있었는가? 얼마나 많은 토큰이 사용되었는가?
다음 상태 (Next state): 이후의 메모리 상태

시간이 흐르면서, 이는 데이터셋을 구축합니다. 이를 내보내어 누군가가 사전에 작성한 규칙이 아닌, 실제 결과로부터 학습하는 정책을 훈련할 수 있습니다.

현재 정책은 베이스라인(baseline)입니다
baseline_v0는 규칙 기반(rule-based)입니다. 만료되거나 삭제된 셀에 대한 엄격한 억제(hard suppression), 민감한 정보가 사용되기 전의 격리(quarantine) 확인, 우선순위에 따른 토큰 예산 강제 적용 등이 포함됩니다. 작동은 하지만, 정적(static)입니다.

흥미로운 질문 — 제가 지향하고 있는 목표 — 은 학습된 정책 (learned policy)이 어떤 모습일 것인가 하는 점입니다. 실제 에이전트 세션(agent sessions)을 통해 학습되어, 어떤 메모리 결정이 실제로 더 나은 결과로 이어지는지를 데이터로부터 알고 있는 정책 말입니다.

해당 리포지토리(repo)는 /v1/rl/dataset 경로를 통해 완료된 전이 (transitions) 데이터를 내보냅니다. 이 형식은 DQN, 행동 복제 (behavioral cloning), 또는 그 외 어떤 방식에도 바로 연결할 수 있을 만큼 충분히 깔끔합니다. 이것이 장기적인 목표입니다.

로컬에서 실행되며, SaaS나 벤더(vendor)가 없습니다.
모든 것이 SQLite로 구성되어 있습니다. API는 일반적인 HTTP입니다. Docker 컨테이너, 노트북, 또는 CI 환경 내에서 실행할 수 있습니다. 데이터는 사용자의 기기를 떠나지 않습니다.

테스트 스위트 (test suite)에는 정책 강제 (policy enforcement), 보상 계산 (reward computation), RL 전이 (RL transitions), 데이터셋 내보내기 (dataset export) 등 전체 API를 아우르는 42개의 테스트가 포함되어 있습니다. 이 테스트들은 모두 API 키 없이 통과합니다.

pytest tests/ -q
42 passed in 1.83s
저는 아직 초기 단계에 있습니다. 가장 어려운 부분은 API가 아닙니다. 메모리 결정에 대한 적절한 보상 함수 (reward function)를 찾아내는 것, 그리고 학습된 정책이 서로 다른 에이전트 워크로드 (agent workloads) 전반에 걸쳐 실제로 일반화 (generalize)될 수 있는지 여부를 파악하는 것입니다.

실제 메모리 요구 사항이 있는 에이전트를 구축하고 있으며 이 문제에 직면했다면, 진심으로 이야기를 나누고 싶습니다. 댓글을 남기거나 이슈 (issue)를 생성해 주세요.

→ github.com/adu3110/memcell-rl