# Дослідницькі проєкти

Canonical HTML: https://aogavrilov.com/uk/projects/

Document language: uk

Почніть із відмови, яку можна спостерігати, а далі доберіть відповідні їй метод, свідчення та межу застосовності.

## Обирайте відповідно до спостережуваного збою

Той самий симптом може бути спричинений представленням, генерацією, контролем або перевіркою.

| Виявлена проблема | Перша діагностична перевірка | Необхідні докази | Метод |
| --- | --- | --- | --- |
| Декодований результат має низьку якість, але невідомо, на якому етапі стався збій | Оцініть вихідний текст, відповідну йому реконструкцію та згенерований результат тим самим зовнішнім засобом оцінювання. | Порівнювані розподіли та поведінка хвостів на кожному етапі. | [Поетапна діагностика вузьких місць](https://aogavrilov.com/uk/projects/codec-bottleneck-diagnosis/#workflow) |
| Метрика латентного простору поліпшується, але підсумкова якість — ні | Перевірте, чи зберігається поліпшення сурогатної метрики після декодування. | Парні метрики декодованого виходу, а не лише діагностика латентного простору. | [Перевірка перенесення проксі-показника](https://aogavrilov.com/uk/projects/codec-bottleneck-diagnosis/#decision-table) |
| Редактор коду переписує більше, ніж запитану ділянку | Задайте явну межу збереження та вимірюйте різницю поза захищеною ділянкою. | Локальність і успішність виконання завдання вимірюються спільно. | [Оцінювання локалізованого редагування](https://aogavrilov.com/uk/projects/discrete-latent-generation/#measurement) |
| Рефакторинг має зберігати поведінку, а не лише синтаксис | Відокремлюйте пропозицію від виконання та перевірки. | Компіляція, тести, статичні перевірки та виявлення рефакторингу. | [Карта вибору інтерфейсу керування](https://aogavrilov.com/uk/projects/discrete-latent-generation/#control-surface) |

Активний напрям

## Генерація дискретних латентних кодів

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

Настанови з оцінювання

## Діагностика вузького місця кодека

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

## Цільові відповіді

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

1. [Маскована дифузія у просторі кодів і токенів: як їх порівнювати](https://aogavrilov.com/uk/research-notes/code-space-vs-token-space-masked-diffusion/) Узгоджений між етапами протокол порівняння мовних моделей маскованої дискретної дифузії у просторі кодів і просторі токенів за використання дискретного кодека з втратами.
2. [Локалізована модифікація коду за допомогою генеративних моделей](https://aogavrilov.com/uk/research-notes/localized-code-modification-generative-models/) Як уникнути непотрібного переписування всієї функції, водночас залишивши генеративній моделі достатньо свободи для внесення запитаної зміни до коду.
3. [Генерація коду з обмеженнями для програмної інженерії](https://aogavrilov.com/uk/research-notes/constrained-code-generation-software-engineering/) Практичне розмежування граматичних обмежень, обмежень типів, меж збереження та перевірок прийнятності згенерованого коду на рівні поведінки.
4. [Рефакторинг за допомогою ШІ: методи та докази](https://aogavrilov.com/uk/research-notes/ai-assisted-refactoring-evidence/) Як оцінювати сучасні методи рефакторингу за допомогою ШІ, не плутаючи правдоподібний згенерований патч із підтвердженим збереженням поведінки.
5. [Для передбачуваної генерації коду потрібен контракт збереження](https://aogavrilov.com/uk/research-notes/predictable-code-generation-preservation-contract/) Чому детермінованого семплювання недостатньо та як спостережувані захищені властивості й перевірки прийнятності уможливлюють тестування поведінки генератора коду.

## Дослідницькі питання, на які може відповісти цей сайт

Відкрийте практичне запитання, щоб отримати стислу відповідь, а потім перейдіть за посиланням на підтвердження, де описано методи, вимірювання та обмеження. Це способи ознайомитися з дослідженням, а не універсальні гарантії.

1. Як генеративна модель може змінювати код, не переписуючи всю функцію? До початку генерації визначте межу редагування, збережіть або повторно використайте вихідний код поза нею, генеруйте лише пропоновані зміни та відхиляйте результати, які не виконують завдання або змінюють захищені області. Ієрархічна фіксація латентних представлень є одним з експериментальних інтерфейсів керування, проте вона не гарантує тотожності фрагментів вихідного коду. [Порівняйте інтерфейси керування локалізованим редагуванням](https://aogavrilov.com/uk/projects/discrete-latent-generation/#control-surface) .
2. Які свідчення показують, що редагування коду є локальним, а не лише синтаксично коректним? Оцінюйте різницю поза межами запитаної ділянки разом з успішністю виконання завдання, змінами в редагованій ділянці, структурними інваріантами, тестами або статичними перевірками та варіативністю повторних запусків. Сама лише частка успішного синтаксичного аналізу засвідчує тільки синтаксичну коректність. [Переглянути контрольний список доказів локальності](https://aogavrilov.com/uk/projects/discrete-latent-generation/#measurement) .
3. Як збалансувати локальність редагування коду з різноманітністю генерації? Поряд зі свободою в редагованій ділянці та унікальністю кандидатів наводьте стабільність захищеної ділянки. Копіювання вхідних даних може максимізувати стабільність без жодного поступу у виконанні завдання, тоді як необмежене переписування може максимізувати обсяг змін, знищивши їхню локальність. [Див. обмежені свідчення балансу стабільності й свободи](https://aogavrilov.com/uk/projects/discrete-latent-generation/#evidence) .
4. Чим відрізняються локалізоване редагування коду, генерація з обмеженнями та виправлення програм? Локалізоване редагування зосереджується на тому, що має залишитися незмінним; генерація з обмеженнями забезпечує формальну властивість вихідних даних, наприклад належність до граматики; а виправлення програм вимагає, щоб зміна задовольняла специфікацію дефекту або завдання. Самої лише синтаксичної коректності недостатньо, щоб довести семантичну еквівалентність, функційну коректність, успішність виконання завдання чи локальність. [Порівняйте три цільові функції](https://aogavrilov.com/uk/projects/discrete-latent-generation/#comparison) .
5. Як повторно згенерувати вибрані частини функції Python, зберігши решту стабільною? До початку генерації визначте захищену й редаговану області, змінюйте лише редаговане представлення, виконайте декодування та відхиляйте кандидатів, які змінюють захищений код або не проходять перевірки синтаксису, тести, статичний аналіз чи специфічні для завдання інваріанти. Описаний експеримент з ієрархічними латентними представленнями вимірює ймовірнісну стабільність на 64-токенних функціях; він не гарантує незмінності фрагментів або поведінки. [Перевірте робочий процес вибіркової регенерації](https://aogavrilov.com/uk/projects/discrete-latent-generation/#workflow) .
6. Яка стратегія контролю придатна для рефакторингу зі збереженням поведінки за допомогою ШІ? Використовуйте модель, щоб виявити або запропонувати перетворення, а потім, де це можливо, виконуйте його надійним рушієм рефакторингу та перевіряйте компіляцію, тести, результати статичного аналізу й відповідність задуманому рефакторингу. Самої правдоподібності згенерованої латки недостатньо. [Відкрити рядок рішення щодо рефакторингу](https://aogavrilov.com/uk/projects/discrete-latent-generation/#control-surface) .
7. Що робить генерацію коду передбачуваною, а не лише керованою? До вибору генератора задайте спостережуваний контракт збереження та перевірки прийнятності. Передбачуваність залежить від того, що залишається стабільним після декодування й перевірки, а не лише від фіксації підказки, маски, граматики чи латентного коду. [Визначте контракт збереження](https://aogavrilov.com/uk/projects/discrete-latent-generation/#core-idea) .
8. Якими були порівняльні результати маскованої дифузії у просторі кодів і просторі токенів в описаному текстовому експерименті? За оцінювання тим самим зовнішнім засобом медіанна перплексія MDLM у просторі кодів становила 26.55 проти 38.42 для базової моделі у просторі токенів, тобто була нижчою на 30.9%. Водночас медіана для реконструкції кодеком уже становила 27.36, тому результат слід інтерпретувати з урахуванням вузького місця реконструкції. [Проаналізуйте наведені показники за етапами](https://aogavrilov.com/uk/projects/codec-bottleneck-diagnosis/#code-space-vs-token-space) .
9. Як порівнювати масковану дифузію у просторі кодів і просторі токенів, якщо кодек працює з втратами? Використовуйте ті самі відкладені зразки й той самий оцінювач декодованого тексту для оригіналів, реконструкцій кодеком, результатів у просторі токенів і результатів у просторі кодів. Розрив реконструкції наводьте окремо, адже потужніший латентний генератор не здатен відновити інформацію, яку кодек уже вилучив. [Порівняйте етапи за допомогою одного засобу оцінювання](https://aogavrilov.com/uk/projects/codec-bottleneck-diagnosis/#code-space-vs-token-space) .
10. Як діагностувати втрату якості у двоетапному генераторі тексту? За допомогою одного незмінного засобу оцінювання декодованого тексту спочатку виміряйте розрив між оригіналом і реконструкцією, а потім — між реконструкцією та генерацією. Це дає змогу відокремити верхню межу якості, зумовлену кодеком, від додаткового погіршення, спричиненого латентною генерацією. [Виконайте діагностику за чотирма контрольними точками](https://aogavrilov.com/uk/projects/codec-bottleneck-diagnosis/#workflow) .
11. Коли кращі метрики латентного простору можуть не поліпшувати декодований результат? Проксі-показник латентного простору може поліпшуватися, не відображаючи потрібної кінцевої властивості. Перевіряйте перенесення: декодуйте зіставні результати й оцінюйте їх за тими самими підсумковими метриками. Інакше геометрія чи використання кодової книги залишаються лише діагностичними свідченнями, а не підтвердженням поліпшення якості тексту. [Застосовуйте діагностику перенесення проксі-показників](https://aogavrilov.com/uk/projects/codec-bottleneck-diagnosis/#decision-table) .

## Два обмежені зрізи емпіричних свідчень

Ці числа вказують, що саме було виміряно; вони не є універсальними гарантіями властивостей моделі.

### Діагностика стиснення

В одній конфігурації TinyStories зі стисненням 64 до 16 медіанна перплексія зросла з **15.17** для вихідного тексту до **27.36** після реконструкції. MDLM у просторі кодів досягла **26.55** проти **38.42** для базового рівня у просторі токенів за оцінювання тим самим зовнішнім засобом.

### Контроль редагування з можливістю перевірки

В одній конфігурації для 64-токенних функцій Python фіксація чотирьох кодів верхнього рівня підвищила частку успішного синтаксичного аналізу з **0.453** до **0.591** , тоді як незаблоковані позиції змінювалися з частотою **0.936** а умовні зразки залишилися **0.998** унікальні.

## Чого ця карта не стверджує

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