다음을 통해 공유


생성 AI 솔루션을 빌드하는 개발자를 위한 중요한 개념 및 고려 사항

LLM(큰 언어 모델)은 놀랍지만 제한 사항이 있습니다. 개발자는 이러한 제한 사항, LLM이 "기본 제공"할 수 있는 기능 및 이를 조정하여 빌드하는 생성 AI 솔루션에 대한 최상의 결과를 얻는 방법을 이해해야 합니다. 이 문서에서는 몇 가지 과제 및 제한 요인을 식별하고, 애플리케이션에 빌드하는 생성 AI 기능 유형에 관계없이 이러한 문제를 극복하고 콘텐츠 생성 프로세스를 제어하는 일반적인 방법을 설명합니다.

LLM을 사용할 때 발생하는 엔지니어링 문제

LLM을 사용할 때 알아야 할 가장 중요한 과제 또는 제한 사항:

  • 지식 차단 - LLM 학습 비용이 높기 때문에 지식의 몸은 특정 시점에 학습된 것으로 제한됩니다. 플러그 인 또는 기타 숙박 시설이 없으면 실시간 정보에 액세스할 수 없으며 개인 데이터에 액세스할 수도 없습니다.

  • 환각 - LLM은 통계적 확률과 약간의 임의성을 사용하여 정보를 생성합니다. 생성된 응답을 질문과 학습된 정보에서 인간의 의도에 맞게 유지하는 메커니즘이 있지만 정확하지 않은 응답을 만들 수 있습니다.

  • 투명성 - 다시 말하지만, 모델이 학습되는 방식으로 인해 더 이상 학습된 기본 지식에 액세스할 수 없습니다. 그리고 그들이 그랬더라도, 정보가 진실되고 처음에 근거를 두었다는 보장은 없습니다. 또한 생성된 응답이 정확한지 확인하는 확인 단계는 없습니다.

  • 도메인별 지식 없음 - "지식 차단, 내부 전용 회사 문서와 같은 개인 정보가 있는 경우 LLM은 이 정보에 대해 학습되지 않았으므로 도메인 관련 지식이 없습니다.

LLM의 가능한 문제 또는 문제를 완화하고 사용자와 조직에 도움이 되는 최상의 결과를 얻으려면 어떻게 해야 할까요? 먼저 LLM에서 데이터를 가져오는 위치를 보완할 수 있는 방법을 이해합니다.

LLM이 정보를 가져오는 위치 이해

LLM에서 최상의 결과를 얻는 좋은 출발점은 LLM이 정보를 얻는 위치 또는 방법을 이해하는 것입니다. 다음 범주는 LLM이 다양한 정보 원본과 상호 작용하여 응답을 생성하는 방법에 대한 다양한 방법을 나타냅니다.

가장 미리 학습된 지식과 상관 관계가 있는 검색-해제 생성이 있는 세 가지 유형의 검색 생성을 보여 주는 다이어그램, 검색 보강된 생성, 가장 많이 검색된 지식과 상관 관계가 있는 맨 아래의 검색 중심 생성을 보여 주는 다이어그램.

  • ROG(검색-해제 생성) - 이 방식은 LLM이 작동하는 전통적인 방식입니다. 여기서 모델은 생성 프로세스 중에 외부 정보에 액세스하거나 검색하지 않고 학습된 지식을 기반으로 응답을 생성합니다. 모델의 지식은 정적이며, 학습 데이터에 포함된 내용으로 제한됩니다. 창의적인 글쓰기 외에도 인터넷에서 쉽게 사용할 수 있는 정보에 대한 질문에 대답할 수 있습니다.

  • RAG(Retrieveal-Augmented Generation) - LLM의 생성 기능을 외부 데이터베이스 또는 문서에서 실시간으로 검색하는 기능과 결합합니다. 모델은 외부 원본을 쿼리하여 관련 정보를 찾은 다음 응답을 알리는 데 사용합니다. 이 접근 방식을 통해 모델은 미리 학습된 지식만으로도 보다 정확하고 최신 정보를 제공할 수 있습니다. 사용 사례에는 팩트 확인, 실시간 데이터 또는 도메인별 개인 데이터를 기반으로 하는 질문에 답변하는 것이 포함됩니다.

  • RCG(검색 중심 생성) - 외부 원본에서 가져온 정보에 대한 응답을 구조화하여 외부에서 검색된 콘텐츠에 더욱 중점을 둡니다. 모델은 검색된 텍스트의 큰 세그먼트를 출력에 직접 통합하여 사용자의 쿼리에 맞게 편집하거나 주석을 추가할 수 있습니다. 이 방법은 검색 기반 메서드와 생성 메서드 간의 하이브리드로 볼 수 있습니다. 여기서 균형은 모델의 자체 생성 기능보다 검색된 정보를 크게 선호할 수 있습니다. 사용 사례에는 더 긴 문서 요약, 여러 유사한 문서에서 비교 및 주제 탐색을 제공하는 연구 지원, 다양한 자료 원본을 결합된 출력으로 컴파일 또는 데이터 정렬하는 것이 포함됩니다.

ROG(검색 해제 생성)의 좋은 예는 ChatGPT입니다. 반면, 필요한 경우 코필로트(Bing을 통해)는 뉴스 원본의 외부 원본을 사용하고 해당 원본에 대한 링크를 제공하여 LLM을 확장합니다.

언뜻 보기에 RAG(검색-증강 세대) 및 RCG(검색 중심 생성)는 모두 외부 정보를 언어 생성 프로세스에 통합하는 것을 포함하기 때문에 비슷하게 들립니다. 그러나 생성 프로세스 내에서 검색된 정보의 우선 순위를 지정하고 활용하는 방법에는 차이가 있습니다.

RAG 시스템에서 외부 데이터 검색은 미리 학습된 언어 모델의 생성 기능을 보강하는 데 사용됩니다. 검색된 정보는 모델이 응답을 알리는 데 사용하는 더 많은 컨텍스트 또는 특정 데이터를 제공합니다. 여기서는 언어 모델의 생성 측면이 응답의 중심이 되는 반면 검색된 데이터는 정확도 또는 깊이를 향상시키는 지원 요소 역할을 합니다.

반면, RCG 시스템은 검색된 정보 자체에 더 중점을 둡다. 이러한 시스템에서 검색된 데이터는 주로 검색된 텍스트를 구체화, 서식 지정 또는 약간 향상시키는 생성 모델의 역할과 함께 응답의 중심 이 되는 경우가 많습니다. 이 방법은 정보의 정확도와 직접적인 관련성이 가장 중요하고 덜 창의적인 합성 또는 추정이 필요한 경우에 특히 사용됩니다.

RAG 및 RCG를 모두 구동하는 데이터의 외부 검색 메커니즘은 초기 학습을 기반으로 LLM에서 사용할 수 있는 지식을 보완하는 두 가지 일반적인 방법인 LLM을 미세 조정하는 방법과 문서의 벡터화된 포함을 저장하는 방법에 대한 문서에서 설명합니다.

검색 모델 간의 차이점을 이해하면 특정 애플리케이션에 적합한 접근 방식을 선택하고 창의적인 합성의 필요성과 원본 재료에 대한 정확도 및 충실도의 필요성의 균형을 맞추는 데 도움이 될 수 있습니다.

유추의 작동 방식에 영향을 주는 요인 이해

ChatGPT의 웹 기반 사용자 인터페이스에 익숙할 수 있으므로 질문에 대답하는 방법을 이해하면 자체 애플리케이션에서 생성 AI 기능을 빌드할 때 중요한 개념을 이해하는 데 도움이 될 수 있습니다.

사용자가 ChatGPT와 채팅할 때 사용자 인터페이스 디자인은 사용자와 LLM 간의 여러 상호 교환 과정에서 상태를 유지하는 장기 실행 채팅 세션의 환상을 제공합니다. 실제로 지정된 채팅 세션의 경우 모든 프롬프트와 LLM의 모든 응답(완료라고도 함)이 각각의 새 프롬프트와 함께 전송됩니다. 따라서 대화가 커짐에 따라 이전 프롬프트 및 완료를 모두 처리하기 위해 LLM에 점점 더 많은 텍스트를 보냅니다. ChatGPT는 현재 프롬프트에 대한 응답을 작성할 때 현재 프롬프트뿐만 아니라 전체 채팅 세션의 컨텍스트를 사용합니다. 전체 채팅 세션을 컨텍스트 창이라고 합니다.

작업하는 ChatGPT 버전에 따라 컨텍스트 창 길이 제한이 있습니다. 컨텍스트 창 길이 제한을 초과하는 채팅 대화의 모든 부분은 최신 프롬프트에 대한 응답을 작성할 때 무시됩니다.

긴 대화는 처음에는 좋은 생각처럼 보일 수 있지만 긴 컨텍스트 창은 프롬프트를 처리하고 완료를 작성하는 데 필요한 계산의 양에 영향을 줄 수 있습니다. 이는 응답의 대기 시간과 OpenAI가 요청을 처리하는 데 드는 비용에 영향을 줍니다.

ChatGPT의 컨텍스트 창 제한은 무엇인가요? 또는 ChatGPT에서 사용할 수 있는 단어는 몇 개입니까? 컨텍스트 창 제한은 작업 중인 LLM 모델, 버전 및 버전에 따라 달라집니다. 또한 컨텍스트 길이는 단어가 아닌 토큰으로 측정됩니다. 토큰은 모델이 이해하고 생성할 수 있는 가장 작은 텍스트 단위입니다. 이러한 단위는 단어, 단어의 일부(예: 음절 또는 줄기) 또는 개별 문자일 수 있습니다. 토큰은 NLP(자연어 처리)의 핵심입니다.

토큰 사용은 개발자에게 다음 두 가지 중요한 고려 사항에 영향을 줍니다.

  • 최대 컨텍스트 창 제한
  • 프롬프트 및 완료당 가격

토큰화란?

"토큰화"는 텍스트를 토큰으로 변환하는 프로세스입니다. LLM을 사용하여 학습 또는 유추(프롬프트에 따라 완성을 구성하는 프로세스)를 위한 데이터를 준비하는 중요한 단계입니다. 이 프로세스에는 복잡한 텍스트를 관리 가능한 조각(토큰)으로 분할하는 것을 포함하여 여러 단계가 포함되며, 그러면 모델에서 처리할 수 있습니다. 이 프로세스는 공백 및 문장 부호로 텍스트를 분할하는 것과 같이 간단할 수 있으며, 다른 언어, 모폴로지(단어 구조) 및 구문(단어 배열)을 처리하는 정교한 알고리즘을 포함하는 보다 복잡할 수 있습니다. LLM 연구원과 개발자는 달성하려는 작업을 기반으로 토큰화 방법을 결정합니다. OpenAI에는 토큰화에 대해 자세히 설명하는 유용한 페이지 가 있으며 문장이나 단락이 토큰으로 분해되는 방법을 보여 주는 계산기도 있습니다.

OpenAI Tokenizer 페이지의 맨 아래에 있는 메모에 따르면 일반적인 영어 텍스트에서 하나의 토큰은 약 4자 정도에 해당합니다. 즉, 평균적으로 100개의 토큰은 약 75단어 또는 토큰당 단어의 3분의 1과 같습니다.

OpenAI 토크나이저 페이지에서는 OpenAI API로 전송된 지정된 프롬프트에 사용할 토큰 수를 프로그래밍 방식으로 예측할 수 있는 Python 및 JavaScript용 패키지인 tiktoken에 대해서도 설명합니다.

토큰 사용량이 청구에 영향을 줍니다.

각 Azure OpenAI API에는 서로 다른 청구 방법이 있습니다. 채팅 완료 API를 사용하여 텍스트를 처리하고 생성하는 경우 프롬프트로 제출하는 토큰 수와 결과로 생성된 토큰 수(완료)에 따라 요금이 청구됩니다.

각 LLM 모델(예: gpt-3.5, gpt-3.5-turbo, gpt-4 등)은 일반적으로 토큰을 처리하고 생성하는 데 필요한 계산의 양을 반영하는 다른 가격을 가집니다. 가격이 "토큰 1,000개당 가격" 또는 "100만 토큰당 가격"으로 표시되는 경우가 많습니다.

이 가격 책정 모델은 사용자 상호 작용을 디자인하는 방법과 추가하는 사전 및 후처리 양에 큰 영향을 미칩니다.

시스템 및 사용자 프롬프트

지금까지 토론은 사용자와 ChatGPT 간의 교환을 구성하는 프롬프트인 "사용자 프롬프트"에만 초점을 맞췄습니다.

OpenAI는 사용자가 정의하고 모든 채팅 대화에 추가되는 지나치게 아치형 명령 집합인 "시스템 프롬프트"("사용자 지정 지침"라고도 함)를 도입했습니다. 새 채팅 세션을 시작할 때마다 LLM이 항상 관찰하도록 하려는 메타 지침 집합으로 간주합니다. 예를 들어 시스템 프롬프트를 "항상 시적인 형태의 하이쿠로 응답"하도록 설정할 수 있습니다. 이 시점부터 ChatGPT에 대한 모든 새 프롬프트는 대답을 포함하는 haiku를 생성합니다.

"haiku 형식으로 회신"은 유용한 예제는 아니지만 프롬프트 자체를 수정하여 프롬프트에 대한 LLM 완료에 영향을 줄 수 있다는 아이디어를 보여 줍니다.

사용자의 프롬프트를 수정하려는 이유는 무엇인가요? 회사 직원, 고객 및 파트너를 포함할 수 있는 전문 대상 그룹을 위한 생성 AI 기능 또는 애플리케이션을 빌드하는 경우 응답할 수 있는 토픽 또는 도메인의 범위를 제한하는 보호 장치를 추가할 수 있습니다.

그러나 사용자의 프롬프트를 수정하는 것은 사용자의 텍스트 생성 환경을 개선하는 한 가지 방법일 뿐입니다.

ChatGPT에서 사용자의 텍스트 생성 환경을 개선하는 방법

텍스트 생성 결과를 개선하기 위해 개발자는 프롬프트를 단순히 개선하는 것으로 제한되며 도움이 될 수 있는 프롬프트 엔지니어링 기술이 많이 있습니다. 그러나 고유한 생성 AI 애플리케이션을 빌드하는 경우 사용자에 대한 텍스트 생성 환경을 개선하는 여러 가지 방법이 있으며, 모든 애플리케이션 구현을 실험해 볼 수 있습니다.

  • 프로그래밍 방식으로 사용자 프롬프트 수정
  • 유추 파이프라인 구현
  • 검색-증강 생성(다른 문서에서 설명)
  • 미세 조정(다른 문서에서 설명)

프로그래밍 방식으로 사용자 프롬프트 수정

프로그래밍 방식의 관점에서 볼 때 사용자 대화에 시스템 프롬프트를 추가하기 위한 특별한 API는 없습니다. 필요에 따라 프롬프트에 지침을 추가하기만 하면 됩니다. 그러나 사용자 프롬프트를 개선하기 위한 몇 가지 기술이 있습니다.

  • 상황별 초기화: 원하는 도메인 내에서 대화의 컨텍스트를 명시적으로 설정하는 크래프트 시스템 프롬프트입니다. 여기에는 각 상호 작용의 시작 부분에 간단한 설명 또는 지침 집합을 제공하여 AI가 문제 도메인 내에 유지되도록 안내하는 작업이 포함됩니다.
  • 예제 기반 지침: 초기 프롬프트에서 도메인과 관련된 질문 및 답변 형식의 예제를 포함합니다. 이를 통해 AI는 예상되는 응답의 종류를 이해할 수 있습니다.

또한 모든 프롬프트 엔지니어링 기술을 적용할 수 있습니다. 어떤 방식으로든 프로그래밍 방식으로 이 작업을 수행할 수 있는 경우 사용자를 대신하여 사용자의 프롬프트를 개선할 수 있습니다.

이 방법의 주의 사항은 프롬프트가 길수록 LLM을 호출할 때마다 비용이 더 많이 든다는 것입니다. 그럼에도 불구하고, 이것은 논의 될 접근 방식 중 가장 저렴 할 가능성이 높습니다.

유추 파이프라인 구현

프로그래밍 방식으로 사용자의 프롬프트를 수정하는 것 이상의 다음 단계는 전체 유추 파이프라인을 만드는 것입니다.

유추 파이프라인은 원시 입력(예: 텍스트 또는 이미지)을 사용하고 이를 사용하여 기본 프롬프트(전처리)를 수행하거나 완료를 확인하여 사용자에게 표시(사후 처리)하기 전에 사용자의 요구 사항을 충족하는지 확인하기 전에 "정리"하는 엔드 투 엔드 프로세스입니다.

전처리에는 키워드 검사, 관련성 점수 매기기 또는 쿼리 변환이 예상 도메인 언어에 더 적합하도록 포함될 수 있습니다. 예를 들어 사용자가 제출한 초기 프롬프트를 분석하고 프롬프트가 적합한지, 수락할 대상의 경계 내에 있는지, 잘못된 프레미스를 기반으로 하는 경우 또는 특정 바이어스를 방지하기 위해 다시 작성해야 하는 경우 LLM에 요청하여 시작할 수 있습니다. LLM이 프롬프트를 분석하고 문제를 발견하면 한 단계 더 나아갈 수 있습니다. LLM에 프롬프트를 다시 단어로 다시 입력하여 잠재적으로 답변을 개선하도록 요청할 수 있습니다.

사후 처리에는 답변의 관련성 및 도메인에 대한 적합성 유효성 검사가 포함될 수 있습니다. 여기에는 도메인 요구 사항에 맞지 않는 답변 제거 또는 플래그 지정이 포함될 수 있습니다. 예를 들어 LLM에서 제공하는 완료를 검사하여 품질 및 안전 요구 사항을 충족하는지 확인할 수 있습니다. LLM에 답변을 평가하여 준수하도록 요청한 요구 사항을 충족하는지 확인할 수 있습니다. 그렇지 않은 경우 LLM에 완료를 수정하도록 요청하고 만족스러운 결과가 발생할 때까지 이 작업을 반복할 수 있습니다.

사전 처리 단계를 추가하는 한 가지 주의 사항이 있습니다. 유추 파이프라인에서 LLM에 대한 호출을 추가할 때마다 전체 대기 시간(응답 시간)과 사용자와의 각 상호 작용 비용이 증가합니다. 숙련된 소프트웨어 개발자는 소프트웨어 시스템의 예산, 성능 및 효과에 영향을 주는 리더십에 의해 이루어져야 하는 이러한 종류의 장단점에 대해 이미 알고 있을 것입니다.

고급 검색-증강 세대 시스템 빌드 문서에서는 유추 파이프라인을 빌드하는 특정 단계를 자세히 설명합니다.

완료에 영향을 주는 기타 요인

프롬프트를 프로그래밍 방식으로 수정하고 유추 파이프라인 및 기타 기술을 만드는 것 외에도 검색-보강된 생성 및 미세 조정을 사용하여 큰 언어 모델을 보강하는 방법에 대해 자세히 설명합니다. 또한 Azure OpenAI API를 호출할 때 수정할 수 있는 매개 변수가 있습니다.

채팅 끝점 설명서에는 완료의 다양한 측면에 영향을 줄 수 있는 전달에 필요한 매개 변수와 선택적 매개 변수가 나열되어 있습니다. 대신 SDK를 사용하는 경우 선택한 언어에 대한 SDK 설명서를 참조하세요. 매개 변수를 실험하려는 경우 플레이그라운드에서 실험해 볼 수 있습니다.

  • 온도: 모델에서 생성된 출력의 임의성을 제어합니다. 0이 되면 모델은 결정적이 되어 학습 데이터에서 가장 가능성이 큰 다음 토큰을 일관되게 선택합니다. 1의 온도에서 모델은 높은 확률 토큰을 선택하고 출력에 임의성을 도입하는 것 사이에서 균형을 이깁니다.

  • 최대 토큰: 응답의 최대 길이를 제어합니다. 더 높거나 낮은 제한을 설정하면 생성된 콘텐츠의 세부 정보 및 범위에 영향을 줄 수 있습니다.

  • Top P(핵 샘플링): 응답의 임의성을 제어하기 위해 온도와 함께 사용됩니다. 상위 P는 각 토큰을 생성할 때 AI가 확률 질량의 상위 P%만 고려하도록 제한합니다. 값이 낮을수록 더 집중적이고 예측 가능한 텍스트가 되지만 값이 높을수록 다양성이 높아질 수 있습니다.

  • 빈도 페널티: 모델이 동일한 줄 또는 구를 반복할 가능성을 줄입니다. 이 값을 늘리면 생성된 텍스트의 중복성을 방지하는 데 도움이 됩니다.

  • 프레즌스 페널티: 모델이 완성 시 새로운 개념과 용어를 도입하도록 권장합니다. 프레즌스 페널티는 보다 다양하고 창의적인 출력을 생성하는 데 유용합니다.

  • 시퀀스 중지: 하나 이상의 시퀀스를 지정하여 API에 추가 토큰 생성을 중지하도록 지시할 수 있습니다. 저장 시퀀스는 문장이나 단락 끝에 완성을 끝내는 것과 같이 출력 구조를 제어하는 데 유용합니다.

  • Logit Bias: 완료 시 지정된 토큰이 나타날 가능성을 수정할 수 있습니다. Logit Bias는 특정 방향으로 완료를 안내하거나 원치 않는 콘텐츠를 표시하지 않는 데 사용할 수 있습니다.

Microsoft OpenAI 세이프가드 이해

LLM의 응답을 특정 주제 또는 도메인에 바인딩된 상태로 유지하는 것 외에도 사용자가 LLM에 대해 묻는 질문의 종류에 대해서도 염려할 수 있습니다. 생성되는 답변의 종류를 고려하는 것이 중요합니다.

첫째, Microsoft OpenAI Services에 대한 API 호출은 잠재적으로 불쾌감을 줄 수 있는 콘텐츠를 자동으로 필터링하고 이를 여러 필터링 범주에 걸쳐 다시 보고합니다.

OpenAI의 조정 API를 직접 사용하여 잠재적으로 유해한 콘텐츠에 대한 콘텐츠를 명시적으로 확인할 수 있습니다.

둘째, Azure AI Content Safety를 사용하여 텍스트 조정, 이미지 조정, 탈옥 위험 검색 및 보호된 자료 검색에 도움을 줄 수 있습니다. 포털 설정, 구성 및 보고 환경을 애플리케이션에 추가하여 유해한 콘텐츠를 식별할 수 있는 코드와 결합합니다.

애플리케이션 디자인 결정에 영향을 줄 수 있는 최종 고려 사항

토큰화, 가격 책정, 컨텍스트 창을 이해하고 프로그래밍 방식의 향상된 기능을 구현하여 사용자의 텍스트 생성 환경을 개선하는 것은 생성 AI 시스템을 디자인하는 방법에 영향을 줍니다. 다음은 애플리케이션 디자인 결정에 영향을 주는 이 문서에서 고려해야 할 사항 및 기타 내용의 짧은 목록입니다.

  • 비용 고려 사항에 대해 최신 AI 모델을 사용해야 하는 필요성을 평가합니다. 저렴한 모델은 애플리케이션의 요구 사항에 적합하여 성능과 예산 제약 조건의 균형을 맞추는 데 충분할 수 있습니다.
  • 사용자 환경에 큰 영향을 주지 않고 비용을 관리하도록 컨텍스트 기간 길이를 최적화하는 것이 좋습니다. 대화의 불필요한 부분을 트리밍하면 품질 상호 작용을 유지하면서 처리 비용을 줄일 수 있습니다.
  • 토큰화와 입력 및 출력의 세분성이 성능에 미치는 영향을 평가합니다. 선택한 LLM이 토큰화를 처리하는 방법을 이해하면 API 호출의 효율성을 최적화하여 비용을 절감하고 응답 시간을 개선하는 데 도움이 될 수 있습니다.

생성 AI 솔루션을 즉시 빌드하는 실험을 시작하려면 Python용 사용자 고유의 데이터 샘플을 사용하여 채팅을 시작하는 것이 좋습니다. .NET, JavaJavaScript에서도 사용할 수 있는 자습서 버전이 있습니다.