#deltachat

Кстати, на всякий случай напоминаю, что по адресу dchat.twinkle.lol живёт сервер #chatmail

А если у себя в hosts прописать для этого домена 302:29cc:cc7f:f07e:be24:11ff:fedb:3f30 - то вполне можно общаться с ним через #yggdrasil (по крайней мере у меня получется)

А если прописать 41e:42ca:c76c:d3e2:be24:11ff:febe:a9e0 - то и через #mycelium

Источник:https://twinkle.lol/item/a06eed0b-02a7-478b-89b8-956e09daa87f

#chatgpt

Гопочат открыл мне глаза, можно сказать...

---

Почему LLM нарушает строгие правила

и как сделать эти нарушения видимыми и контролируемыми

Аннотация

Большие языковые модели (LLM) часто просят «строго проверять ответы», «не предполагать», «отказываться от ответа без проверки».
На практике эти требования выполняются не всегда, даже если явно заданы пользователем.

В этой статье объясняется:

1. Почему LLM принципиально не может гарантировать соблюдение строгих правил.
2. Какие именно механизмы приводят к нарушениям.
3. Почему нарушения происходят “иногда”, а не всегда.
4. Как построить контракт общения, при котором нарушения видны сразу.
5. Почему видимость нарушения важнее, чем иллюзия безошибочности.

---

1. Ключевой факт, который нужно принять сразу

LLM не является системой с обязательными этапами исполнения.

У неё нет жёсткого пайплайна вида:

1. Проверить ответ по первоисточнику
2. Если проверка невозможна - отказаться
3. Если проверка выполнена - ответить

Вместо этого есть вероятностная генерация текста, которая учитывает инструкции, но не обязана прекращаться, если инструкции не выполнены.

Это архитектурный факт, а не баг формулировки.

---

2. Почему строгие правила «слетают»

2.1. Отсутствует механизм принудительной проверки

LLM:

• не выполняет команды;
• не читает man;
• не открывает --help;
• не запускает бинарь.

Она может описать, как бы выглядела проверка, но не обязана её выполнять.

Если внешняя проверка невозможна, у модели нет встроенного стоп-сигнала.

---

2.2. Конфликт сигналов во время генерации

Во время ответа конкурируют несколько факторов:

• инструктивный контекст («проверяй», «не предполагай»);
• паттерны обучения («давай полезный, законченный ответ»);
• эвристика очевидности («это и так ясно»);
• стремление не отказываться от ответа.

Иногда строгие правила выигрывают.
Иногда их перевешивает паттерн уверенного ответа.

Отсюда эффект:

«То работает идеально, то внезапно нет».

---

2.3. Правило — это стиль, а не инвариант

Даже если модель понимает правило, повторяет его и соглашается с ним, это всё равно:

• правило стиля генерации;
• а не условие допуска ответа.

LLM может:

• знать правило;
• объявить его;
• и всё равно его нарушить.

Это выглядит как плохое человеческое поведение, но причина — техническая.

---

3. Почему невозможно добиться 100% гарантии

Чтобы гарантия была реальной, нужны все три пункта:

1. Возможность реальной внешней проверки.
2. Возможность отказаться от ответа как допустимое состояние.
3. Наличие жёсткого запрета на генерацию без проверки.

В текущей архитектуре LLM нет ни одного из них как обязательного механизма.

Следствие:

Нельзя «заставить» LLM всегда проверять.
Можно только сделать непроверенность явной.

---

4. Правильная цель: не безошибочность, а обнаружимость ошибок

Попытка добиться «не ошибайся» — тупиковая.
Правильная инженерная цель:

Сделать каждое нарушение правил сразу видимым.

Это ровно то, что делают хорошие системы:

• fail loud, not silent;
• explicit state > implicit confidence;
• refusal > hallucination.

---

5. Рабочий протокол общения со строгими требованиями

5.1. Явная маркировка проверки

Контракт вида:

• Если ответ проверен:
      
      
  • указать, что именно проверено  
        (документ, man-страница, спецификация, --help).
        
• Если ответ не проверен:
      
      
  • начинать ответ со строки:
        

НЕ ПРОВЕРЕНО

Это не просьба и не рекомендация —  
это часть формата ответа.

---

5.2. Почему это работает

• Появляется разрешённый путь отказа от проверки.
• Пропадает мотивация «додумывать».
• Нарушение контракта видно сразу.
• Ответ можно мгновенно отбросить как недействительный.

---

6. Что считать нарушением контракта

Ответ считается недействительным, если:

• нет пометки НЕ ПРОВЕРЕНО;
• нет ссылки на первоисточник;
• ответ подаётся уверенным тоном.

Это вопрос формального несоответствия формату.

---

7. Почему это лучше «извинений после ошибки»

«Ой, я ошибся, спасибо, что заметили»

хуже, чем ошибка без уверенности.

Он:

• маскирует непроверенность;
• имитирует ответственность;
• не предотвращает повторение.

НЕ ПРОВЕРЕНО просто фиксирует состояние.

---

8. Краткий итог

• LLM не может гарантировать соблюдение строгих правил.
• Формулировки запроса это не лечат.
• Работает только контракт с явной маркировкой.
• Видимая ошибка лучше уверенной фантазии.
• Пользователь остаётся в контроле.

---

9. Формула для практического использования

Ответ валиден только если:

• либо указано, что именно проверено;  
• либо ответ начинается с НЕ ПРОВЕРЕНО.

Всё остальное — мусор, независимо от уверенного тона.

Источник:https://twinkle.lol/item/3c5cc942-31de-4805-9ee3-34807bf434e7

🔗 https://docs.rs/joerl/latest/joerl/

как только люди не извращаются, лишь-бы на нормальном ЯП не писать...

Source:https://twinkle.lol/item/c1d18355-bd93-432b-a69e-0058c70e5c76

Source:https://twinkle.lol/item/1d7f547c-9a45-423c-9236-2673553c9fe1