에이전트 메모리에도 OpenTelemetry 같은 합의가 필요하다

아니다, 그렇지 않다. LLM 공간에서는 여전히 많은 혁신과 변화가 일어나고 있고, 만능 해결책은 없다. 내가 알기로는 해결책은 속도, 정확성, 비용이라는 세 가지 주요 고려사항 사이에서 균형을 잡아야 한다. 메모리를 파일로 하는 것조차 아직 확정되지 않았다고 생각한다. 이 공간에는 혁신과 발전의 여지가 너무나 많다.

블로그 글 전체가 LLM 냄새가 난다.

LLM 텍스트를 적절히 신뢰할 수 있게 탐지하는 방법이 있다면, 그걸 걸러내는 브라우저 확장 프로그램을 만들 텐데.

일반적인 전제에는 동의한다. 하지만 그 시점이 오늘이라고는 생각하지 않는다, 적어도 아직은. 우리는 아직 컨텍스트와 메모리에 접근하는 올바른 방법이나 그것들이 얼마나 오래 지속되어야 하는지 이해하지 못한다. 하물며 성급하게 추상화를 표준화해서 SOAP나 SGML처럼 되어버리는 일은 말할 것도 없다.

정말 이게 필요한가..? LLM이 잘하는 것은 자연어를 해석하는 것이다. 그래서 특정 프로젝트에서 사용되는 어떤 포맷이든 흡수하는 스펀지 같은 존재다. 미리 정의된 포맷은 별로 필요 없다.

게다가 사용자 A의 에이전트 메모리가 사용자 B의 메모리와 공존하기를 정말 원하는가? 그렇지 않다. 그래서 협업과 공유에 대한 주장은 상당히 빈약하다, 적어도 코딩 에이전트에게는. 저장소 특정 컨텍스트는 에이전트 이전 시대에도 그랬듯이 docs/나 architecture/ 디렉터리에 인코딩할 수 있다.

배포된 에이전트 모니터링에는? 어쩌면. 이를 위해 나는 (또 하나의) 메모리 관리 도구 slivingdoc.dev를 만들었다. 이것으로 모든 에이전트의 지속적인 컨텍스트를 끌어올 수 있다. 하지만 여기서 문제는 분산 시스템 문제이지, 메모리의 포맷 문제가 아니다.

통합 포맷이나 명세의 필요성은 에이전트 메모리의 경우 크게 줄어든다. 정의상 에이전트가 읽는 것이고, 에이전트는 이미 다양한 포맷의 메모리 파일을 읽도록 지시받거나 프로그래밍되어 있기 때문이다. 그러한 지시가 없더라도, 에이전트는 필요한 컨텍스트를 얻기 위해 파일을 탐색하는 데 매우 능숙하다.

이 문제에 대해 표준화를 주장하기에는 너무 이르다. Otel은 해당 분야에서 수십 년의 경험을 쌓은 후 개발되었고, 우리는 수많은 해결책을 탐구하고 Otel을 개발할 때 그것들을 활용했다.

지금 에이전트 메모리 해결책에서 충분히 탐구해서 표준화하고 추가 실험에 마찰을 더할 수 있다고 말하는 것은 실수라고 생각한다.

문제를 찾기 위해 만들어진 해결책이다. 메모리, 아니 사실 전체 저장 계층은 에이전트와 일상 워크로드에 보이지 않아야 한다. 아무도 뛰어난 저장 능력 때문에 에이전트를 만들거나 팔지 않는다. 그걸로 무엇을 할 수 있는지가 중요하다.

아무도 메모리 때문에 에이전트를 만들지 않는다. 하지만 그 위에 구축한다. 사용자가 실제 비즈니스 문제에 집중할 수 있도록 해결책을 단순화하는 것이다. 그 이상은 아니다.

작은 홍보 - 나는 https://github.com/Polign/recall을 몇몇 프로덕션 워크플로에서 실행해 왔는데, 가장 많이 듣는 말은 그냥 잘 작동한다는 것이다.