'소프트웨어 개발'이 AI 대형 모델을 만났을 때

오픈소스 중국 커뮤니티 팀이 공유라는 이름으로 오픈소스 중국 커뮤니티의 뒷이야기를 전하는 첫 생방송을 진행했습니다."

저자: Chen Xin (Shenxiu)

안녕하세요 여러분, 저는 Tongyi Lingma의 제품 기술 이사 Chen Xin입니다. 지난 8년 동안 저는 Alibaba Group에서 R&D 성과, 즉 R&D 도구 관련 업무를 맡아왔습니다.

2015년부터 원스톱 DevOps 플랫폼 구축을 시작했고, 이후 DevOps 플랫폼을 클라우드화하는 Cloud Effect를 만들었습니다. 2023년까지 우리는 대형 모델 시대가 도래한 후 소프트웨어 도구가 철저한 혁신에 직면하게 될 것이라고 분명히 느낍니다. 대형 모델과 소프트웨어 도구 체인의 결합은 소프트웨어 연구 개발을 다음 시대로 가져올 것입니다.

그렇다면 첫 번째 정류장은 어디입니까? 사실 보조 프로그래밍이기 때문에 대규모 코드 모델을 기반으로 한 AI 보조 도구인 Tongyi Lingma 제품을 만들기 시작했습니다. 오늘 저는 이 기회를 빌어 Tongyi Lingma 기술의 구현에 대한 세부 사항과 소프트웨어 연구 및 개발 분야에서 대형 모델 개발을 어떻게 보는지에 대해 여러분과 공유하고자 합니다.

세 부분으로 나눠보겠습니다. 첫 번째 부분에서는 먼저 AIGC가 소프트웨어 연구 및 개발에 미치는 근본적인 영향을 소개하고 거시적 관점에서 현재 동향을 소개합니다. 두 번째 부분에서는 Copilot 모델을 소개하고 세 번째 부분에서는 향후 소프트웨어 개발 Agent 제품의 진행 상황을 설명합니다. 제가 코파일럿 에이전트를 언급한 이유는 나중에 설명하겠습니다.

AIGC가 소프트웨어 개발에 미치는 근본적인 영향

이 그림은 제가 최근 몇 년 동안 그린 그림인데, 기업의 R&D 효율성에 영향을 미치는 핵심 요소는 이 세 가지라고 생각합니다.

첫 번째 포인트는 사람의 기술입니다. 예를 들어, Google은 개인 능력이 다른 사람보다 10배 더 강한 엔지니어를 채용할 수 있으며, 그러면 10배 더 많은 인원으로 구성된 소규모 그룹을 구성할 수 있습니다. 유능한 엔지니어는 매우 강력하며 심지어 풀 스택을 실현할 수도 있습니다. 역할 분담이 매우 간단하고 작업이 매우 효율적이며 최종 효율성도 매우 뛰어납니다.

그러나 실제로 우리 기업, 특히 중국 기업 중 Google 수준에 도달할 수 있는 기업은 거의 없습니다. 이는 객관적인 영향을 미치는 요소입니다. 우리는 인력 능력이 효율성의 초석이자 효율성의 한계점이기도 하다고 믿습니다.

두 번째 포인트는 협력적 소비이다. 모든 엔지니어에게 뛰어난 능력을 요구할 수는 없기 때문에 모든 사람이 전문적인 업무 분담을 가져야 합니다. 예를 들어 일부는 소프트웨어 설계를 담당하고 일부는 개발, 테스트 및 프로젝트 관리를 담당합니다. 이러한 사람들로 구성된 팀의 소프트웨어 아키텍처가 복잡해지면 그에 비례하여 조직의 복잡성도 증가하게 되며, 이로 인해 협업 소비가 증가하고 결국 전체 R&D 효율성이 저하됩니다.

세 번째 포인트는 비용 관리입니다. 우리는 프로젝트를 진행하면서 항상 부자가 될 수는 없고, 항상 인력이 부족하며, 10배의 엔지니어를 채용하기 위한 무제한의 자금이 불가능하다는 점을 발견했습니다.

오늘날 AIGC 시대에 이 세 가지 요소는 몇 가지 근본적인 변화를 가져왔습니다.

인력 기술 측면에서 AI 지원은 일부 후배 엔지니어의 역량을 빠르게 향상시킬 수 있습니다. 실제로 해외에서도 이에 대한 보고가 있는데, 주니어 엔지니어가 코드 지원 도구를 사용하는 효과가 수석 엔지니어보다 훨씬 높습니다. 이러한 도구는 초급 작업이나 보조 효과를 대체할 수 있는 매우 좋은 도구이기 때문에 후배 엔지니어의 단점을 빠르게 보완할 수 있습니다.

협업 소비 측면에서 오늘날 AI가 슈퍼 개인이 될 수 있다면 프로세스 협업 소비를 줄이는 것이 실제로 도움이 될 것입니다. 예를 들어, 일부 간단한 작업은 사람을 상대할 필요가 없고, AI가 직접 수행할 수 있으며, 요구사항 테스트 방법을 모든 사람에게 설명할 필요도 없고 간단한 테스트만 수행하면 되기 때문에 시간 효율성이 향상됩니다. . 따라서 슈퍼개인을 통해 협력적 소비를 효과적으로 줄일 수 있다.

실제로 비용 관리 측면에서 보면 코드 지원을 위한 대규모 코드 모델의 현재 사용을 포함하여 많은 수의 AI 사용이 트랜잭션 작업을 대체하고 있으며 이는 일일 트랜잭션 노동의 70%를 대체할 것으로 예상됩니다.

구체적으로 살펴보면 지능에 대한 네 가지 과제와 기회가 있을 것입니다.

첫 번째는, 앞서 소개해드린 것처럼 다수의 R&D 엔지니어들의 반복적인 업무와 간단한 의사소통을 AI를 통해 완성할 수 있는 모델입니다.

협업 효율성의 또 다른 측면은 몇 가지 간단한 작업을 AI가 직접 수행할 수 있어 협업 소비를 줄일 수 있다는 것입니다.

세 번째는 R&D 경험입니다. 과거 DevOps 툴체인은 무엇에 중점을 두었나요? 하나씩 대규모 조립 라인과 전체 도구 체인을 형성합니다. 실제로 각 도구 체인은 회사마다 사용 습관이 다를 수 있으며 계정 시스템, 인터페이스, 상호 작용 및 권한도 다를 수 있습니다. 이러한 복잡성은 개발자에게 매우 큰 컨텍스트 전환 비용과 이해 비용을 가져오며, 이는 눈에 보이지 않게 개발자를 매우 불행하게 만듭니다.

하지만 AI 시대에는 일부 변화가 일어났습니다. 자연어를 사용하여 통일된 대화 입구를 통해 많은 도구를 작동할 수 있고 심지어 자연어 창에서 많은 문제를 해결할 수도 있습니다.

예를 들어, SQL 문에 성능 문제가 있는지 확인했다면 어떻게 해야 할까요? 먼저 코드에 있는 SQL문을 파헤쳐 실행문으로 변환한 뒤 DMS 시스템에 넣어 인덱스를 사용하는지, 문제가 있는지 진단하고 수동으로 여부를 판단하면 된다. 필요 여부에 관계없이 이 SQL을 수정하여 최적화하고 최종적으로 IDE에서 변경합니다. 이 프로세스에는 여러 시스템을 전환해야 하며 많은 작업이 수행되어야 합니다.

앞으로 코드 인텔리전스 도구가 있으면 코드에 동그라미를 치고 이 SQL에 문제가 있는지 대형 모델에 문의할 수 있습니다. 이 대형 모델은 DMS 시스템과 같은 일부 도구를 독립적으로 호출하여 분석할 수 있습니다. 얻은 결과는 대규모 모델을 통해 SQL을 어떻게 최적화해야 하는지 직접 알려주고 결과만 알려주면 전체 작업 링크가 단축되고 R&D가 향상됩니다. 효율성이 향상될 것입니다.

네 번째는 디지털 자산이다. 예전에는 누구나 코드를 작성해 거기에 넣어두었다가 코드나 부채의 산으로 변했다. 물론 발굴되지 않은 뛰어난 금광도 많고, 아직도 문서도 많다. 내가 찾고 싶은 시간을 찾을 수 없습니다.

하지만 AI 시대에 우리가 하는 가장 중요한 일 중 하나는 자산과 문서를 정리하고 SFT와 RAG를 통해 대형 모델에 권한을 부여하여 대형 모델이 더욱 스마트해지고 사용자의 성격에 더 부합하도록 하는 것입니다. 따라서 오늘날 인간-컴퓨터 상호작용 방식의 변화는 경험의 변화를 가져올 것입니다.

인공지능은 현재 영향 요인을 세분화해 인간과 컴퓨터의 상호작용 방식에 세 가지 변화를 가져오는 것이 핵심이다. 첫 번째는 AI가 도구와 결합된 부조종사(Copilot)가 되어 사람들이 AI에 명령을 내려 우리가 일부 단일 지점 도구를 완성할 수 있다는 것입니다. 두 번째 단계에서는 실제로 모든 사람이 합의를 해야 합니다. 즉, 독립적으로 코드 작성이나 테스트 수행을 포함하여 작업을 독립적으로 완료할 수 있는 능력을 갖게 됩니다. 실제로 이 도구는 다중 영역 전문가 역할을 하며 컨텍스트를 제공하고 지식 정렬을 완료하기만 하면 됩니다. 세 번째 단계에서는 AI가 의사결정자가 될 수 있다고 판단합니다. 두 번째 단계에서도 의사결정자는 여전히 인간이기 때문입니다. 세 번째 단계에서는 대형 모델이 어느 정도 의사결정 능력을 가질 가능성이 있습니다. 더욱 발전된 정보 통합 및 분석 기능을 포함합니다. 이때 사람들은 비즈니스 창의성과 수정에 더 집중하게 될 것이며 많은 것을 대형 모델에 맡길 수 있습니다. 다양한 인간-기계 모드의 이러한 변화를 통해 우리의 전반적인 작업 효율성이 높아질 것입니다.

또 다른 점은 방금 이야기한 지식 전달의 형태도 근본적인 변화를 겪었다는 것입니다. 과거에는 지식 전수 문제를 입소문과 교육, 옛 것이 가져오는 방식으로 해결했습니다. 미래에는 이것이 필요하지 않을 가능성이 매우 높습니다. 모델에 비즈니스 지식과 도메인 경험만 갖추면 되며, 모든 개발 엔지니어가 지능형 도구를 사용하도록 하면 이러한 지식을 연구 개발 프로세스에 적용할 수 있습니다. 위의 그림은 이제 DevOps를 위한 원스톱 도구 체인입니다. 다수의 코드 및 문서 자산을 축적한 후 이러한 자산을 분류하여 대규모 모델과 함께 구성합니다. RAG 및 SFT를 통해 모델은 DevOps 도구의 각 링크에 내장되어 더 많은 데이터를 생성하여 이러한 전달을 형성합니다. 이 과정에서 일선 개발자는 자산이 가져오는 배당금이나 기능을 누릴 수 있습니다.

이상은 대형 모델의 R&D 효율성에 영향을 미치는 핵심 요소와 형태의 가장 중요한 두 가지 변화를 거시적 관점에서 소개한 것입니다. 첫 번째는 인간-컴퓨터 상호 작용 형태의 변화이고 두 번째는 지식이 전달되는 방식의 변화. 대형 모델 개발 단계의 다양한 기술적 한계와 문제로 인해 우리가 가장 잘하는 것은 Copilot 인간-컴퓨터 상호 작용 모드이므로 다음에는 우리의 경험 중 일부와 최고의 Copilot 인간-컴퓨터 상호 작용 모드를 만드는 방법을 소개하겠습니다. .

최고의 부조종사 포즈 만들기

우리는 코드 개발의 인간-컴퓨터 상호 작용 모델이 현재 소규모 작업, 수동 채택이 필요한 문제, 코드 완성과 같은 빈도가 높은 문제 등의 문제만 해결할 수 있다고 믿고 있으며 이를 받아들입니다. 그런 다음 다른 단락을 생성해 보겠습니다. 이는 매우 자주 발생하는 문제이며, 프로젝트를 한 번에 생성하지도 않고, 클래스도 생성하지 않습니다. 매번 함수 또는 몇 줄. 우리는 왜 이런 일을 하는가? 사실 이는 모델 자체의 능력의 한계와 관련이 많습니다.

현재 컨텍스트 폭은 여전히 매우 제한되어 있으므로 요구 사항을 완료하려는 경우 모든 배경 지식을 한 번에 전달할 방법이 없으므로 에이전트를 사용하여 여러 개의 작은 작업으로 나눌 수 있습니다. 그리고 단계별로 해결해보세요. 또는 주석에 따라 작은 코드 조각을 생성하는 등 가장 간단한 작업을 Copilot 모드에서 완료하도록 하세요. 이를 작은 작업 해결이라고 합니다.

수동 채택 측면에서 이제 인간은 대규모 코드 모델에서 생성된 결과에 대해 판단을 내려야 합니다. 현재 우리가 잘하고 있는 것은 채택률이 30~40%일 수 있습니다. 이는 생성된 코드의 절반 이상이 실제로 부정확하거나 개발자의 기대에 미치지 못함을 의미하므로 착시 문제를 지속적으로 제거해야 합니다.

그러나 대형 모델이 실제로 생산 수준에서 사용 가능하려면 가장 중요한 것은 수동 확인입니다. 그러면 빈도가 높은 모델을 너무 많이 생성하지 말고 매번 조금씩 생성하십시오. OK는 성능에도 영향을 미칩니다. 이 기사에서는 우리가 생각하는 것과 우리가 하는 일에 대해 이야기하고 높은 빈도를 통해 정확도가 제한된 문제를 해결합니다. 또한 출력 부족은 주로 성능 및 비용 문제로 인해 발생합니다.

현재 코드 어시스턴트 모델은 실제로 대형 모델의 일부 기술적 한계를 매우 정확하게 충족하므로 이러한 제품을 신속하게 출시할 수 있는 매우 좋은 기회가 있습니다. 우리 의견으로는 개발자들이 가장 좋아하는 Copilot 모델은 빈도가 높고 엄격한 요구 사항, 도달 범위 내, 내가 원하는 것을 아는 것, 나만의 독점이라는 네 가지 키워드입니다.

첫 번째는 빈도가 높고 긴급하게 필요한 시나리오를 해결하여 개발자가 이것이 단순한 장난감이 아니라 정말 유용하다는 것을 느낄 수 있도록 해야 한다는 것입니다.

두 번째는 손이 닿는 곳에 있습니다. 즉, 언제든지 깨어날 수 있으며 언제든지 문제를 해결하는 데 도움이 될 수 있습니다. 더 이상 예전처럼 각종 검색엔진을 통해 코드를 검색할 필요가 없고, 마치 내 옆에 있는 것처럼 언제든지 깨워 문제 해결에 도움을 줄 수 있습니다.

세 번째는 내가 무엇을 생각하는지 아는 것, 즉 내 질문에 대답하는 정확성과 내 질문에 대답하는 타이밍이 매우 중요합니다.

마지막으로, 완전히 오픈 소스인 것만 이해하는 것이 아니라 내 개인적인 지식 중 일부를 이해할 수 있어야 합니다. 이 네 가지 사항에 대해 자세히 논의해 보겠습니다.

고주파가 필요합니다

우리는 소프트웨어 개발에 있어 가장 빈번한 시나리오가 무엇인지 파악해야 합니다. 여기에 실제 데이터가 있습니다. 첫 번째 데이터는 JetBrains가 2023년에 작성한 개발자 생태 보고서에서 나온 것입니다. 이 보고서는 개발자의 가장 많은 시간이 소요되는 활동을 정리한 것으로, 70%~80%가 코드를 작성하고 코드를 이해하고 있음을 알 수 있습니다. 인터넷을 검색하고, 디버그하고, 댓글을 작성하고, 테스트를 작성합니다. 이러한 시나리오는 실제로 코드 인텔리전스 도구의 기능입니다. Tongyi Lingma와 같은 제품이 해결하는 핵심 문제는 실제로 가장 빈번한 문제입니다.

후자의 두 데이터는 Tongyi Lingma Online의 수십만 명의 사용자에 대한 데이터 분석입니다. 현재 우리가 온라인으로 채택하는 코드의 73%는 완료 작업에서 비롯되고, 27%는 질문 및 답변 작업 채택에서 비롯됩니다. 그래서 오늘날에는 코드를 작성하는 데 있어 수많은 AI가 사람을 대체하고 있으며, 여전히 IDE 라인 사이에서 생성되는 것은 실제 상황을 반영한 결과입니다. 다음으로 Q&A 기능을 사용하는 비율이 76%가 R&D Q&A에서 나오고 나머지 10%는 코드 최적화, 코드 해석 등 일련의 코드 작업입니다. 따라서 대다수의 개발자는 여전히 우리 도구를 사용하여 일반적인 R&D 지식을 요청하거나 자연어를 사용하여 대규모 코드 모델에서 일부 알고리즘을 생성하여 일부 작은 문제를 해결합니다.

다음 23%는 모든 사람에게 데이터 통찰력을 제공하기 위한 실제 세부 코딩 작업입니다. 그래서 우리는 핵심 목표를 가지고 있습니다. 첫째, 특히 줄 사이의 코드 생성 문제를 해결해야 합니다. 둘째, R&D 문제의 정확성과 전문성 문제를 해결해야 한다.

손이 닿는 곳에

우리가 궁극적으로 이야기하고 싶은 것은 몰입형 프로그래밍 경험을 만드는 것입니다. 오늘날 개발자들이 직면한 대부분의 문제가 뛰어내리지 않고 IDE 내에서 해결될 수 있기를 바랍니다.

과거에 우리의 경험은 어떠했습니까? 문제가 발생하면 인터넷을 검색하거나 다른 사람에게 물어보고, 마지막으로 코드를 작성하고 복사하여 디버깅 및 컴파일을 위해 IDE에 넣고 다시 확인해야 합니다. 실패합니다. 시간이 많이 걸립니다. 우리는 IDE에서 빅 모델에게 직접 물어보고 빅 모델이 코드를 생성하도록 하여 매우 즐거운 경험이 되기를 바랍니다. 이러한 기술적 선택을 통해 우리는 몰입형 프로그래밍 경험의 문제를 해결했습니다.

완료 작업은 성능에 민감한 작업이며 출력은 300~500밀리초, 바람직하게는 1초 이내여야 합니다. 따라서 주로 코드를 생성하는 데 사용되는 작은 매개변수 모델과 대부분의 훈련이 있습니다. 말뭉치는 코드에서도 나옵니다. 모델 매개변수는 작지만 코드 생성의 정확도는 매우 높습니다.

두 번째는 특수 작업을 수행하는 것입니다. 주석 생성, 단위 테스트, 코드 최적화, 운영 오류 문제 해결 등 7가지 작업을 포함하여 실제 작업의 20~30%가 여전히 남아 있습니다.

우리는 현재 중간 매개변수 모델을 사용합니다. 여기서 주요 고려사항은 첫째, 발전 효율, 둘째, 튜닝이다. 매우 큰 매개변수 모델의 경우 튜닝 비용이 매우 높지만 이 중간 매개변수 모델의 경우 코드 이해 및 코드 생성 효과가 이미 우수하므로 중간 매개변수 모델을 선택했습니다.

그리고 대형 모델의 경우, 특히 R&D 질문의 70% 이상에 대한 답변에서 높은 정확도와 실시간 지식을 추구합니다. 그래서 우리는 최대 매개변수 모델을 통해 RAG 기술을 중첩하여 거의 실시간으로 인터넷 기반 지식 기반을 연결할 수 있으므로 답변의 품질과 효과가 매우 높으며 모델 환상을 크게 제거하고 답변을 개선할 수 있습니다. 품질. 우리는 세 가지 모델을 통해 전체 몰입형 프로그래밍 경험을 지원합니다.

두 번째 요점은 더 많은 터미널을 포괄해야 더 많은 개발자를 포괄할 수 있기 때문에 여러 터미널을 구현해야 한다는 것입니다. 현재 Tongyi Lingma는 VS 코드와 JetBrains를 지원하며 주로 트리거링 문제, 디스플레이 문제 및 일부 상호작용 문제를 해결합니다.

핵심 수준에서 로컬 에이전트 서비스는 독립적인 프로세스입니다. 이 프로세스와 위 플러그인 간에 통신이 이루어집니다. 이 프로세스는 주로 코드 지능형 완성, 세션 관리 및 에이전트를 포함한 코드의 일부 핵심 기능을 다룹니다.

또한 파일 간 참조 문제를 해결하려면 구문 분석 서비스도 매우 중요합니다. 로컬 검색을 향상하려면 경량 로컬 벡터 검색 엔진도 필요합니다. 따라서 실제로 이러한 방식으로 전체 백엔드 서비스를 빠르게 확장할 수 있습니다.

또한 개별 언어로 한 줄 완성을 구현하는 B의 10분의 1 정도의 작은 로컬 오프라인 모델도 있습니다. 최근에는 JetBrains를 포함하여 로컬에서 실행되는 작은 모델도 출시했습니다. . 이러한 방식으로 로컬 세션 관리 및 로컬 저장소와 같은 일부 데이터 보안 및 개인 정보 보호 문제가 모두 로컬 컴퓨터에 배치됩니다.

내가 어떻게 생각하는지 알아

IDE 플러그인 도구에 관해서는 몇 가지 점이 있다고 생각합니다. 첫 번째는 트리거되는 시간이며, 개발자 경험에도 큰 영향을 미칩니다. 예를 들어 공백에 들어갈 때 트리거해야 합니까? IDE가 프롬프트를 생성했을 때 트리거되어야 합니까? 이 코드를 삭제할 때 트리거되어야 합니까? 우리가 정리해야 할 시나리오는 아마도 30~50개 이상일 것입니다. 이 시나리오에서 코드를 트리거할지 여부는 규칙을 통해 해결할 수 있습니다. 이를 신중하게 탐색하고 개발자 경험을 조사하는 한 이는 매우 심오한 기술이 아닙니다. .

하지만 코드 생성 기간 측면에서는 더 어렵다고 생각합니다. 다양한 편집 영역의 다양한 위치에서 생성되는 코드의 길이는 우리의 경험에 직접적인 영향을 미치기 때문입니다. 개발자가 한 줄의 코드만 생성하는 경향이 있다면 문제는 개발자가 생성된 전체 내용을 이해할 수 없다는 것입니다. 예를 들어, 함수를 생성할 때 함수가 무엇을 할 것인지, 또는 if를 생성할 때 알 수 없습니다. if 문 안에 무엇이 있는지 알 수 없습니다. 비즈니스 논리가 무엇인지, 그의 경험에 영향을 미치는 기능 단위를 완전히 판단할 수 있는 방법은 없습니다.

이를 위해 몇 가지 고정된 규칙을 사용하면 문제가 발생할 수도 있습니다. 즉, 상대적으로 경직될 것입니다. 그래서 우리의 접근 방식은 실제로 코드의 의미 정보를 기반으로 합니다. 학습과 수많은 샘플을 통해 모델은 현재 어떤 시나리오에서 생성되어야 하는지를 이해하고 클래스 수준, 기능을 자동으로 결정하는 모델을 구현했습니다. 수준, 논리 블록 수준 및 행 수준의 생성 강도를 적응형 생성 강도 의사 결정이라고 합니다. 사전 훈련을 많이 함으로써 모델이 인지할 수 있게 하여 생성의 정확도를 높이는 것도 핵심 기술 항목이라고 생각합니다.

앞으로 가장 중요한 것은 모델의 환상을 어떻게 제거하느냐 하는 것입니다. 왜냐하면 환상이 충분히 제거되어야 채택률이 향상될 수 있기 때문입니다. 따라서 라이브러리 내에서 파일 간 컨텍스트 인식을 구현해야 합니다. 여기서는 코드 기반 의미 분석, 참조 체인 추적, 유사 코드 및 동적 언어 유형 파생을 많이 수행합니다.

가장 중요한 것은 개발자가 이 직책을 채우기 위해 어떤 종류의 배경 지식이 필요할 수 있는지 추측하기 위해 모든 수단을 시도하는 것입니다. 이러한 것에는 일부 언어, 프레임워크, 사용자 습관 등이 포함될 수도 있습니다. 우리는 이를 결합하기 위해 다양한 것을 사용합니다. 맥락에 따라 우선순위를 정하고, 가장 중요한 정보를 맥락에 넣은 다음 이를 대형 모델에 제공하여 파생함으로써 대형 모델이 환상을 제거할 수 있도록 합니다. 이 기술을 통해 우리는 파일 간 상황 인식 테스트 세트를 달성할 수 있으며 정확도는 22%에서 66.9%로 향상되었습니다 .

마지막은 로컬 도서관 내 검색 향상입니다. 방금 말했듯이 상황 인식은 트리거 위치에서 개발자의 상황만 추측합니다. 보다 일반적인 시나리오는 오늘날 개발자가 질문을 하고 버그 수정, 요구 사항 추가, 도움 등 로컬 라이브러리의 모든 파일을 기반으로 문제를 해결하는 데 큰 모델을 사용하도록 하는 것입니다. 파일을 채우고 자동으로 추가, 삭제, 수정 및 검색을 구현하고 심지어 내 Pompt 파일에 새 패키지 버전을 추가하는 것까지 실제로 이와 같은 요구 사항이 많이 있습니다. 대형 모델의 경우. 컨텍스트 폭의 영향으로 인해 전체 프로젝트의 모든 파일을 대형 모델에 담는 것이 불가능하기 때문에 로컬 라이브러리 내 검색 향상 이라는 기술을 사용해야 합니다 .

이 기능은 라이브러리를 기반으로 무료 Q&A를 구현하고, 라이브러리에 로컬 검색 강화 서비스를 구축하기 위한 것입니다. 이 방법이 개발자의 경험에 가장 적합하고 보안이 가장 높다고 판단합니다.

전체 링크를 완료하기 위해 코드를 클라우드에 업로드할 필요는 없습니다. 전체 링크의 관점에서 보면 개발자가 질문을 한 후 코드베이스로 이동하여 작업을 분해하는 데 필요한 핵심 정보를 추출하게 됩니다. 분해가 완료된 후 로컬 벡터 검색 및 호출을 수행합니다. 기업은 기업 수준의 통일된 지식 기반 관리를 갖추고 있기 때문에 검색 결과를 병합 및 재정렬하고 기업 내부 데이터 지식 기반을 검색할 수 있습니다. 마지막으로 모든 정보가 요약되어 빅 모델로 전송되므로 빅 모델이 문제를 생성하고 해결할 수 있습니다.

나만

기업이 대규모 코드 모델로 매우 좋은 효과를 얻으려면 이 수준에서 벗어날 수 없다고 생각합니다. 예를 들어, 프로젝트 관리 단계에서 기업 데이터에 대한 개인화된 시나리오를 구현하는 방법, 요구 사항/작업/결함 내용의 일부 고유 형식 및 사양에 따라 대규모 모델을 생성하는 방법을 통해 자동 분해 및 자동 갱신을 실현하는 데 도움이 됩니다. 일부 요구사항 작성, 자동 요약 등

개발 단계는 모두가 가장 주목하는 단계일 수 있습니다. 회사에서는 회사 자체에 맞는 코드 사양이 있어야 하고, 회사 자체의 2차 라이브러리를 참조하고, 일부 프런트엔드를 사용하는 것을 포함하여 API를 호출해야 한다고 흔히 말합니다. 회사에서 자체 개발한 프레임워크, 구성 요소 라이브러리 등은 모두 개발 시나리오에 속합니다. 테스트 시나리오는 기업 사양을 준수하고 비즈니스를 이해하는 테스트 사례도 생성해야 합니다. 운영 및 유지 관리 시나리오에서는 항상 기업의 운영 및 유지 관리 지식을 찾은 다음 질문에 답하여 기업의 운영 및 유지 관리 API 중 일부를 얻어 코드를 빠르게 생성해야 합니다. 이는 우리가 수행해야 한다고 생각하는 엔터프라이즈 데이터 개인화를 위한 시나리오입니다. 구체적인 접근 방식은 검색 향상 또는 미세 조정 교육을 통해 이를 달성하는 것입니다.

여기에는 코드 처리 방법, 문서 처리 방법, 코드를 사용하기 전에 필터링, 정리 및 구조화해야 하는 등 몇 가지 간단한 시나리오와 주의해야 할 사항이 나열되어 있습니다.

교육 과정에서는 공개 도메인 데이터와 비공개 도메인 데이터의 혼합을 고려해야 합니다. 예를 들어, 검색 향상 측면에서 몇 가지 다른 매개변수 조정을 수행해야 하며, 실제로 코드 생성 시나리오에서 필요한 상황 정보를 얻는 방법과 검색 향상 방법을 포함하여 지속적으로 탐색하고 있습니다. 질문과 답변 시나리오에서 필요한 답변의 상황별 정보를 검색 강화하는 것입니다.

우리가 원하는 것은 엔터프라이즈급 검색 향상 솔루션 입니다 . 현재 엔터프라이즈급 검색 향상 솔루션의 아키텍처 다이어그램은 대략 다음과 같습니다. 중간에는 데이터 분석 일정 관리, 질문 이해, 답변 구성, 구조적 분석, 데이터 세분화 등을 포함한 지식 기반 관리 서비스가 있습니다. 핵심 기능은 중간에 있으며 아래쪽에는 더 일반적으로 사용되는 임베딩 서비스가 있습니다. . 대규모 모델, 벡터 저장 및 검색 서비스를 포함합니다.

우리가 관리하는 일부 백엔드는 문서 검색 향상 및 코드 생성 검색 향상을 지원합니다. 코드 생성은 이 시나리오의 검색 및 개선을 완료하는 것입니다. 실제로 필요한 처리 방법과 기술은 문서와 약간 다릅니다.

과거에 우리는 푸단대학교와 수년간 학술 연구를 진행해 왔으며 그들의 노력에 매우 감사하고 있습니다. 당시 테스트 세트의 결과도 1.1 모델을 기반으로 했습니다. 1B에 검색 향상 기능을 추가하면 실제로 정확도와 효과가 7B 이상 모델과 동일한 효과를 얻을 수 있습니다.

미래 소프트웨어 개발 에이전트 제품 진화

우리는 미래의 소프트웨어 개발이 확실히 에이전트 시대로 진입할 것이라고 믿습니다. 이는 어느 정도 자율성을 가지며 우리 도구를 매우 쉽게 사용할 수 있고 인간의 의도를 이해하고 작업을 완료하며 결국 그림과 같이 다목적 소프트웨어를 형성할 수 있음을 의미합니다. 그림. 에이전트의 협업 모델.

올해 3월, Devin의 탄생으로 인해 이 문제가 실제로 가속화되었음을 느끼게 되었습니다. 우리는 과거에는 이 문제가 실제 비즈니스 프로젝트를 완료할 수 있을 것이라고는 상상도 하지 못했고 심지어 이 문제도 느꼈습니다. 아직 1년은 남았지만, 오늘날 우리는 정말 수백, 수천 단계를 대형 모델을 통해 해체하고 차근차근 실행해 나갈 수 있다는 걸 느끼게 됩니다. 강력한 해체 능력과 추론 능력은 우리를 매우 놀라게 했습니다.

Devin의 탄생과 함께 다양한 전문가와 학자들이 투자하기 시작했고, 우리 Tongyi 연구소는 즉시 OpenDevin이라는 프로젝트를 시작했습니다. 이 프로젝트는 불과 몇 주 만에 별 20,000개를 돌파했습니다. 모두가 이 분야에 매우 열정적인 모습을 볼 수 있습니다. 그런 다음 즉시 SWE의 Agent 프로젝트를 오픈하여 SWE-벤치 솔루션 비율을 10% 이상으로 올렸습니다. 과거의 대형 모델은 모두 몇 퍼센트 범위에 있었고, 10%로 올리는 것은 이미 Devin의 성능에 가깝습니다. 우리는 이 분야의 학문적 연구가 매우 빠를 수 있다고 판단했습니다.

과감하게 추측해 보자. 2024년 중반쯤에는 6월부터 9월까지 SWE-벤치의 해결률이 30%를 넘을 가능성이 매우 높다. 50~60%의 해결률을 달성할 수 있다면 AI가 실제로 Github의 문제를 해결하고, 버그를 수정하고, 이러한 요구 사항을 해결하도록 하세요. 이 테스트 세트를 통해 AI의 자율 완료율을 50~60%에 도달할 수 있다면 실제로 프로덕션 수준에서 구현할 수 있다고 생각합니다. 최소한 몇 가지 간단한 결함은 이를 통해 해결할 수 있으며 이는 업계에서 우리가 본 최신 개발 중 일부입니다.

그러나 이 그림은 기술적인 관점에서 당장 실현될 수는 없습니다. 우리는 이 네 단계를 거쳐 점진적으로 구현할 것입니다.

첫 번째 단계에서 우리는 여전히 단일 데이터베이스 Q&A 에이전트를 개발 중입니다. 이 분야는 현재 가까운 미래에 온라인으로 제공될 단일 데이터베이스 Q&A 에이전트를 개발 중입니다.

다음 단계에서는 독립적으로 코딩 작업을 완료할 수 있는 에이전트를 출시할 예정입니다. 주요 역할은 특정 도구를 사용하여 배경 지식을 이해하고 단일 내에서 코딩 작업을 독립적으로 완료할 수 있는 것입니다. 라이브러리 전체가 아닌, 요구 사항에 여러 코드 베이스가 있고 프런트 엔드도 변경되고 백 엔드도 수정되어 마침내 요구 사항이 형성되는 것을 상상할 수 있습니다. .

따라서 먼저 단일 라이브러리의 코딩 에이전트를 구현한 다음 테스트 에이전트를 수행합니다. 테스트 에이전트는 작업 요구 사항 이해, 읽기 등 코딩 에이전트에서 생성된 결과를 기반으로 일부 테스트 작업을 자동으로 완료할 수 있습니다. 코드를 작성하고, 테스트 케이스를 생성하고, 자율적으로 실행합니다.

만약 이 두 단계의 성공률이 상대적으로 높다면 세 번째 단계로 넘어가겠습니다. 여러 에이전트가 함께 작업하여 AI 스케줄링을 기반으로 작업을 완료함으로써 요구 사항부터 코드, 테스트까지 전체 프로세스의 자율성을 실현할 수 있습니다.

엔지니어링 관점에서 각 단계가 더 나은 생산 수준 구현에 도달하고 궁극적으로 제품을 생산할 수 있도록 단계별로 진행할 것입니다. 하지만 학문적 관점에서 볼 때 그들의 연구 속도는 우리보다 빠를 것입니다. 이제 우리는 학문적, 공학적 관점에서 논의하고 있으며 모델 진화라는 세 번째 분야가 있습니다. 이 세 가지 경로는 현재 Alibaba Cloud 및 Tongyi Lab과 함께 진행 중인 연구 중 일부입니다.

결국 우리는 다중 에이전트 개념 아키텍처를 형성할 것입니다. 사용자는 대형 모델과 대화할 수 있고 대형 모델은 작업을 세분화할 수 있으며 다중 에이전트 협업 시스템이 있을 것입니다. 이 에이전트는 일부 도구를 연결하고 자체 실행 환경을 가질 수 있으며 여러 에이전트가 서로 협력할 수 있으며 일부 컨텍스트 메커니즘도 공유합니다.

본 제품 이미지는 3개의 레이어로 나누어집니다. 하단은 기본 레이어입니다. 기업의 경우 기본 레이어를 먼저 완료할 수 있습니다. 예를 들어, 이제 대규모 코드 모델을 도입할 수 있습니다. AI Bot을 즉시 구현하지는 않았지만 이제 IDE 코드 생성 플러그인 기능을 갖추고 있으며 Copilot 모델이라는 일부 작업을 이미 수행할 수 있습니다.

Copilot 모드는 인프라 계층 위의 에이전트 계층을 발전시켜 실제로 인프라를 재사용할 수 있습니다. 수행해야 할 검색 향상, 미세 조정 교육 및 지식 기반을 이제 수행할 수 있습니다. 이러한 지식의 분류와 자산의 축적은 원래 DevOps 플랫폼의 축적에서 비롯됩니다. 이제 일부 프롬프트 단어 프로젝트를 통해 현재 기본 기능 계층을 전체 DevOps 도구 체인과 결합할 수 있습니다.

요구사항 단계에서 이 대형 모델이 요구사항의 자동 분해를 실현하려면 과거 분해 데이터와 현재 요구사항을 대형 모델에 대한 프롬프트로 결합하기만 하면 됩니다. 직원이 더 잘 배정되었습니다. 실험 결과, 결과의 정확도가 상당히 높은 것으로 나타났습니다.

실제로 전체 DevOps 도구 체인에는 모든 작업에 Agent나 Copilot이 필요하지 않습니다. 이제 우리는 몇 가지 프롬프트 단어 프로젝트를 사용하고 있으며 CICD 프로세스의 자동 디버깅, 지식 기반 필드의 지능형 질문 및 답변 등을 포함하여 즉시 권한을 부여할 수 있는 많은 시나리오가 있습니다.

여러 에이전트를 구현한 후 에이전트는 IDE, 개발자 포털, DevOps 플랫폼 또는 IM 도구에 노출될 수 있습니다. 실제로는 의인화된 지능입니다. 에이전트 자체에는 자체 작업 공간이 있으며, 이 작업 공간에서 개발자나 관리자는 에이전트가 코드 작성을 완료하는 데 어떻게 도움이 되는지, 테스트를 완료하는 데 어떻게 도움이 되는지, 인터넷에서 어떤 종류의 지식을 얻는 데 사용되는지 모니터링할 수 있습니다. 작업을 완료하면 자체 작업 공간을 갖게 되며 궁극적으로 전체 작업의 완전한 프로세스를 실현하게 됩니다.

Tongyi Lingma를 경험하려면 여기를 클릭하세요 .