이 기사는 Yunshan Network의 DeepFlow 제품 리더인 Xiang Yang이 QCon 글로벌 소프트웨어 개발 컨퍼런스(베이징) 2024 에서 "eBPF + LLM: 관찰 가능한 에이전트 실현을 위한 인프라"라는 주제로 공유한 연설을 편집한 것입니다 . 링크를 검토 하고 PPT를 다운로드하세요 .
둘째날 등록 카운트다운! Observability 오픈 소스 개발자 모임에 참여하세요 |
오늘 저는 DeepFlow가 관찰 가능성 에이전트에 대해 수행한 작업 중 일부를 여러분과 공유하게 되어 기쁘게 생각합니다. 오늘의 주제는 주로 두 가지 측면, 즉 eBPF를 사용하여 데이터 품질 문제를 해결하는 방법과 LLM을 사용하여 이를 기반으로 효율적인 에이전트를 구축하는 방법을 포함합니다. 이 두 가지 측면에서 eBPF와 LLM이 관측성 에이전트를 실현하기 위한 핵심 인프라인 이유를 알 수 있습니다 .
위의 첫 번째 질문은 실제로 데이터 거버넌스 문제입니다. 조직 사양을 사용하고 R&D 엔지니어링 효율성을 높이는 등 고품질 데이터를 얻는 방법은 많습니다. 오늘 제가 공유하는 내용은 주로 후자, 특히 혁신적인 기술인 eBPF를 사용하여 침입 없이 전체 스택 관측 가능성 데이터를 얻는 방법에 대한 것입니다. 고품질 데이터를 얻은 후에는 프롬프트 단어 엔지니어링, RAG, 미세 조정 및 기타 방법과 결합된 LLM을 사용하여 효율적으로 관찰 가능한 에이전트를 구축할 수 있습니다. 오늘 공유된 사례는 점점 더 인기를 끌고 있는 오픈 소스 프로젝트인 관찰 가능성 제품 DeepFlow에서 나온 것입니다. 마지막으로 관찰 가능한 에이전트의 진화에 대한 내 생각도 공유하겠습니다.
01
eBPF를 사용하여 고품질 관측성 신호 소스 구축
첫 번째 이슈의 본질은 고품질의 관측 가능한 데이터 획득을 목표로 하는 데이터 거버넌스입니다. 먼저 기존 솔루션을 살펴보겠습니다. 예를 들어 APM을 사용하여 현재 데이터의 무결성과 관련성을 보장하는 방법은 무엇입니까? 특히 클라우드 네이티브 환경에서는 클라이언트가 서버에 접속할 때 복잡한 K8s 네트워크, 다양한 게이트웨이, 다양한 미들웨어, 데이터베이스, DNS 및 기타 기본 서비스를 통과할 수 있습니다. , APM의 관찰된 위치와 프로세스의 실제 네트워크 요청도 다를 수 있습니다. 이를 기반으로 데이터 거버넌스 및 데이터 분석을 수행할 때 일반적으로 데이터의 무결성 및 일관성에 문제가 있음을 발견합니다. 비즈니스 측 계측 적용 범위를 홍보하고 개선하는 데 많은 시간과 에너지가 소요되는 경우가 많습니다. 다수의 기본 서비스의 이기종 데이터를 연결하려면 패킷 캡처와 로그 및 기타 방법을 사용해야 합니다. 아래 그림은 APM을 사용할 때 자주 발생하는 문제인 것으로 생각됩니다. 클라이언트에서 관찰된 지연은 500ms이지만 서버에서 관찰된 지연은 10ms에 불과합니다. 더 나쁜 것은 서버가 계측을 전송하지 않았을 수도 있다는 것입니다. 아직.
집에 더 가까이, eBPF가 고품질 관측 신호 소스를 위한 인프라라고 말하는 이유는 무엇입니까 ? eBPF 기술은 커널 프로그래밍 가능 기술입니다. 아래 그림의 작은 벌은 eBPF가 Hook할 수 있는 기능 위치입니다. eBPF를 사용하면 Hook 비즈니스 기능, 시스템 호출, 커널 기능, 네트워크 및 디스크 드라이버 기능을 통해 클라우드 호스트에 있는 모든 프로세스의 모든 내부 상태를 인식할 수 있습니다. 더 중요한 것은 eBPF Verifier가 존재하기 때문에 이 작업이 완전히 안전하고 JIT 컴파일 메커니즘으로 인해 성능이 커널의 네이티브 코드와 비슷하다는 것입니다.
eBPF 기술은 두 가지 고유한 장점을 가지고 있으며 APM이 직면한 데이터 품질 문제를 잘 해결할 수 있습니다. 첫 번째 장점은 제로 침입(Zero Code) 입니다 . eBPF 프로그램의 작동에는 코드 수정, 재컴파일 또는 애플리케이션 프로세스의 재시작이 필요하지 않습니다. 이는 언제든지 프로덕션에 업로드할 수 있는 플러그 앤 플레이 기술입니다. 시간. 두 번째 장점은 Full Stack 입니다 . 비즈니스 프로세스, 게이트웨이, 메시지 대기열, 데이터베이스 또는 운영 체제 등 eBPF를 사용하여 관찰 데이터를 수집할 수 있습니다. 따라서 프로세스가 실행 중일 때 비즈니스 로직에서 언어 런타임, 공유 라이브러리에서 커널, 하드웨어 드라이버에 이르기까지 전체 소프트웨어 스택과의 상호 작용을 모두 eBPF를 사용하여 다룰 수 있습니다. 아래 그림에서 프로세스 이벤트, 파일 이벤트, 성능 이벤트, 소켓 이벤트, 커널 이벤트 및 하드웨어 이벤트를 포함하여 eBPF가 수집할 수 있는 원시 데이터가 매우 풍부하다는 것을 알 수 있습니다. 오늘 QCon 세션의 주제는 비즈니스 관찰 가능성 입니다 . 이 주제에서는 먼저 처음 네 가지 데이터 유형에 중점을 둡니다.
그러나 위 그림에 보이는 데이터는 Raw Data일 뿐입니다. 우리가 일상적으로 사용할 수 있는 비즈니스 가시성 데이터를 얻기 위해서는 식별, 추출, 변환, 연관, 집계 및 기타 작업이 필요합니다. 아래 그림은 DeepFlow에서 처리하는 eBPF 원시 데이터의 일부를 요약한 것으로, 소켓 이벤트를 기반으로 API의 요청/오류/지연 골든 지표를 추출하여 서비스 맵을 구축할 수 있음을 알 수 있습니다. , 모든 호출을 상호 연결함으로써 분산 추적 호출 체인을 형성할 수 있으며, 이러한 호출 체인을 집계하여 보다 세분화된 API 맵을 구성할 수 있습니다. 그중 eBPF를 기반으로 하는 무침입 분산 추적은 DeepFlow의 원래 기능입니다. 분산 추적은 계측이나 TraceID 삽입 없이 달성할 수 있습니다. 관심 있는 파트너는 GitHub Repo 에서 다운로드하여 사용해 볼 수 있습니다 . 또한 Process Events에서 프로세스 시작 및 중지 로그를 추출하고, File Events에서 파일 액세스 로그를 추출하고, Perf Events에서 CPU, 메모리, GPU, 비디오 메모리, 잠금 이벤트를 추출하여 성능 분석 플레임 그래프를 추출할 수 있습니다. 그어진.
관측 신호를 얻는 것 외에도 우리가 해야 할 중요한 작업은 데이터에 통합 레이블을 삽입하는 것입니다. 예를 들어, K8s, 클라우드 및 CMDB에서 얻은 리소스 및 비즈니스 태그를 주입하면 프로세스, 스레드, 코루틴과 같은 시스템 수준 태그는 물론 서브넷과 같은 네트워크 수준 태그를 주입하여 전체 스택 데이터를 수평적으로 연결하는 데 도움이 됩니다. IP 및 TCP SEQ는 분산 호출 체인을 수직으로 연결하는 데 도움이 됩니다.
분산 추적을 예로 들어 eBPF를 사용한 DeepFlow의 효과를 살펴보겠습니다. 다음 그림은 APM과 eBPF 추적 결과의 차이를 비교한 것입니다. APM을 사용하면 일반적으로 Java 프로세스를 커버할 수 있지만 일반적으로 API 게이트웨이, 마이크로서비스 게이트웨이, 서비스 그리드, DNS, Redis, MySQL 등을 전체적으로 커버하기는 어렵습니다. 다른 애플리케이션을 커버하기 어렵고 Java 언어의 애플리케이션 커버리지 비용도 상대적으로 높습니다. 무침입 및 풀 스택 데이터를 기반으로 하는 eBPF를 사용하면 전체 호출 스택이 모든 비즈니스 프로세스와 인프라 프로세스는 물론 K8s 네트워크 전송, 파일 읽기 및 쓰기 및 기타 이벤트를 포괄할 수 있습니다. 이 기능은 매우 혁신적인 기술입니다. 우리는 작년에 미국 컴퓨터 학회(American Computer Society)의 최고 학술 회의인 ACM SIGCOMM에서 승인된 약 20페이지 분량의 학술 논문으로 이 작업을 발표했습니다.
오늘 세션의 주제인 비즈니스 관찰 가능성 으로 돌아가서 , eBPF가 커널에서 얻은 데이터는 비즈니스와 어떻게 연관됩니까? eBPF는 핵심 기술이며 전체 생태학적 논의는 시스템, 성능, 보안 등에 초점을 맞추고 있으며 애플리케이션은 비즈니스 의미에 중점을 두고 있으며 개발자는 비즈니스 및 효율성 정보를 얻기를 원합니다. eBPF의 가시성이 시스템에서 비즈니스까지 차원의 벽을 뚫는 방법에 대해 DeepFlow의 접근 방식에 대해 이야기하겠습니다. 소켓 데이터를 예로 들면, eBPF에서 얻은 데이터에 대해 프로토콜 구문 분석을 수행할 때 일반적으로 표준 프로토콜(예: HTTP, MySQL 등)의 헤더 필드만 구문 분석합니다. DeepFlow는 이제 HTTP1/2/S, RPC, MQ, DB 및 네트워크 범주를 포괄하는 20개 이상의 프로토콜 구문 분석을 지원합니다. DeepFlow에 내장된 구문 분석 기능은 이러한 프로토콜의 헤더에서 표준 필드는 물론 URL, SQL 문, 오류 코드 등과 같은 페이로드까지 추출할 수 있습니다. 다만, HTTP Payload에 위치한 업무 오류 코드, 거래 일련번호, 주문 ID, 차량 프레임 번호 등의 정보는 통일된 로직에 따라 추출할 수 없습니다. 때로는 비즈니스에서 직렬화를 위해 Protobuf, Thrift 및 기타 방법을 사용하며 페이로드를 구문 분석하기 위해 해당 스키마와 결합해야 합니다.
여기서는 이 문제를 해결하기 위해 또 다른 기술인 WebAssembly를 사용합니다 . 실제로 eBPF가 커널 프로그래밍 가능 기술이라고 생각한다면 WebAssembly는 사용자 모드 프로그래밍 가능 기술입니다. DeepFlow는 이를 사용하여 안전한 고성능 핫 로딩 플러그인 메커니즘 세트를 구현합니다. 사용자는 Golang, Rust, C/C++ 및 기타 언어를 사용하여 비즈니스 페이로드의 주문형 구문 분석을 달성하는 플러그인을 작성할 수 있습니다. 이를 통해 요청 로그 및 파일 액세스 로그를 분석하여 eBPF 관찰 데이터가 향상될 때까지 기다립니다. 예를 들어 DeepFlow에서 제공하는 플러그인 SDK를 기반으로 Golang 프로그램을 작성하여 HTTP Protobuf 페이로드를 구문 분석하고 비즈니스 관련 필드를 추출할 수 있습니다. 페이로드의 오류 코드, 오류 메시지 및 기타 정보를 사용하여 원래 HTTP 요청 로그의 해당 필드를 다시 작성할 수도 있습니다.
마지막으로 이 섹션의 제목은 "eBPF를 사용하여 고품질 관측 가능한 신호 소스 구축"입니다. 따라서 우리의 견해는 eBPF가 인프라이자 전체 관찰 가능성 구축의 첫 번째 단계라는 것입니다. 무침입 관찰 가능성이라는 탄탄한 기반을 바탕으로 우리는 필요에 따라 기존 침입 데이터를 통합하고 통합 레이블을 삽입하여 더욱 강력한 관찰 가능성 플랫폼을 구축할 수 있습니다. eBPF의 기능은 지도를 완전히 열기 위해 스타워즈 초반에 섹션을 입력하는Whos your daddy 것과 같습니다 . 전통적인 침입 데이터는 과학 공을 사용하여 필요에 따라 지역의 고정 지점 탐색을 수행하는 비즈니스 측면과 같습니다.
02
LLM을 사용하여 효율적인 관찰 에이전트 구축
오늘 공유된 두 번째 요점은 LLM의 기능을 사용하여 고품질 데이터를 기반으로 관찰 가능한 인텔리전스를 구축하는 방법입니다. 과거 AIOps의 가장 큰 문제점은 열악한 데이터 품질(낮은 적용 범위, 지저분한 형식)이었습니다. AIOps를 시작하려고 계획하면 데이터 거버넌스를 촉진하는 데 일반적으로 반년 이상이 걸립니다. 이제 eBPF의 고품질 데이터는 기반이 탄탄하다는 것을 의미하는 동시에 AGI 시대에 맞춰 LLM은 이전 소형 모델보다 훨씬 강력한 기능을 보여주었습니다. 따라서 우리는 eBPF + LLM이 관찰성 에이전트를 구현하기 위한 인프라라고 믿습니다 . 이 분야의 몇 가지 DeepFlow 사례를 공유하겠습니다.
이 단계에서 DeepFlow는 모든 문제에 대한 에이전트를 구축하지 않습니다. 개발, 테스트, 운영 및 유지 관리의 전체 과정에서 문제를 탐색하고 관찰 가능성 + 에이전트를 결합하여 해결하기 가장 어려운 두세 가지를 선택합니다. 문제점을 이해하려면 먼저 이 두세 가지 사항에 집중하세요. 우리가 발견한 첫 번째 시나리오는 작업 주문 , 특히 작업 주문 그룹을 생성하는 초기 단계의 혼란스러운 프로세스입니다. 두 번째 시나리오는 변경 , 특히 변경 후 성능 저하의 급격한 구분입니다. 우리 는 아직 탐색 중입니다. 오늘 우리는 예비적인 생각 중 일부를 공유하겠습니다.
작업 주문의 비효율성 : 먼저 회사의 알람으로 인해 Feishu 그룹과 같은 그룹 채팅이 생성된다고 가정해 보겠습니다. 고객 사무실에서 볼 수 있는 일반적인 시나리오를 살펴보겠습니다. 첫 번째 사람이 작업 주문 그룹에 들어간 후 콜 체인 추적 데이터를 보고 몇 가지 분석을 수행한 후 자신의 문제가 아니라는 것을 확인한 다음 해당 사람을 뽑습니다. 두 번째 사람이 작업 지시 그룹에 합류했습니다. 이 사람은 몇 가지 지표 데이터를 살펴보고 몇 가지 분석을 한 후 그것이 자신의 문제가 아니라는 것을 발견하고 세 번째 사람을 그룹에 데려왔습니다. 이벤트 데이터를 분석한 후에도 그는 그것이 자신의 문제가 아니라는 것을 발견했습니다. 그리고 아마도 부서에서 가장 강력한 사람인 Lao 가 아니었을 수도 있습니다. 왕씨를 그룹에 끌어들이고 좀 더 심층적이고 상세한 분석과 요약이 이루어져 관이 완성될 수 있었고 작업은 올바른 담당자인 샤오리 에게 명령이 전달되었습니다 . 우리는 작업 주문이 Xiao Li와 연결되기 전에 프로세스가 매우 혼란스럽고 비효율적이며 1시간 이상 걸릴 수 있다는 것을 종종 발견합니다. 처음에 투입된 사람들이 전체 프로세스에 참여하지 않더라도 이 작업 지시 그룹의 존재는 때때로 그들의 정상적인 작업을 방해하게 되며 이는 작업 지시에 있는 모든 사람의 효율성에 큰 영향을 미칩니다. 그룹.
관측 가능성 에이전트는 이 문제를 어떻게 해결할 수 있나요? 작업지시가 생성되면 AI 에이전트 구동 로봇이 자동으로 작업지시 그룹에 들어갑니다. AI 에이전트는 먼저 DeepFlow API를 호출하여 추적, 지표, 이벤트, 로그 및 기타 데이터 유형을 보고 일련의 통계 알고리즘을 사용하여 데이터의 특징을 요약(따라서 토큰 수를 효과적으로 줄임)한 다음 이러한 기능 정보를 LLM 호출 프롬프트로 사용합니다(현재 분석에는 GPT4가 주로 사용됩니다. 한 가지 유형의 데이터를 분석한 후 AI 에이전트는 LLM의 함수 호출 또는 JSON 모드 기능을 사용하여 분석해야 할 다른 유형의 데이터를 결정합니다. 마지막으로 AI Agent는 LLM에게 모든 분석 결과를 바탕으로 요약을 요청합니다.
이 프로세스에서 DeepFlow의 eBPF는 완전한 전체 스택 관찰 데이터를 제공하고 AutoTagged는 의미론적으로 풍부한 통합 레이블을 모든 데이터에 삽입합니다 . AI Agent는 분석 결과를 바탕으로 label.owner 등의 라벨을 활용하여 해당 담당자를 작업지시 그룹으로 정확하게 끌어올 수 있습니다. 현 단계에서는 AI Agent의 작업지시 구분 정확도가 100%에 도달할 수는 없지만, 매우 혼란스러운 작업지시 그룹의 초기 기간을 대부분의 경우 1시간 이상에서 1분으로 성공적으로 압축할 수 있었으며, 작업지시 그룹의 효율성이 대폭 향상되었습니다. 작업지시 그룹의 인원이 줄어들어 팀 전체의 업무 효율성이 대폭 향상되었습니다 .
변경의 비효율성 : 클라우드 네이티브 환경에서는 서비스 출시 후 성능 저하의 원인이 다양할 수 있으며, 콜 체인 및 소프트웨어 코드 스택의 복잡성으로 인해 때때로 On Call을 담당하는 파트너가 어려운 경우가 있음을 확인했습니다. 자신이 아는 범위를 넘어서는 내용에 대한 무지로 인해 쉽게 오판할 가능성도 매우 높다는 것이 근본 원인이다. 이런 문제가 발생하면 일시적으로 용량을 늘리거나 롤백하여 업무를 복구한 후, 문제가 해결될 때까지 기다렸다가 다시 버전을 출시하는 수밖에 없습니다. 그러나 테스트 환경에서는 프로덕션 환경의 문제를 재현하지 못할 수 있으므로 문제의 근본 원인을 분석하는 데 도움이 되는 일련의 트래픽 재생 메커니즘을 도입해야 합니다. 이 시나리오에서는 AI 에이전트가 개발자가 성능 저하의 근본 원인을 신속하게 식별하고 훨씬 더 일찍 버전을 다시 온라인으로 전환하는 데 도움이 되기를 바랍니다.
복잡한 호출 체인이 있는 시나리오의 경우 작업 주문 에이전트의 예에 이미 좋은 솔루션이 있습니다. 복잡한 함수 호출 스택이 있는 시나리오의 경우 이는 프로세스가 침입 없이 실행될 때 비즈니스 함수, 라이브러리 함수, 런타임 함수 및 커널 함수 호출 스택을 얻을 수 있는 eBPF의 특징입니다. eBPF의 보안성과 낮은 오버헤드로 인해 프로파일링은 지속적으로 활성화될 수 있으므로 일반적으로 프로파일링 데이터는 변경 후 성능이 견딜 수 없을 정도로 저하되기 전까지 일정 기간 동안 축적됩니다. 데이터를 사용하여 근본 원인 구분을 신속하게 완료합니다.
eBPF 프로파일링 데이터는 매우 광범위한 기술 스택을 다루며 비즈니스 개발자가 모든 정보를 이해하기는 어렵습니다. 이 시나리오는 AI Agent가 잘하는 일입니다. 아래 그림과 같이 LLM은 일반적으로 커널 기능, 런타임 기능, 기본 라이브러리 기능에 대한 지식을 이해할 수 있으므로 이러한 기능에 대한 분석 결과를 직접 제공할 수 있습니다. LLM이 잘 못하는 부분이 있더라도 그러한 기능이 있는 소프트웨어 프로젝트는 자주 업데이트되지 않고 상식에 속하기 때문에 LLM이 마스터하지 못하는 부분을 미세 조정을 통해 향상시키는 것을 고려할 수 있습니다. Python의 요청 등과 같이 일반적으로 사용되는 일부 애플리케이션 라이브러리 함수를 살펴보겠습니다. 이러한 라이브러리는 많은 수, 빠른 반복 및 풍부한 인터페이스 문서화를 특징으로 하며 이러한 함수의 문서화를 벡터화하고 RAG 메커니즘을 사용하는 것을 고려할 수 있습니다. LLM 분석을 강화합니다. 더 나아가 기업의 내부 비즈니스 코드는 상식이 아니며 양이 더 많고 더 빨리 변경되므로 프롬프트 단어를 최적화하여 LLM에 직접 주입할 수 있습니다. DeepFlow의 AutoTagged 기능을 사용하면 AI 에이전트가 commit_id를 통해 최근 코드 수정 기록을 쉽게 찾아 LLM에 알릴 수 있습니다. LLM, Fine-tuning, RAG 및 Prompt Engineering 기술을 결합하여 eBPF 풀스택 프로파일링 데이터와 관련된 모든 전문 분야를 완벽하게 다룰 수 있어 개발자가 근본 원인을 빠르게 식별할 수 있음을 알 수 있습니다 .
취약점의 비효율성 : 한 보고서에 따르면 "취약점 수정은 76%가 쓸모가 없으며, 취약점 중 3%에만 우선적으로 주의를 기울여야 합니다." DeepFlow는 이 링크에서 AI 에이전트를 사용하여 효율성을 향상시키는 방법을 계속 모색하고 있습니다. 확실한 것은 eBPF가 Cloud Workload Security를 위한 탁월한 데이터 수집 기술이라는 것입니다. Isovalent는 보안의 4가지 주요 관찰 신호인 프로세스 실행, 네트워크 소켓, 파일 액세스 및 레이어 7 네트워크 ID를 요약합니다 . DeepFlow는 현재 이 네 가지 신호를 부분적으로 다루고 있으며 앞으로도 지속적으로 이를 강화할 것입니다. 이러한 데이터가 완성되면 LLM과 결합하여 매우 눈길을 끄는 보안 현장 AI 에이전트를 만들 수 있을 것이라고 믿습니다.
이번 편 마지막에는 AI Agent를 지속적으로 개선하는 방법에 대해 이야기해보겠습니다. 작업 주문 시나리오를 예로 들면, 테스트 환경에서 카오스 엔지니어링을 사용하여 대량의 비정상적인 데이터를 구축합니다. 이러한 이상 현상의 정확한 근본 원인을 알고 있기 때문에 AI Agenl을 평가하는 데 사용할 수 있습니다. 지속적으로 개선해 나가세요. 프로덕션 환경(참고: PPT의 오른쪽은 프로덕션 환경이어야 함)에서 사용자가 점수를 매길 수 있는 메커니즘을 추가했으며 에이전트 개발자는 점수에 따라 개선을 수행합니다.
03
DeepFlow 사용자를 위한 관찰 에이전트 실습 예시
그렇다면 DeepFlow의 AI 에이전트는 현재 어떤 모습일까요? 이 부분에 대해 간단히 소개하겠습니다. 현재 DeepFlow Enterprise Edition 페이지에서는 토폴로지 맵, 호출 체인 추적 및 연속 분석 페이지에서 AI 에이전트를 소환할 수 있으며 동시에 Feishu ChatBot에서 에이전트의 API를 호출하여 기능을 구현할 수도 있습니다. 작업지시 전문가입니다. AI 에이전트가 첫 번째 요약을 제공한 후 계속 질문할 수 있는 약 3~4개의 질문도 제공합니다. 이러한 질문을 직접 클릭하여 대화를 계속할 수 있습니다. 물론 사용자가 대화에 필요한 질문을 직접 입력할 수도 있습니다.
또한 오늘 DeepFlow Community Edition에도 AI 에이전트 기능이 출시되어 현재 Grafana Panel 데이터를 분석할 수 있습니다. 현재 우리는 Topo와 Tracing이라는 두 개의 패널을 지원하며 GPT, Tongyi Qianwen, Wenxinyiyan 및 ChatGLM의 네 가지 대형 모델에 적용됩니다.
04
미래의 진화 방향에 대한 생각
마지막으로 DeepFlow AI Agent의 향후 진화 방향에 대해 말씀드리겠습니다.
이제 eBPF는 클라우드 애플리케이션을 완벽하게 포괄할 수 있습니다. 다음으로는 스마트카의 자율주행, 스마트 공간 도메인 제어, 권한이 허용되는 일부 스마트폰 시나리오 등 최종 단계까지 기능을 확장할 것입니다.
한편, 우리는 RAG에 최적화할 여지가 많다는 사실도 발견했습니다. 다음은 RAG: 대규모 언어 모델을 위한 검색 증강 생성: 설문조사에 대한 리뷰입니다 .
05
DeepFlow란 무엇입니까?
DeepFlow는 복잡한 클라우드 인프라 및 클라우드 네이티브 애플리케이션에 대한 심층적인 관찰 가능성을 제공하는 것을 목표로 Yunshan Network에서 개발한 관찰 가능성 제품입니다. DeepFlow는 eBPF를 기반으로 애플리케이션 성능 지표, 분산 추적, 지속적인 성능 분석 등 관찰 신호의 무침입 ( ) 수집을 구현하고 스마트 라벨 ( ) 기술 과 결합하여 전체 스택 ( ) 상관 관계 및 모든 항목의 효율적인 액세스를 구현합니다. 관측 신호. DeepFlow를 사용하면 클라우드 네이티브 애플리케이션에 자동으로 깊은 관찰 기능이 제공되어 개발자의 지속적인 계측에 대한 무거운 부담을 없애고 DevOps/SRE 팀에 코드에서 인프라까지 모니터링 및 진단 기능을 제공할 수 있습니다.Zero CodeSmartEncodingFull Stack
GitHub 주소: https://github.com/deepflowio/deepflow
DeepFlow 데모를 방문하여 제로 계측, 전체 적용 범위 및 완전히 관련된 관찰 가능성을 경험해 보세요.
이벤트 미리보기 | 관찰 가능성 오픈 소스 개발자 모임 "지능형 관찰 가능성: 대형 모델이 주도하는 관찰 가능한 진화"