Як формувати запит для критичного аналізу

Щоб змусити інструмент ШІ розкрити логіку вашої аргументації, необхідно явно призначити йому роль скептика та заборонити узагальнювати чи полірувати ваш текст. Це досягається за допомогою структур запитів, які змушують модель займати протилежну позицію, виділяючи конкретні логічні хиби та необґрунтовані припущення, а не просто покращуючи прозу.

Чому типові відповіді не працюють

Типові відповіді ШІ мають тенденцію погоджуватися або узагальнювати, оскільки базові моделі навчені бути корисними та розмовними. Коли ви вставляєте аргумент у чат без конкретних інструкцій, інструмент переходить у режим співпраці. Він визначає головну думку, перефразує її для ясності та, можливо, пропонує незначні стилістичні покращення. Така поведінка корисна для редагування, але марна для логіки. Модель не знає, що ви хочете, щоб вона знайшла тріщини у ваших міркуваннях; вона вважає, що вам потрібне підтвердження або вдосконалення. Як наслідок, результат часто відображає ваші власні упередження, підсилюючи аргумент, а не перевіряючи його. Щоб отримати критичний аналіз, потрібно перевизначити цю типову співпрацюючу позицію за допомогою явних опозиційних інструкцій.

Структури запитів для скептицизму

Щоб змусити зайняти скептичну позицію, використовуйте структури запитів, які визначають конкретну протилежну роль. Замість питання «Чи гарний цей аргумент?» попросіть інструмент діяти як конкретний тип критика. Наприклад, змусьте модель діяти як формальний логік, чиє єдине завдання — виявляти логічні хиби та прогалини в міркуваннях у вашій аргументації. Таке формулювання знімає тиск бути ввічливим або корисним у загальному сенсі. Також можна використовувати запити з рольовою грою, які надають ШІ перспективу конкретного опонента, наприклад, рецензента, відомого суворими стандартами, або філософа, що спеціалізується на епістемології.

Ще одна ефективна структура — підхід «steel-man, а потім критика». Попросіть інструмент спершу сформулювати найсильнішу можливу версію вашого аргументу, а потім розібрати цю найсильнішу версію. Це не дозволить ШІ атакувати слабку, солом’яну версію вашої тези. Ви повинні явно заборонити моделі узагальнювати текст. Включіть у запит негативну обмежувальну умову, наприклад: «Не узагальнюй аргумент. Не переписуй текст. Визнач лише логічні слабкості». Це змусить результат зосередитися на структурі та валідності, а не на змісті чи стилі.

Ізоляція хиб і припущень

Техніки ізоляції логічних хиб і необґрунтованих припущень вимагають розкладання аргументу на складові частини. Не вставляйте довгий есе й не просіть критикувати його цілком. Натомість виділіть основну логічну структуру. Ви можете використовувати QuillBot для парафразування або узагальнення вашого аргументу до його чистої логічної основи, позбувшись риторичних прикрас. Коли ви отримаєте цю спрощену версію, подайте її ШІ з інструкцією визначити кожну засновку та висновок. Попросіть інструмент перелічити кожну засновку та визначити, чи підтверджується вона доказами, чи просто стверджується.

Щоб виявити хибні міркування, попросіть ШІ перевірити наявність конкретних поширених помилок, таких як ствердження наслідку, тавтологія або non sequitur. Ви також можете попросити його визначити неявні припущення. Для кожного висновку, який ви робите, запитайте інструмент: «Що має бути істинним, щоб цей висновок випливав із цих засновок?» Це підкреслює приховані припущення, які ви могли пропустити. Якщо ви працюєте зі складними, багаторівневими аргументами, можна звернутися до можливостей розширеного мислення Claude для глибокого аналізу структурних слабкостей і неявних припущень, що охоплюють кілька абзаців. Це дозволяє моделі відстежувати залежності між віддаленими частинами вашого аргументу, які простий лінійний перегляд може пропустити.

Ітерація щодо критики

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

Під час цієї ітерації можна використовувати різні інструменти для різних етапів процесу. Якщо ваш аргумент спирається на фактичні засновки, зверніться до Perplexity, щоб перевірити логічну узгодженість цих засновків із цитованими джерелами, гарантуючи, що ваші фактичні твердження мають підґрунтя. Якщо ваш аргумент є частиною більшого документа чи презентації, зверніться до Microsoft Copilot, щоб оцінити логіку безпосередньо в робочому процесі, що дозволить побачити, як аргумент функціонує в контексті. Якщо ваш аргумент містить мультимодальні елементи, такі як діаграми чи схеми, зверніться до Gemini, щоб оцінити аргумент одночасно в текстовому, графічному або відеоформатах. Якщо ваші нотатки зберігаються в базі даних, зверніться до Notion AI, щоб проаналізувати збережені аргументи на наявність внутрішніх суперечностей. Зверніться до Grammarly, щоб виявити структурні неоднозначності, які знижують точність аргументу, гарантуючи, що ваші логічні твердження не розмиваються через незрозумілий синтаксис.

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