GLM 5.3 у Dikaya: перевірка договору з додатками

Мінімальний API-приклад

Ілюстративний Python-код, не виконана відповідь моделі. Ключ береться з оточення, автоматичні повтори вимкнені. Втрата зв’язку може залишити результат і витрати невідомими: не повторюйте запит наосліп.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-glm-5-3",
    max_tokens=512,
    messages=[{"role": "user", "content": "Склади перевірний список для мого завдання. Відокрем факти від припущень."}],
)
print(response.choices[0].message.content)

Складіть паспорт договірного пакета

Зазначте основний договір, специфікацію, графік робіт і правила приймання як окремі документи. Для кожного запишіть дату, редакцію та статус: погоджено, проєкт або довідковий матеріал. Підписаний додаток і чернетка листа не повинні отримати однакову вагу через сусідство у повідомленні. На початку запиту поясніть, що саме перевіряється: обсяг обслуговування, межі відповідальності та умови підтвердження виконаних робіт.

Якщо в пакеті відсутнє правило пріоритету, попросіть позначити це прогалиною. Не дозволяйте автоматично зробити специфікацію головнішою за основний текст або навпаки. У робочій копії збережіть номери пунктів і таблиць, включно з примітками. Для зміненої редакції залиште окремий код документа, щоб цитата зі старої версії не виглядала підтвердженням нового формулювання після переговорів.

Розкладіть умови на перевірні зобов’язання

Для кожної дії виділіть виконавця, предмет, строк, умову початку та спосіб підтвердження. Фраза про обслуговування «за потреби» не визначає ні максимальний час реагування, ні того, хто повідомляє про потребу. Попросіть модель не заповнювати ці поля за звичаєм галузі. Відсутнє значення має залишитися питанням до сторін із посиланням на відповідний абзац, а не непомітною редакторською поправкою.

Окремо перевірте взаємні залежності. Виконавець може починати роботи після доступу до об’єкта, але замовник отримує право вимагати результат лише після іншої події. У таблиці потрібні обидві умови та зв’язок між ними. Потім звірте назви обладнання в договорі, специфікації й акті: схожі скорочення не завжди означають той самий комплект, а вилучена позиція може змінити весь обсяг обов’язків.

Читайте винятки поряд із основним правилом

Умову про відповідальність не можна оцінити лише за абзацом із загальним правилом. Перевірте винятки, обмеження суми, порядок повідомлення та строки заявлення вимог. Попросіть для кожного винятку вказати, яке саме зобов’язання він змінює. Якщо посилання веде на відсутній пункт, це окрема знахідка. Модель не повинна реконструювати зміст пропущеного додатка зі схожих договорів або власних очікувань.

Для графіка обслуговування порівняйте календарні періоди, святкові дні та поняття аварійного виїзду. Загальна доступність підтримки не дорівнює виїзду спеціаліста на місце. Попросіть створити короткі умовні сценарії для перевірки формулювань, але чітко називати їх вигаданими прикладами застосування, а не реальними спорами чи судовими рішеннями. Поверніть кожен сценарій до конкретних пунктів, які визначають можливі варіанти відповіді.

Керуйте effort окремо від обсягу звіту

Для seller-glm-5-3 задекларовано low, high і max. Вибір рівня не замінює чіткого запиту й не є доказом, що перевірено кожен додаток. Почніть з обмеженого завдання, наприклад карти строків, і визначте критерій приймання. Якщо порівнюєте різні налаштування, використовуйте той самий пакет документів і перевіряйте конкретні пропуски. Не робіть висновку про кращу якість лише з довшого часу очікування.

Ліміт відповіді та контекст є окремими величинами. Браузер має власні межі історії й розміру запиту; великий контекст моделі не доводить, що весь договір передано. Надто довгий звіт може обірватися до важливого додатка. Розділіть перевірку на тематичні проходи та ведіть список покриття. Для кожного проходу заздалегідь визначте, які документи й питання входять до нього, щоб не дублювати витрати без потреби.

Відокремлюйте текст договору від зовнішніх довідок

Платний браузерний пошук можна явно ввімкнути для пошуку довідкових матеріалів, але знайдена сторінка не стає умовою договору. У звіті мають бути окремі позначки для цитат пакета й зовнішніх джерел. Перевіряйте дату та сферу застосування довідки. Не приписуйте публічному API вбудований інтернет-пошук лише тому, що він є в браузерному продукті, і не видавайте згенерований висновок за перевірене юридичне роз’яснення.

Скановані сторінки для цієї моделі проходять через окремий оплачуваний Flash-міст у текстовий опис. Це не нативне читання зображень GLM. Перевірте точність перенесення приміток і нумерації до змістового аналізу. Зазвичай доцільніше підготувати контрольований текст, ніж розбирати довгий договір за фотографіями. Збережіть оригінали та позначте всі місця, де текст відновлено з нечіткого скану й потрібна ручна звірка.

Передайте людині список рішень, а не вердикт

Підсумковий реєстр має розрізняти знайдену суперечність, прогалину та редакційне уточнення. Додайте коротке пояснення практичного наслідку й відповідального за рішення. Наприклад, відсутність форми акта може затримати приймання, але це ще не висновок про недійсність договору. Фінальний огляд перевіряється по цитатах, а всі зміни погоджуються сторонами в контрольованій редакції з незмінними ідентифікаторами пунктів.

Перехід у чат залишає чернетку: перевірте модель, дозволи та попередньо збережений текст перед надсиланням. Демо не відкриває автоматично seller-glm-5-3. Для SDK задайте max_retries=0; мережевий обрив не дорівнює відомому HTTP-відхиленню й не доводить відсутності витрат. Спершу з’ясуйте стан операції, потім вирішуйте, чи потрібен новий ручний запит для конкретних неперевірених пунктів, а не повтор усього пакета.

Запитання й відповіді

Чи замінює такий аналіз остаточну перевірку договору?

Ні. Модель допомагає організувати цитати, залежності та запитання, але не підтверджує чинність документів, повноваження підписантів або правильність застосування норм. Відповідальна людина звіряє оригінали й ухвалює рішення. Практичний результат — простежуваний список проблем і погоджених змін, а не безумовний вердикт про безпечність підписання.

Що означає max для GLM 5.3?

max є одним із задекларованих рівнів effort саме seller-glm-5-3 поряд із low та high. Він не означає необмежений вихід, повну браузерну історію чи гарантовано правильний юридичний висновок. Плануйте явний ліміт відповіді та оцінюйте покриття пунктів окремо від обраного рівня й тривалості очікування.

Чому не варто просто надіслати фотографії всіх сторінок?

GLM отримує опис зображень через окремий оплачуваний міст, а не працює з ними нативно. У такому перенесенні можуть загубитися примітки, таблиці та перехресні посилання. Для договору підготуйте перевірений текст і збережіть нумерацію, а нечіткі місця позначте для ручного читання оригіналу до змістового висновку.

Як перевірити, що жоден додаток не пропущено?

До запиту створіть паспорт пакета з назвами, редакціями та номерами частин. У відповіді вимагайте перелік фактично опрацьованих документів і непокритих питань. Потім зіставте його з паспортом. Великий заявлений контекст і впевнений підсумок не замінюють цієї звірки та не підтверджують передачу всіх матеріалів клієнтом.

Джерела

Матеріал підготовлено за допомогою AI. Приклади ілюстративні, а не записи справжніх відповідей чи порівняльних тестів. Зовнішні джерела не замінюють умов сервісу.

• Каталог Dikaya: GLM 5.3 та параметри моделі
  dikaya.cc
• Документація Dikaya: робочі межі браузера й API
  dikaya.cc
• OpenAI Python: контроль повторів і помилок SDK
  github.com
• MDN: читання HTTP-відповіді й скасування Fetch
  developer.mozilla.org