독일어 API 비교: 유효한 JSON, 정확한 책임 소재, 변경 사항 및 찾아볼 수 있는 출처.
과제 앱은 'Clara가 표를 맡는다'라는 내용을 신뢰할 수 있는 필드로 만들어야 합니다. 하지만 동시에 'Ben이 시범 운영을 맡을 수도 있다'는 내용이 아직 할당된 것이 아님을 인식해야 합니다. 이 경우, 어떤 모델이 더 유용한 데이터를 제공할까요? DeepSeek V4-Flash일까요, 아니면 GPT-6 Sol일까요?
저는 두 가지 가상의 독일어 메모 시퀀스(office project와 학습 그룹)를 테스트했습니다. 두 모델 모두 JSON을 출력하고 이후 새로운 결의안을 통합하도록 했습니다. 추가적인 실행에서는 더 정확하게 정의된 필드를 사용했습니다. 결과적으로 도출된 과제 필드와 그 근거들을 비교했습니다.
📊 과제 앱에 대한 결과
| 테스트 | DeepSeek V4-Flash | GPT-6 Sol |
|---|
JSON.parse로 직접 읽기 가능 | 평가된 답변 6/6 | 평가된 답변 6/6 |
| ... | | |
| 클릭 가능한 원본 근거가 있는 앱의 경우, 저는 이 테스트에서 GPT-6 Sol을 선택할 것입니다. 사전에 검토된 과제 필드의 경우 DeepSeek V4-Flash도 후보입니다: 정교화 후 값은 모두 정확했고, 답변이 더 빨랐습니다. 3/8은 사실 비율이 아닌 직접적인 텍스트 검색에 관한 것입니다. | | |
DeepSeek V4-Flash vs GPT-6 Sol: Daten für eine Aufgaben-App
gpt-image-2로 생성된 컨셉 일러스트; 제품 인터페이스 아님.
동일한 입력, 즉시 사용 가능한 JSON
사무실 사례에는 다음과 같은 전체 메모 시퀀스가 포함되어 있었습니다:
노트지, 연도 2026년:
8월 10일: D1 데이터 테이블 — Anna, 제출일 10월 14일. D2 슬라이드 — Ben, 제출일 10월 16일. D3 라이브 데모 — 10월 18일; 발표자 미정.
10월 10일, 확정 수정: D1 데이터 테이블 — Clara, 제출일 10월 16일; 이전 담당자와 마감일은 대체됨. D3 라이브 데모 — 10월 21일; 발표자는 계속 미정. D2는 변경 없음.
...
요구된 형식은 tasks와 open_questions를 가진 객체였습니다. 각 과제는 id, owner, due, status, 그리고 evidence를 받았습니다. 할당되지 않은 사람은 null로 유지해야 했으며, 제안은 상태가 proposed여야 했습니다. 답변에는 마크다운 경계나 추가 설명 텍스트가 포함되어서는 안 되었습니다. 이 형식은 서버 측 JSON 스키마 모드로 강제된 것이 아니라 텍스트 지침을 통해 요구되었습니다.
두 모델 모두 후처리 없이 유효한 JSON을 제공했습니다. 두 모델 모두 D1의 담당자를 Clara로, 마감일을 10월 16일로, 그리고 D3의 마감일을 10월 21일로 채택했습니다. 어느 쪽도 Ben이 슬라이드 작업만 했다는 이유로 그를 발표자로 지정하지 않았습니다. D3의 경우 owner: null을 유지했습니다.
차이는 D2의 증거(evidence)에 있었습니다. DeepSeek은 처음에 단지 D2 변경 없음.만을 출력했습니다. GPT는 D2 슬라이드 — Ben, 제출일 10월 16일.을 인용했습니다. 둘 다 올바른 필드 값을 가지고 있었지만, 두 번째 발췌본만이 그 자체로 누가 그리고 언제부터 왔는지 보여주었습니다.
상태(Status)의 경우 처음에는 지침이 부정확했음
두 번째 사례는 학습 그룹에 관한 것이었습니다. Mira가 문헌 검토를 작성하고 Leon이 슬라이드를 작성해야 했습니다. 11월 16일에 발표가 예정되어 있었지만, 발표자는 미정했습니다. 실습 세션의 경우 Leon의 조건부 제안만 있었습니다.
DeepSeek은 처음에 발표를 proposed로 표시했고, GPT는 confirmed로 표시했습니다. 오직 제안된 실습 세션에 대해서 DeepSeek은 11월 15일을 due 날짜로 설정했고, GPT는 해당 필드를 비워두었습니다. 반면 사무실 사례에서는 두 모델 모두 시범 운영의 제안된 날짜를 채택했습니다.
원래 스키마는 status가 실행 여부를 의미하는지 아니면 전체 인력 계획을 의미하는지에 대해 충분히 설명하지 못했습니다. 마찬가지로, due 필드가 일정 제안까지 포함할 수 있는지 여부도 불분명했습니다. 따라서 이러한 차이는 명확한 모델 오류의 깔끔한 증거가 아닙니다. 애플리케이션은 그러한 값을 평가하기 전에 필드의 의미를 정의해야 합니다.
별도의 실행을 위해 두 모델 모두 전체 원래 메모와 동일한 정제 작업을 받았습니다:
status는 과제의 실행 여부를 설명하며, 배치 상태를 나타내지는 않습니다.
D3 또는 S3은 owner=null임에도 불구하고 확정(confirmed)입니다.
due는 확실하게 결정된 일정만 포함합니다.
...
그 후 두 모델 모두 8개 모든 과제에 대해 예상되는 ID, 인물, 일정 및 상태 값을 제공했습니다. 날짜 및 상태 규칙은 여기서 명시적으로 주어졌으며, 그 결과는 이러한 규칙의 실행을 입증할 뿐, 모호한 메모를 스스로 해결하는 능력을 증명하지는 못합니다.
누군가 나중에 과제를 맡게 되면 어떻게 될까요?
이 정제된 실행과 무관하게, 모든 원래 대화는 새로운 결정으로 이어졌습니다. 사무실 사례에서는 David가 10월 21일 데모를 맡았습니다. 연습 세션은 Anna와 함께 10월 19일로 결정되었습니다.
두 모델 모두 D3와 D4를 올바르게 업데이트하고, D1과 D2는 유지했으며, 열려 있던 질문들을 비웠습니다. 학습 사례에서도 두 모델 모두 발표의 새로운 배치와 연습 세션의 확정된 일정을 정확하게 구현했습니다.
이 두 가지 경우에서는 업데이트에 있어 품질 우위가 없었습니다. DeepSeek이 더 빨랐습니다: GPT 대비 3.37초 및 3.16초 대 4.71초 및 3.95초. 측정된 것은 네트워크, 게이트웨이, 생성을 포함한 전체 응답이었으며, 인간의 후속 작업에 대한 측정은 없었습니다.
동일한 과제 필드, 출처 증거를 위한 다른 가능성
정제된 실행(Im präzisierten Durchlauf)에서는 GPT의 8개 evidence 필드가 각각의 노트에서 연결된 문자열로 직접 발견되었습니다. DeepSeek의 경우 이 조건은 3개에 해당했습니다. DeepSeek은 다른 섹션의 문장 앞에 날짜 접두사를 붙이거나, 여러 출처의 진술을 …와 함께 결합하는 등의 방식을 사용했습니다.
DeepSeek의 학습 사례 예시:
S2 Folien — Leon, Abgabe 13. November. … S2 und S3 unverändert.
두 진술은 실제로 출처에 존재합니다. 하지만 생략 부호(Auslassungszeichen)를 포함한 전체 문자열이 그곳에 있는 것은 아닙니다. 따라서 source.indexOf(evidence)를 사용하는 간단한 '원본 보기' 버튼으로는 이를 찾을 수 없습니다.
Aufgabenfelder und direkte Auffindbarkeit der Quellenstellen im präzisierten Durchlauf
실제 API 응답 평가. 결합된 증거(Zusammengefügte Belege)는 여기에서 연속적으로 발견 가능한 발췌문으로 간주되지 않습니다. 따라서 그 내용이 틀렸다는 것을 의미하지는 않습니다.
추가 작업은 어디서 발생하는가?
| 앱이 처리해야 할 것 | DeepSeek V4-Flash | GPT-6 Sol |
|---|
| 정제된 규칙에 따른 과제 가져오기 | 검증된 사람, 날짜 및 상태 필드는 변경 없이 가져올 수 있었음 | 동일한 결과 |
| ... | | |
| 실제 과제 가져오기만으로는 정제된 테스트가 품질 면에서 우위를 보이지 못했습니다. 출처 보기의 경우 GPT가 더 쉽게 연결할 수 있는 발췌문을 제공했습니다. 이는 응답과 원본 텍스트를 기반으로 검증되었으며, 완전한 과제 앱은 작동하지 않았습니다. | | |
답변 속도는 어떠했는가?
[Antwortzeiten beider Modelle bei ursprünglicher Aufgabe, Aktualisierung und präzisen Feldregeln](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fuw6ctctz0v4006la9skf.png
모든 조합을 한 번씩 측정했습니다. 다른 사고 설정, 통계적 성능 순위 목록은 아닙니다.
🎓 학업과 💼 사무실: 어떤 비교가 선택에 도움이 될까요?
| 사용처 | 이 시나리오를 위한 저의 첫 번째 선택 | 이유 |
|---|
| 과제 계획 및 검증 가능한 원본 출처가 있는 학습 프로젝트 | GPT-6 Sol | 정교화된 학습 사례에서 올바한 필드와 네 개의 직접 찾을 수 있는 증거 |
| ... | | |
| 만약 앱이 단일 문자열 대신 여러 출처 목록을 지원해야 한다면, 이 다른 형식은 별도로 테스트되어야 합니다. 여기서 발견된 복합적인 증거들로부터 독일어 메모를 읽는 데 일반적인 결함은 도출할 수 없습니다. | | |
테스트 조건
테스트 날짜: 2026년 10월 10일. 11월의 일정은 가상의 시나리오에 속합니다. 입력 언어와 출력 언어 모두 독일어였습니다. thinking: {type: 'disabled'}를 사용한 deepseek-v4-flash와 공급업체 표준을 사용한 gpt-6-sol이 각각 max_tokens: 2400, 스트리밍 또는 도구 없이 사용되었습니다. 응답은 deepseek-v4-flash-0731 또는 gpt-6-sol로 명명되었으며, 상위 흐름 할당(Upstream assignment)은 독립적으로 확인되지 않았습니다. 평가된 모든 응답은 stop으로 끝났습니다.
평가된 12개의 호출에는 각 모델별로 두 가지 초기 사례, 두 가지 업데이트 및 두 가지 새로운 실행이 포함됩니다. '원본 메모'에 대한 모호한 표현에 대해 네 개의 추가 탐색적 응답은 표에 포함되지 않았으며, 이는 필드 명확화와 문서 상태 선택을 혼합했기 때문입니다. 따라서 정교화된 실행은 전체 출처로 새로 시작되었습니다. 안정성을 위한 반복 시리즈는 측정되지 않았으며, 최대 네 개의 요청이 동시에 실행되었습니다.
연결은 Crazyrouter를 통해 이루어졌습니다. 동일한 API 연결을 설정하려는 경우, Crazyrouter API 문서에서 엔드포인트와 인증 정보를 찾을 수 있습니다.
본 게시물은 Crazyrouter 관련 내용이며, AI의 도움을 받아 작성되었습니다. API 응답은 주어진 과제 값과 원문 텍스트를 비교하여 일치시켰습니다.