llm 0.37, 모델 선택 기능 추가 및 기본값 변경

Simon Willison은 11월 2일 llm 0.37을 출시하며 모델 옵션을 추가하는 한편, 자체 기본값을 선택하지 않은 사용자의 기본 설정을 변경했다. 이번 업데이트는 간편해진 구성 방식과 함께 실질적인 질문을 던진다. 개발자는 기존 워크플로의 예측 가능성을 해치지 않으면서 모델 선택지를 얼마나 늘릴 수 있을까?

언어 모델에 접근하기 위한 Willison의 명령줄 인터페이스이자 Python 라이브러리인 LLM은 애플리케이션과 이들이 사용하는 모델 사이에 위치한다. 최신 릴리스는 이 연결 역할을 더욱 명확히 한다. 개발자는 호환 가능한 서비스를 더 간단히 등록할 수 있게 되었고, 임베딩 지원은 다양한 미디어 유형을 처리하는 범위를 확장한다.

관련 비교 대상은 개별 제공업체에 직접 연결하는 방식과 Ollama 같은 로컬 모델 도구다. 공통 인터페이스는 이러한 선택지 전반의 설정 작업을 줄여 준다. 그렇다고 각 도구의 동작이 동일해지는 것은 아니다. 이 차이는 이번 릴리스의 주요 기능, 신뢰성 수정, 그리고 AI 지원 기여를 검토한 Willison의 경험을 연결한다.

llm 0.37이 모델 목록 외에 바꾸는 것

이번 릴리스는 도구를 통해 사용할 수 있는 모델뿐 아니라 개발자가 모델을 선택하고 연결하는 방식도 바꾼다.

릴리스 발표에 따르면 약 두 달간 누적된 작업이 담겼다. gpt-6.1-sol과 gpt-6.1-terra를 추가하고, llm openai endpoint add를 도입했으며, 대체 모델을 gpt-6-luna로 변경했다. 이 기본값 변경은 사용자가 자체 기본값을 선택하지 않았을 때 적용된다.

이들은 서로 다른 종류의 업데이트다. 이름이 지정된 모델을 추가하면 기존 선택 목록이 확장된다. 엔드포인트 관리를 추가하면 개발자가 그 목록을 유지하는 방식이 달라진다. 대체 모델을 변경하면 사용자가 모델 선택을 명시하지 않았을 때 발생하는 결과에 영향을 준다.

엔드포인트는 소프트웨어가 모델 요청을 보내는 서비스 주소다. OpenAI 호환 엔드포인트는 OpenAI의 애플리케이션 프로그래밍 인터페이스, 즉 API와 관련된 규칙을 사용해 요청을 받는다. 호환성 덕분에 기존 클라이언트는 완전히 다른 통합 방식을 요구하지 않고도 다른 서비스에 연결할 수 있다.

개발자라면 사용 가능한 모델과 선택된 모델의 차이에 주목할 필요가 있다. 새 항목은 누군가 선택하기 전까지 아무런 동작도 하지 않는다. 변경된 대체값은 모델을 한 번도 지정하지 않았던 기존 명령에 영향을 줄 수 있다.

명시적으로 모델을 선택해 정기 요약 작업을 실행하는 개발자를 생각해 보자. 이 선택은 의도한 의존성을 드러낸다. 반면, 그 선택 없이 비슷한 명령을 실행하는 동료는 환경의 기본값에 의존하게 된다.

어느 쪽도 자동으로 잘못된 방식은 아니다. 기본값은 모든 결정을 처음부터 내리지 않고도 시작할 수 있도록 돕는다. 명시적인 선택은 업그레이드나 환경 변경 후 워크플로가 다르게 동작한 이유를 팀이 설명하는 데 도움이 된다.

이번 릴리스는 타입이 지정된 임베딩 첨부 파일 지원도 확장한다. 임베딩은 의미를 기준으로 콘텐츠를 비교하는 데 사용되는 수치적 표현이다. 타입이 지정된 첨부 파일은 모든 바이너리 입력을 동일하게 취급하지 않고, 그 과정에 들어가는 콘텐츠 유형에 관한 정보를 보존한다.

이는 미디어를 받는 모델이 원시 바이트만으로는 충분한 정보를 얻지 못하기 때문에 중요하다. 주변 소프트웨어는 첨부 파일이 이미지, 오디오 또는 다른 지원 입력을 나타내는지 전달해야 한다.

더 넓게 보면 이는 아키텍처의 변화다. LLM은 공통 인터페이스를 유지하면서 모델 선택, 서비스 구성, 입력 처리의 차이를 수용하고 있다. 개발자가 더 다양한 작업에 같은 도구를 사용하면서 이러한 책임은 더욱 눈에 띄게 된다.

따라서 llm 0.37을 평가하는 독자는 접근성과 동작을 분리해서 봐야 한다. 이번 릴리스는 접근성을 확장하고 정리한다. 특정 워크플로가 개선되는지는 여전히 그 워크플로의 입력, 출력, 요구 사항에 달려 있다.

이 차이는 익숙한 모델 추가를 담은 릴리스가 모델 이름 이상으로 주목할 만한 이유도 설명한다. 구성 선택은 발표가 더 이상 관심을 끌지 않은 뒤에도 재현성에 영향을 미친다.

간편해진 모델 전환은 워크플로 소유자에게 책임을 넘긴다

모델 전환은 통합 과정의 마찰을 줄이지만, 전환의 결과는 여전히 누군가가 책임져야 한다.

직접적인 수혜자는 호스팅 서비스와 로컬 모델을 넘나들며 실험하는 개발자다. 공통 클라이언트는 매번 평가할 때마다 기본 요청 처리를 새로 구축하는 수고를 덜어 줄 수 있다. 실험이 반복 작업으로 바뀌면 이 편의성은 더 큰 의미를 갖는다.

프로토타입은 보통 모델이 작업을 완료할 수 있는지를 묻는다. 운영 워크플로는 결과가 허용 가능한 조건에서 허용 가능한 형식으로 도착하는지도 묻는다. 라이브러리가 연결을 단순화하더라도, 이 질문의 책임은 애플리케이션 소유자에게 있다.

내부 장애 보고서에서 요약을 생성하는 엔지니어링 팀을 상상해 보자. 탐색 단계에서 팀은 같은 문서로 여러 모델을 시험한다. 동료들이 그 요약에 의존하기 시작하면 일관성은 제품의 일부가 된다.

더 읽기 좋은 문장을 생성하는 모델 변경도 운영 세부 사항을 누락할 수 있다. 다른 변경은 모든 세부 사항을 보존하면서도 후속 애플리케이션이 받을 수 없는 형식을 도입할 수 있다. 성공적인 엔드포인트 구성만으로는 어느 결과도 파악할 수 없다.

이 팀의 부담은 쉬워진 실험이 이미 형성된 기대와 맞부딪히면서 생긴다. 필요한 대응은 후보 모델을 일상적인 선택으로 삼기 전에 허용 가능한 동작을 정의하는 것이다.

바로 이 지점에서 모델 전환은 조직의 문제가 된다. 클라이언트를 구성하는 사람이 요약을 검토하는 사람과 다를 수 있다. 데이터 접근을 승인하는 사람도 또 다른 책임을 맡을 수 있다.

공통 인터페이스는 명령이 환경 전반에서 익숙하게 보이기 때문에 이러한 경계를 덜 눈에 띄게 만들 수 있다. 익숙한 문법이 정보의 이동 경로와 출력 평가 방식에 관한 명시적 결정을 대신해서는 안 된다.

LLM의 기존 로깅 제어 기능은 이 책임의 또 다른 부분을 보여 준다. 이 도구는 일반적으로 프롬프트와 응답을 로컬 데이터베이스에 기록한다. 사용자는 개별 요청을 포함해 로깅을 비활성화할 수 있다.

로그는 변경된 결과를 설명하는 데 도움이 될 수 있지만, 워크플로 중 제출된 정보에 관한 별도 기록도 만든다. 모델을 평가하는 개발자는 원격 요청과 로컬 기록을 모두 고려해야 한다.

유용한 실험이 복사된 명령을 통해 팀의 관례가 될 때 이는 특히 관련이 있다. 명령은 보존, 모델 선택, 허용 가능한 소스 자료에 관한 원래의 가정보다 더 쉽게 전파될 수 있다.

검색 가능한 지식 기반을 구축하는 팀이라면, 동일한 소유권 문제는 초기 모델 호출을 넘어 확장된다. 누군가는 소스 정체성, 접근 기대치, 검색된 자료와 생성된 답변의 관계를 유지해야 한다.

이는 실질적인 함의일 뿐, 이번 릴리스가 모든 사용자에게 새로운 거버넌스 의무를 만든다는 증거는 아니다. 개인 실험과 공동의 프로덕션 프로세스는 요구 사항이 다르다.

공통된 교훈은 더 좁다. 간편한 구성은 평가를 시작하는 비용을 낮춘다. 하지만 다른 사람들이 신뢰하는 워크플로에서 모델이 자리를 얻을 시점을 결정해 주지는 않는다.

공통 인터페이스가 공통 동작을 보장하지는 않는다

OpenAI 호환성은 연결 규칙일 뿐, 모든 백엔드가 같은 워크플로를 지원한다는 약속은 아니다.

LLM의 엔드포인트 구성 문서는 플러그인과 함께 추가 호환 모델 지원을 설명한다. 플러그인은 기본 애플리케이션에 기능이나 제공업체 통합을 추가하는 확장 기능이다.

이는 개발자에게 공통 작업 환경으로 들어가는 여러 경로를 제공한다. 호환 엔드포인트는 익숙한 요청 규칙을 재사용할 수 있다. 제공업체별 확장 기능은 그 규칙에 맞지 않는 동작을 수용할 수 있다.

중요한 비교는 공통 인터페이스의 편의성과 직접 통합의 구체성 사이에 있다. 공통 인터페이스는 일반적인 작업을 더 쉽게 반복하게 해 준다. 직접 통합은 제공업체 고유의 기능과 가정을 더 명시적으로 드러낸다.

어느 경로도 모든 경우에 우세하지는 않다. 올바른 선택은 애플리케이션이 실제로 요구하는 기능과 보존해야 하는 제공업체별 동작의 정도에 달려 있다.

Ollama는 로컬 모델 사용과 호환 클라이언트 연결을 모두 지원하므로 유용한 참고 사례다. 호환성 문서는 OpenAI API의 일부 기능 지원을 명시적으로 설명한다.

이 한정은 중요하다. 개발자는 호환성을 완전한 상호 교환 가능성의 보증이 아니라 지원되는 작업에 관한 설명으로 읽어야 한다. 기본적인 시연에서 성공한 요청이 완전한 애플리케이션 테스트보다 적은 것을 입증하는 이유다.

예를 들어 애플리케이션은 요청 전반에 걸쳐 대화 상태를 유지해야 할 수 있다. 다른 애플리케이션은 외부 함수를 호출하는 특정 메커니즘에 의존할 수 있다. 유사한 요청 문법이 두 요구 사항이 모든 서비스에서 작동함을 입증하지는 않는다.

관련 평가는 애플리케이션의 동작을 따라야 한다. 모델이 의도한 입력을 받을 수 있는가? 서비스가 필요한 출력을 반환할 수 있는가? 옵션을 거부하거나, 일찍 중단하거나, 오류를 반환하면 어떻게 되는가?

모델 전환이 스크립트 내부에서 일어날 때 이러한 질문은 더 중요해진다. 대화형 사용자는 예상치 못한 응답을 알아차리고 조정할 수 있다. 무인 프로세스는 같은 예외 상황을 명시적으로 처리해야 한다.

엔드포인트 관리 기능은 재사용 가능한 구성을 유지하는 더 구체적인 문제를 다룬다. 등록하면 서비스를 다시 선택하기 쉬워진다. 그렇다고 그 서비스가 이전에 다른 모델을 통해 실행한 모든 명령에 적합하다는 의미는 아니다.

이 때문에 OpenAI 호환 경로를 제공업체 결정으로부터의 독립성과 혼동해서는 안 된다. 공통 클라이언트도 선택한 서비스의 가용성, 지원 기능, 요청 해석에 여전히 의존한다.

따라서 이번 릴리스는 유용한 중간 지대를 강화한다. 개발자는 워크플로의 일부를 표준화하면서 개별 백엔드에는 의도적인 예외를 유지할 수 있다. 이 접근 방식은 어떤 가정이 공통이고 어떤 가정이 여전히 제공업체별인지를 아는 데 달려 있다.

모델 전환은 통제된 기능으로 다룰 때 가장 잘 작동한다. 이를 자동적인 동등성으로 취급하면 개발자가 평가하려는 바로 그 차이를 지우게 된다.

타입이 지정된 임베딩이 미디어 차이를 드러낸다

더 많은 입력 유형을 지원하면, 모델이 수치 변환을 수행하더라도 주변 데이터 처리가 더 중요해진다.

Willison은 첨부 파일 변경의 이유로 Gemini Embedding 2를 언급한다. Google은 텍스트, 이미지, 비디오, 오디오, 문서를 공유 수치 공간 안에서 표현하는 멀티모달 임베딩을 설명한다.

멀티모달은 시스템이 텍스트와 이미지처럼 서로 다른 형태의 입력을 처리한다는 의미다. Google은 그 공유 공간을 이러한 형태 전반에서 의미를 비교하는 방법으로 제시한다.

텍스트 전용 검색과의 차이는 구체적이다. 텍스트 쿼리는 원본 항목에 정확한 쿼리 단어가 포함되어 있지 않아도 관련 미디어를 찾을 수 있다. 유용한 결과를 검색하는지는 여전히 모델과 컬렉션에 달려 있다.

Google의 제품 페이지에는 미디어 및 법률 기술 조직의 고객 계정이 포함되어 있습니다. 이들 계정은 다양한 미디어 유형에서 관련 자료를 찾는 데 관심이 있다고 설명합니다. 이는 수요의 사례를 보여 주는 것이지, LLM의 구현을 독립적으로 검증하는 것은 아닙니다.

llm 0.37에서 더 좁은 범위의 개발 사항은 입력 처리입니다. 첨부 파일의 유형을 보존하면 통합 기능이 지원되는 콘텐츠를 올바르게 라우팅하는 데 필요한 정보를 얻을 수 있습니다. 이는 검색 품질 향상의 증거라기보다, 성능 좋은 모델을 활용하기 위한 인프라입니다.

인터뷰 메모, 화면 녹화, 스크린샷이 포함된 가상의 제품 리서치 아카이브를 생각해 봅시다. 혼란스러운 인터페이스에 관한 질의와 관련된 근거는 이들 자료 어느 곳에나 있을 수 있습니다.

매력적인 약속은 아카이브 전체를 대상으로 하는 단일 검색 경험입니다. 하지만 운영상 요구 사항은 더 구체적입니다. 각 항목이 무엇이며 어디에서 왔는지를 보존해야 합니다.

유용한 검색 결과는 사용자가 직접 검토할 수 있는 근거로 돌아갈 수 있게 해야 합니다. 수치적 유사도 점수만으로는 스크린샷의 맥락을 설명할 수 없습니다. 관련 녹화물 역시 독자가 필요로 하는 정확한 시점을 자동으로 알려 주지는 않습니다.

이 기능이 작게 들리더라도 유형이 지정된 첨부 파일에 주목할 가치가 있는 이유가 여기에 있습니다. 미디어 간 차이는 원본 자료에서 모델 입력으로, 다시 사용할 수 있는 결과로 이어지는 과정 내내 유지되어야 합니다.

유형 정보가 모든 단계를 해결해 주지는 않습니다. 개발자는 여전히 콘텐츠를 어떻게 나눌지, 출처 참조를 어떻게 보존할지, 결과를 사용자에게 어떻게 보여 줄지 결정해야 합니다.

긴 녹화물을 더 작은 단위로 나누면 검색 시스템이 반환할 수 있는 결과가 달라집니다. 파일 수준의 참조만 유지하는 것은 관련 구절이나 시점을 반환하는 것과 다른 경험을 만듭니다.

이러한 선택은 평가에도 영향을 줍니다. 검색 시스템은 질의와 관련된 무언가를 반환할 수 있지만, 그것을 해결하는 근거를 반환하지 못할 수도 있습니다. 팀에는 이 차이가 중요한 사례가 필요합니다.

개인 아카이브에서는 느슨하게 관련된 일치 항목도 여전히 유용할 수 있습니다. 공유 리서치 워크플로에서는 독자가 질의, 검색된 항목, 그리고 그로부터 도출된 결론 사이의 더 명확한 연결을 필요로 할 수 있습니다.

이번 릴리스는 인터페이스 수준에서 더 풍부한 입력을 위한 여지를 마련합니다. 다음 엔지니어링 과제는 이러한 입력을 둘러싸고 있습니다. 즉, 맥락 보존, 검색 결과 검증, 그리고 그 결과로 얻은 근거를 이해하기 쉽게 만드는 일입니다.

이는 다른 형태로 표현한 핵심 상충 관계입니다. 더 많은 콘텐츠가 공유 도구를 통해 접근 가능해지는 반면, 의미 있는 결과에 대한 책임은 애플리케이션에 남습니다.

신뢰성 수정으로 더 쉬운 접근성의 약속을 보완하다

성공적인 모델 응답은 신뢰할 수 있는 워크플로의 일부일 뿐입니다. 주변 소프트웨어 역시 제어, 저장소, 실패를 올바르게 처리해야 합니다.

릴리스 노트에는 로깅, 도구 실행, 임베딩 저장소와 관련된 수정 사항이 포함되어 있습니다. 이 세부 사항들은 애플리케이션이 모델의 답변 주변에서 무엇을 신뢰할 수 있는지와 관련되므로 주목할 필요가 있습니다.

도구 호출은 모델이 소프트웨어에 함수를 실행해 달라고 요청하는 것입니다. 애플리케이션은 그 요청이 어떻게 행동으로 이어질지 결정합니다. 따라서 해당 실행을 둘러싼 제어 검사는 모델이 올바른 함수를 제안하는 능력과는 별개의 문제입니다.

이번 릴리스는 거부된 도구 호출이 여전히 실행되던 경로를 수정합니다. 또한 로깅이 비활성화된 상태에서도 계속되던 채팅 로깅 문제를 해결합니다. 이는 문서화된 수정 사항이지, 완전한 보안 또는 개인정보 보호 감사를 입증하는 증거는 아닙니다.

또 다른 수정 사항은 모델이 잘못된 수의 결과를 반환할 경우 임베딩 작업이 배치를 거부하도록 합니다. 이전에는 이러한 불일치로 인해 행이 손실되거나 벡터와 식별자 간 연결이 잘못될 위험이 있었습니다.

분석상 중요한 점은 실패를 처리하는 방식입니다. 명시적 오류는 애플리케이션이 중단, 재시도 또는 주의 요청을 할 기회를 제공합니다. 잘못된 연결을 지닌 채 겉보기에는 성공한 작업은 감지하기가 더 어려울 수 있습니다.

지식 애플리케이션에서 출처의 정체성은 근본적입니다. 잘못된 문서에 연결된 그럴듯한 결과는 독자가 이를 확인할 능력을 약화시킵니다. 더 나은 언어 생성도 사후에 그 연결을 복구할 수는 없습니다.

같은 원칙은 중단된 작업에도 적용됩니다. 워크플로는 완료된 단계와 시도된 단계, 기록된 결과와 누락된 결과를 구분해야 합니다. 그렇지 않으면 다음 프로세스는 무슨 일이 있었는지 불분명한 기록을 물려받게 됩니다.

이는 LLM에만 국한된 단점이 아니라 일반적인 엔지니어링 요구 사항입니다. 이러한 내용이 릴리스에 등장한 것은 사용 사례가 다양해짐에 따라 통합 라이브러리가 어느 부분에서 유지보수를 필요로 하는지 보여 줍니다.

AI 지원 기여에 대한 Willison의 설명은 또 다른 관점을 더합니다. 그는 12명의 작성자가 수정 사항을 제공했으며, 거의 모두 AI 지원을 사용했다고 말합니다. 그는 이러한 기여를 검토하는 일이 예상보다 부담이 적었다고 전합니다.

그의 설명은 트리아지, 즉 보고를 분류하고 어떤 항목이 주목할 가치가 있는지 결정하는 과정에 중점을 둡니다. 그는 AI를 활용해 유용한 수정을 식별하고, 제출된 패치를 받아들이는 대신 때로는 자신의 구현을 작성합니다.

이 설명은 구체적인 관찰을 뒷받침합니다. AI 지원 제출물은 그의 검토 프로세스 안에서 유용한 자료를 제공할 수 있습니다. 그렇다고 다른 유지관리자도 같은 업무량을 겪거나 똑같이 유용한 기여를 받는다는 사실이 입증되는 것은 아닙니다.

발표에는 검토 시간, 회귀율 또는 유지보수 결과에 대한 통제된 비교가 없습니다. 회의적인 해석은 릴리스에 포함된 구체적 수정 사항을 인정하면서도 이 한계를 유지해야 합니다.

기여자에게 시사점은 실용적입니다. 제안된 코드가 검토 과정에서 크게 바뀌더라도, 명확한 재현 방법과 잘 정의된 실패 조건은 여전히 가치가 있습니다.

사용자에게 시사점은 다시 워크플로의 소유권으로 돌아갑니다. 신뢰는 관찰 가능한 동작과 작업에 부합하는 검사에 기반해야 합니다. 패치의 출처만으로 애플리케이션이 그것에 의존해야 하는지 판단할 수는 없습니다.

llm 0.37 이후 주목할 점

유용한 후속 신호는 새로 사용 가능한 모델의 수가 아니라 호환성, 검색 품질, 유지보수 결과와 관련됩니다.

앞으로 몇 달간 첫 번째 신호는 개발자가 실제로 사용하는 서비스 전반에서 엔드포인트 관리가 얼마나 잘 유지되는지입니다. 구체적인 보고는 작업, 예상 동작, 관찰된 결과를 식별해야 합니다.

기본적인 텍스트 생성은 출발점일 뿐입니다. 애플리케이션은 지원되지 않는 옵션, 인증 실패, 중단된 응답, 대화 처리 방식의 차이도 마주합니다. 이러한 사례를 다루는 문서와 수정은 공유 인터페이스의 실질적 가치를 강화할 것입니다.

반대 신호는 어떤 조합이 지원되는지를 둘러싼 반복적인 모호성일 것입니다. 사용자가 같은 제한 사항을 계속 다시 발견해야 한다면, 더 단순한 등록 방식은 통합 부담의 상당 부분을 해결하지 못하게 됩니다.

이는 모든 백엔드가 동일한 기능을 제공해야 한다는 뜻은 아닙니다. 명확한 경계는 그 자체로 가치가 있습니다. 문서화된 제한 사항은 개발자가 가정에 기반한 의존성을 구축하기 전에 적절한 경로를 선택할 수 있게 합니다.

두 번째 신호는 임베딩 통합에서 유형이 지정된 첨부 파일이 유용하게 채택되는지입니다. 지원 선언도 중요하지만, 작동하는 사례는 그에 따른 검색 동작이 사용자를 검토 가능한 출처와 어떻게 연결하는지 보여 줘야 합니다.

설득력 있는 사례는 컬렉션을 정의하고, 질의 작업을 설명하며, 관련 자료가 어디에 나타나는지 보여 줄 것입니다. 또한 관련 콘텐츠가 올바른 근거와 경쟁하는 까다로운 사례도 포함해야 합니다.

그러한 근거는 더 풍부한 첨부 파일 처리가 추가 파일 형식을 수용하는 수준을 넘어 애플리케이션에 이점을 준다는 주장을 강화할 것입니다. 모델이 그럴듯한 수치 결과를 반환하더라도, 출처 맥락을 보존하지 못하는 실패가 반복된다면 그 주장은 약화될 것입니다.

개발자는 모델 시연과 애플리케이션 평가도 구분해야 합니다. 전자는 기능이 존재함을 보여 줍니다. 후자는 그 기능이 특정 독자가 작업을 완료하는 데 도움이 되는지를 보여 줍니다.

세 번째 신호는 AI 지원 유지보수의 지속성입니다. Willison의 경험은 그가 설명한 한계 안에서는 고무적입니다. 다음으로 유용한 근거는 승인된 변경 사항이 이후 개발 과정에서도 이해 가능하고 신뢰할 수 있는 상태로 유지되는지에 관한 것입니다.

후속 수정이 자동으로 부정적인 신호가 되는 것은 아닙니다. 소프트웨어 유지보수에는 실수를 발견하고 수정하는 일이 포함됩니다. 더 드러나는 질문은 보고가 재현 가능한지, 실패에 명확한 설명이 제공되는지, 수정이 반복되는 불확실성을 줄이는지에 관한 것입니다.

이 관점은 기여량을 프로젝트 건전성의 완전한 척도로 보는 일을 피합니다. 더 많은 코드가 제출된다고 해서 유지관리자가 더 많은 실질적 역량을 확보했다는 뜻은 아닙니다. 가치는 문제를 이해하고 동작을 개선하는 데 있습니다.

이 릴리스를 고려하는 독자에게 즉각적인 결정은 비례적입니다. 전체 업데이트를 해당 작업을 재설계할 이유로 보기 전에, 기존 작업에서 어떤 변경이 중요한지 식별해야 합니다.

모델을 실험하는 개인은 구성 편의성을 가장 중요하게 여길 수 있습니다. 반복 작업을 운영하는 팀은 명시적 선택과 신뢰할 수 있는 기록을 더 중시할 수 있습니다. 검색 개발자는 미디어 처리와 출처 보존에 초점을 맞출 수 있습니다.

llm 0.37을 이미 이해하고 있는 워크플로를 살펴보는 계기로 활용하세요. 대표적인 입력을 선택하고, 의도한 모델을 기록하며, 허용 가능한 결과에 반드시 포함되어야 할 내용을 정의하세요. 역할을 확대하기 전에 후보 출력물을 그 기준과 비교하세요. 검색에서는 생성된 답변에만 의존하지 말고 검색된 출처를 검토하세요. 자동화된 작업에서는 거부와 중단이 다음 단계에 어떤 영향을 미치는지 살펴보세요. 결과를 사용하는 사람들과 가까운 곳에서 평가를 유지하세요. 그들의 요구 사항이 더 쉬운 전환이 유용한 유연성을 만들어 내는지 결정하기 때문입니다. 워크플로의 어느 부분이 더 많은 선택지의 혜택을 받고, 어느 부분에 더 명시적인 의존성이 필요한가요?