# Изследователски проекти

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

Document language: bg

Започнете от наблюдавания проблем, а след това проследете подходящите за него метод, доказателства и граници на приложимост.

## Избирайте според наблюдавания отказ

Един и същ симптом може да произтича от представянето, генерирането, контрола или проверката.

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

Активно направление

## Дискретно латентно генериране

Дискретни представяния за избирателно регенериране на код, съчетани с основан избор между ограничено генериране, подпомагано от ИИ рефакториране и предвидимо редактиране на код според наличните доказателства.

Ръководство за оценяване

## Диагностика на тясното място в кодека

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

## Фокусирани отговори

Самостоятелни бележки за доказателствата при по-широки търсения, които не започват със заглавие на статия. Всяка бележка препраща към съответната публикация и пълния ѝ текст.

1. [Маскирана дифузия в пространството на кодовете спрямо пространството на токените: как да ги сравним](https://aogavrilov.com/bg/research-notes/code-space-vs-token-space-masked-diffusion/) Съгласуван между етапите протокол за сравнение на маскирани дифузионни езикови модели в кодовото и токеновото пространство, когато дискретният кодек внася загуби.
2. [Локализирана промяна на код с генеративни модели](https://aogavrilov.com/bg/research-notes/localized-code-modification-generative-models/) Как да се предотврати ненужното пренаписване на цялата функция, като същевременно се запази достатъчно свобода генеративният модел да извърши поисканата промяна в кода.
3. [Ограничено генериране на код за софтуерното инженерство](https://aogavrilov.com/bg/research-notes/constrained-code-generation-software-engineering/) Практическо разграничение между граматични ограничения, ограничения на типовете, граници на запазване и проверки за приемане на генерирания код на равнище поведение.
4. [Рефакториране с помощта на ИИ: методи и доказателства](https://aogavrilov.com/bg/research-notes/ai-assisted-refactoring-evidence/) Как да се оценяват съвременните методи за рефакториране с помощта на изкуствен интелект, без правдоподобна генерирана кръпка да се бърка с проверено запазване на поведението.
5. [Предвидимото генериране на код изисква договор за запазване](https://aogavrilov.com/bg/research-notes/predictable-code-generation-preservation-contract/) Защо детерминираното извадково генериране не е достатъчно и как наблюдаемите защитени свойства и критериите за приемане позволяват поведението на генератора на код да бъде проверявано.

## Изследователски въпроси, на които този сайт може да отговори

Отворете практически въпрос за кратък отговор, след което последвайте връзката към доказателствата за методите, измерванията и ограниченията. Това са отправни точки към изследването, а не универсални гаранции.

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

## Два ограничени среза на доказателствата

Тези числа посочват какво е измерено; те не представляват универсални гаранции за модела.

### Диагностика на компресията

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

### Контрол върху редактирането с възможност за проверка

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

## Какво не твърди тази карта

Публикуваните експерименти не установяват точно запазване на AST, семантична еквивалентност, функционална коректност, поправяне в мащаба на хранилище или универсална подредба на тесните места в кодека и генератора. Ръководствата превръщат ограничените доказателства в повторно използваеми диагностични процедури; всяка нова система все пак изисква собствено валидиране на декодираните резултати и на поведението.