오류율은 10%에서 0.01%로 감소했으며 LinkedIn은 LLM 응용 프로그램 구현 경험을 완전히 공유했습니다.-일체 포함-php.cn

LLM(대규모 언어 모델) 기술이 점점 성숙해짐에 따라 다양한 산업에서 LLM 응용 프로그램 구현 속도가 가속화되었습니다. LLM의 실제 적용 효과를 높이기 위해 업계에서는 많은 노력을 기울여 왔습니다. 최근 LinkedIn 팀은 생성 AI 제품 구축에 대한 귀중한 경험을 공유했습니다. LinkedIn은 생성 AI를 기반으로 한 제품을 구축하는 것이 순조롭게 진행되지 않았으며 여러 영역에서 어려움을 겪었다고 말합니다. 다음은 LinkedIn 블로그 원문입니다. 지난 6개월 동안 LinkedIn 팀은 회원들이 입사 지원하고 전문 콘텐츠를 검색하는 방법을 재구성하는 새로운 AI 경험을 개발하는 데 열심히 노력했습니다. 제너레이티브 AI의 폭발적인 성장은 우리로 하여금 1년 전에는 불가능했지만 지금은 가능한 것이 무엇인지 생각하게 만듭니다. 우리는 많은 아이디어를 시도했지만 성공하지 못했으며 궁극적으로 게시물에서 핵심 사항을 확인하거나 회사 업데이트에 대한 최신 정보를 유지하는 등 정보에 대한 더 빠른 액세스와 같은 핵심 기능이 제품에 필요하다는 사실을 발견했습니다. 직위에 대한 적합성 평가와 같은 정보의 점을 연결하십시오. 프로필 개선이나 인터뷰 준비 등 조언을 구하세요. ...

오류율은 10%에서 0.01%로 감소했으며 LinkedIn은 LLM 응용 프로그램 구현 경험을 완전히 공유했습니다.

예: 새로 개발된 시스템의 작동 방식

실제 시나리오를 사용하여 새로 개발된 시스템의 작동 방식을 보여줍니다. LinkedIn 피드를 스크롤하다가 디자인의 접근성에 관한 흥미로운 게시물을 우연히 발견했다고 상상해 보세요. 이 기사 외에도 "기술 회사의 비즈니스 가치를 높이는 접근성의 예는 무엇입니까?"와 같이 주제를 더 깊이 탐구할 수 있는 몇 가지 소개 질문도 제공됩니다.

시스템 배경 운영:

올바른 에이전트 선택: 시스템이 문제를 처리하고 문제를 처리하는 데 가장 적합한 AI 에이전트를 결정합니다. 이 경우 기술 회사 내 접근성에 대한 귀하의 관심을 식별하고 일반 지식 검색 수행을 전문으로 하는 AI 에이전트에게 귀하의 쿼리를 라우팅합니다.
정보 수집: AI 에이전트는 내부 API와 Bing의 조합을 호출하여 디자인의 접근성이 기술의 비즈니스 가치에 어떻게 기여하는지 강조하는 구체적인 예와 사례 연구를 검색합니다.
답장 작성: 필요한 정보를 바탕으로 상담원은 이제 답장을 작성할 수 있습니다. 데이터를 일관되고 정보가 풍부한 답변으로 필터링하고 합성하여 접근성 이니셔티브가 기술 회사에 비즈니스 가치를 어떻게 제공하는지에 대한 명확한 예를 제공합니다. 보다 대화형 경험을 만들기 위해 기사 링크나 게시물에 언급된 사람들의 프로필과 같은 첨부 파일을 사용하기 위해 내부 API 호출이 이루어집니다.

상호작용:

"어떻게 하면 내 경력을 이 분야로 바꿀 수 있나요?"라고 물으면 시스템이 위 프로세스를 반복하지만 이제 직업 및 직업(경력 및 직업) AI 에이전트로 전환됩니다. 몇 번의 클릭만으로 모든 주제를 더 깊이 파고들고, 실행 가능한 통찰력을 얻거나, 다음 취업 기회를 찾을 수 있습니다.

기술적 기반:

대부분의 새로운 기능은 LLM 기술의 도움으로 가능해졌습니다.

전체 디자인:

시스템 파이프라인은 생성 인공 지능 시스템의 일반적인 디자인 패턴인 RAG(Retrieval Augmented Generation)를 따릅니다. 놀랍게도 파이프라인을 구축하는 일은 우리가 예상했던 것보다 덜 골치 아픈 일이었습니다. 단 며칠 만에 우리는 기본 프레임워크를 준비하고 실행했습니다.

라우팅: 쿼리가 범위 내에 있는지와 이를 전달할 AI 에이전트를 결정합니다.
검색: 회상 지향 단계에서 AI 에이전트는 호출할 서비스와 호출 방법(예: LinkedIn 사람 검색, Bing API 등)을 결정합니다.
생성: 검색된 시끄러운 데이터를 선별하고 필터링하여 최종 응답을 생성하는 정밀 지향 단계입니다.
查 그림 1: 사용자 쿼리의 파이프라인을 단순화합니다. KSA는 "Knowledge Sharing Agent"의 약자로 사용자 쿼리를 처리할 수 있는 수십 개의 에이전트 중 하나입니다.
주요 디자인은 다음과 같습니다.
고정된 3단계 파이프라인,
생성된 대규모 모델을 위한 소형 모델,
인메모리 데이터베이스로 구동되는 내장 기반 검색(EBR), 프롬프트에 직접 삽입 특히 라우팅/검색을 위한 각 단계의 특정 평가 파이프라인입니다.
개발 속도
저희는 상식, 직업 평가, 직업 포인트 등 다양한 사람들이 독립적인 에이전트를 개발하는 작업을 분할하기로 결정했습니다.
개발 작업을 병렬화함으로써 개발 속도를 높이지만 이는 "조각화"라는 대가를 치르게 됩니다. 다양한 모델, 프롬프트 또는 도구를 통해 관리되는 보조자와 후속 상호 작용이 이루어질 때 통합된 사용자 경험을 유지하는 것이 어려워집니다.
이 문제를 해결하기 위해 우리는 간단한 조직 구조를 채택했습니다.
공통 구성 요소를 처리하고 전반적인 경험에 초점을 맞춘 작은 "수평" 엔지니어링 포드에는 다음이 포함됩니다.
제품 호스팅 서비스
평가/테스트 도구
글로벌 프롬프트 템플릿 모든 분야에서 사용됩니다(예: 에이전트의 글로벌 ID, 대화 기록, 탈옥 방어 등)
iOS/Android/웹 클라이언트용 공유 UX 구성 요소
클라이언트 코드를 변경하거나 릴리스하지 않고 새로운 UI 변경 사항을 게시하기 위한 서버 기반 UI 프레임워크.
주요 디자인은 다음과 같습니다.
분할 및 정복, 그러나 에이전트 수 제한
다양한 대화가 포함된 중앙 집중식 평가 파이프라인
공유 프롬프트 템플릿(예: "ID" 정의), UX 템플릿, 도구 및 계측
평가
사실 평가 응답의 질이 예상보다 어려웠습니다. 이러한 과제는 크게 지침 개발, 주석 확장, 자동화된 평가의 세 가지 영역으로 나눌 수 있습니다.
가이드라인 개발이 첫 번째 장애물입니다. 예를 들어 직업 평가를 생각해 보십시오. "이 직업에 대한 내 적합성을 평가해 주세요"를 클릭하고 "당신은 매우 적합합니다"라는 말을 듣는 것은 별로 쓸모가 없습니다. 우리는 진정성이 있고 공감적인 답변을 원합니다. 일부 사용자는 현재 자신에게 적합하지 않은 분야로 경력 변경을 고려할 수 있으며 격차와 다음 단계를 이해하는 데 도움이 필요할 수 있습니다. 이러한 세부 사항의 일관성을 보장하는 것은 주석자에게 매우 중요합니다.
댓글 연장이 두 번째 단계입니다. 일관되고 다양한 주석자가 필요합니다. 당사의 내부 언어학자 팀은 최대 500개의 일일 대화를 평가하고 전체 품질 점수, 환각 비율, AI 위반, 일관성, 스타일 등 관련 지표를 캡처하는 도구와 프로세스를 구축했습니다.
자동 평가 작업이 아직 진행 중입니다. 자동화된 평가가 없으면 엔지니어는 결과를 시각적으로 검사하고 제한된 예시 세트에 대해서만 테스트할 수 있었으며 측정항목을 이해하기까지 1일 이상이 지연되었습니다. 우리는 위의 지표를 평가하기 위해 모델 기반 평가자를 구축하고 있으며 환각 감지에서 어느 정도 성공을 거두기 위해 노력하고 있으며 엔드투엔드 자동화 평가 파이프라인을 통해 더 빠른 반복이 가능해집니다.骤 그림 2: 평가 단계.

내부 API 호출
LinkedIn은 차별화된 가치를 제공하는 제품을 구축하는 데 중요한 사람, 회사, 기술, 교육 과정 등에 대한 풍부하고 고유한 데이터를 보유하고 있습니다.

그러나 LLM은 이 정보에 대한 교육을 받지 않았으므로 이를 추론하고 응답을 생성하는 데 사용할 수 없습니다.

이 문제를 해결하기 위한 표준 패턴은 내부 API가 호출되고 해당 응답이 후속 LLM 프롬프트에 삽입되어 응답을 지원하기 위한 추가 컨텍스트를 제공하는 RAG(검색 증강 생성) 파이프라인을 설정하는 것입니다.

이 데이터 중 상당수는 다양한 마이크로서비스의 RPC API를 통해 내부적으로 노출됩니다.
우리는 이러한 API 주위에 "기술"을 래핑하여 이 문제를 해결합니다. 각 스킬에는 다음 구성 요소가 있습니다.
API의 기능과 사용 시기에 대한 인간 친화적인 설명
RPC API 호출을 위한 구성(엔드포인트, 입력 모드, 출력 모드 등)

LLM- 친숙한 입력 및 출력 모드

기본 유형(문자열/부울/숫자) 값
JSON 스키마에 대한 입력 및 출력 스키마 설명
LLM 친화적 스키마와 실제 RPC 스키마 간의 매핑을 위한 비즈니스 논리
이러한 기술은 다음과 같습니다. LLM이 프로필 보기, 기사/사람/직위/회사 검색, 내부 분석 시스템 쿼리 등 다양한 제품 관련 작업을 수행할 수 있도록 설계되었습니다.
Bing 검색과 같은 LinkedIn이 아닌 API를 호출하는 데에도 동일한 기술이 사용됩니다.

그림 3: 기술을 사용하여 내부 API를 호출합니다.

우리는 LLM에게 특정 작업을 해결하기 위해 사용할 기술을 결정하도록 요청한 다음(계획을 통한 기술 선택) 기술을 호출하기 위한 매개변수를 출력합니다(함수 호출). 호출의 매개변수는 입력 패턴과 일치해야 하므로 LLM에 이를 구조화된 방식으로 출력하도록 요청합니다. 대부분의 LLM은 구조화된 출력을 위해 YAML 및 JSON에 대해 교육을 받았습니다. YAML은 덜 장황하고 JSON보다 더 적은 토큰을 소비하기 때문에 선택했습니다.

우리가 직면한 문제 중 하나는 LLM 응답의 약 90%가 올바른 형식의 매개변수를 포함하지만 약 10%의 경우 LLM이 잘못되어 잘못된 형식의 데이터를 출력하거나 더 나쁜 경우에는 유효한 YAML도 아니라는 것입니다. .

이러한 오류는 인간에게는 사소한 것이지만 이를 구문 분석하는 코드의 충돌을 일으킬 수 있습니다. 10%는 단순히 무시할 수 없을 만큼 높은 수치이므로 이를 해결하기 위해 나섰습니다.

이 문제를 해결하는 표준 방법은 문제를 감지한 다음 LLM에 오류를 수정하고 추가 지침을 제공하도록 요청하는 것입니다. 이 접근 방식은 효과가 있지만 추가 LLM 호출로 인해 상당한 대기 시간이 추가되고 귀중한 GPU 용량이 소비됩니다. 이러한 제한을 피하기 위해 우리는 내부 방어 YAML 파서를 작성했습니다.

다양한 페이로드 분석을 통해 LLM에서 흔히 저지르는 실수를 식별하고 구문 분석 전에 이러한 오류를 적절하게 감지하고 패치하는 코드를 작성했습니다. 또한 패치 정확도를 높이기 위해 이러한 일반적인 오류 중 일부에 대한 힌트를 삽입하도록 힌트를 수정했습니다. 우리는 궁극적으로 이러한 오류 발생률을 약 0.01%로 줄일 수 있었습니다.

현재 생성 AI 제품에서 LLM 친화적 기술로 패키지된 API/에이전트의 동적 검색 및 호출을 위한 통합 기술 레지스트리를 구축하고 있습니다.

용량 및 대기 시간

용량과 대기 시간은 항상 주요 고려 사항입니다. 다음은 몇 가지 고려 사항입니다.

품질 및 대기 시간: CoT(사고 사슬)와 같은 기술은 품질을 향상하고 착각을 줄이는 데 매우 효과적입니다. 토큰이 아니므로 대기 시간이 늘어납니다.
처리량 및 지연 시간: 대규모 생성 모델을 실행할 때 활용도가 증가함에 따라 TimeToFirstToken(TTFT) 및 TimeBetweenTokens(TBT)가 증가하는 것이 일반적입니다.
비용: GPU 클러스터는 쉽게 구할 수 없고 비용도 많이 듭니다. 토큰이 너무 많이 소모되기 때문에 초기에 제품 테스트 일정을 잡아야 했습니다.
엔드 투 엔드 스트리밍: 전체 답변을 완료하는 데 몇 분 정도 걸릴 수 있으므로 인지된 지연 시간을 줄이기 위해 모든 요청을 스트리밍합니다. 게다가 우리는 실제로 파이프라인에서 엔드투엔드 스트리밍을 수행합니다. 예를 들어, 호출할 API를 결정하는 LLM 응답은 점진적으로 구문 분석되고, 매개변수가 준비되면 전체 LLM 응답을 기다리지 않고 API 호출이 트리거됩니다. 최종 종합 응답 역시 실시간 메시징 인프라를 사용해 고객에게 끝까지 전송되며, '책임 있는 AI' 등을 기반으로 점진적으로 처리됩니다.
비동기 비차단 파이프라인: LLM 호출은 처리하는 데 오랜 시간이 걸릴 수 있으므로 I/O 스레드를 차단하여 리소스를 낭비하지 않는 완전 비동기식 비차단 파이프라인을 구축하여 서비스 처리량을 최적화했습니다.
관심 있는 독자는 블로그의 원본 텍스트를 읽고 연구 내용에 대해 자세히 알아볼 수 있습니다. 원본 링크: https://www.linkedin.com/blog/engineering/generative-ai/musings-on-building-a-generative-ai-product