Я описывал проблему версионности web components в одном SPA вот тут и тут и как ее решал. Там же говорил про
Похоже, дело сдвинулось. Safari 26.4 объявил (Web API → Improvements to Scoped Custom Element Registries) об улучшениях поддержки этого API. Chrome поддерживает с версии 146.
Теперь можно создать изолированный реестр и привязать его к Shadow DOM. Каждый shadow root своя версия компонента, без конфликтов с глобальным window.customElements.
Круто!
Proposal Scoped Custom Element Registries которому уже 7 лет.Похоже, дело сдвинулось. Safari 26.4 объявил (Web API → Improvements to Scoped Custom Element Registries) об улучшениях поддержки этого API. Chrome поддерживает с версии 146.
Теперь можно создать изолированный реестр и привязать его к Shadow DOM. Каждый shadow root своя версия компонента, без конфликтов с глобальным window.customElements.
Круто!
1🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Такие утренние слоты сильно упрощают рабочий день 💪🏻
5🔥11
Вчера ходил на концерт группы Jane Air. 24 года этой банде.
Смотрел и думал, всем бы так гореть своим делом как эти дядьки.
Смотрел и думал, всем бы так гореть своим делом как эти дядьки.
1🔥5
Когда просто LLM поверх доки не взлетает
Думал, что задача «подключить документацию к боту» это просто загрузил документы, настроил поиск, подкрутил промпт и готово.
Оказалось, всё неприятнее.
Сейчас делаю проект, где внутреннюю документацию нужно превратить в рабочую базу знаний для бота. И довольно быстро выяснилось, что плохой ответ может появляться в разных местах:
- бот не нашёл нужный документ;
- нашёл соседний документ с похожим смыслом;
- в исходной документации не хватает важного факта;
- факт есть, но модель не вытянула его в ответ.
Из-за этого пришлось собирать отдельный ai eval. AI Eval помогает проверять поиск, качество ответа и разбирать, где именно ухудшается качество ответов.
Мои промежуточные выводы по такой задаче:
- Prompt engineering помогает, но на корпусе документов из 60 файлов быстро упирается в потолок.
- Если в исходной документации не хватает различий между близкими сущностями, это неизбежно вылезает в ответах.
Без проверки качества такие системы очень сложно «улучшать» вслепую.
В итоге для меня это уже выглядит не как «LLM поверх документации», а как инженерная задача со своим корпусом знаний и проверками.
До пользователей это пока не докатил. Сейчас как раз этап, где нужно понять, достаточно ли надёжно оно работает в реальных сценариях.
Если будет интересно, потом отдельно расскажу, как строил eval для такого корпуса.
Думал, что задача «подключить документацию к боту» это просто загрузил документы, настроил поиск, подкрутил промпт и готово.
Оказалось, всё неприятнее.
Сейчас делаю проект, где внутреннюю документацию нужно превратить в рабочую базу знаний для бота. И довольно быстро выяснилось, что плохой ответ может появляться в разных местах:
- бот не нашёл нужный документ;
- нашёл соседний документ с похожим смыслом;
- в исходной документации не хватает важного факта;
- факт есть, но модель не вытянула его в ответ.
Из-за этого пришлось собирать отдельный ai eval. AI Eval помогает проверять поиск, качество ответа и разбирать, где именно ухудшается качество ответов.
Мои промежуточные выводы по такой задаче:
- Prompt engineering помогает, но на корпусе документов из 60 файлов быстро упирается в потолок.
- Если в исходной документации не хватает различий между близкими сущностями, это неизбежно вылезает в ответах.
Без проверки качества такие системы очень сложно «улучшать» вслепую.
В итоге для меня это уже выглядит не как «LLM поверх документации», а как инженерная задача со своим корпусом знаний и проверками.
До пользователей это пока не докатил. Сейчас как раз этап, где нужно понять, достаточно ли надёжно оно работает в реальных сценариях.
Если будет интересно, потом отдельно расскажу, как строил eval для такого корпуса.
1❤6
Доверяй, но проверяй.
В прошлом посте писал, что подключить документацию к LLM оказалось сложнее, чем я ожидал. Когда бот отвечает плохо, не всегда понятно почему.
Что происходит при поиске нужного документа в проекте:
- не находит нужный документ;
- находит похожий, но не тот;
- находит правильный, но пропускает важный факт или источник;
- берёт факт из документации, но неправильно формирует ответ.
Для оценки системы собрал небольшой eval: набор вопросов, ожидаемых источников ответов в виде имён файлов и проверок ответа.
Eval состоит из:
- retrieval, проверяет источник ответа и выставляет оценку: попал / не попал;
- judge, другая модель, которая на вход принимает ответ бота и заметки для оценки. Judge выставляет оценку от 0 до 2, где 0 вообще мимо, а 2 точно донёс информацию.
Так стало проще понять не только то, что бот ошибся, но и где именно:
- проблема в поиске;
- проблема в документации;
- проблема в формулировке ответа.
Каждый сгенерированный документ в шапке имеет свой frontmatter, в котором есть информация о том, к какой сущности он относится и какое действие над сущностью описывает.
Иногда бот отвечает плохо не потому, что модель слабая или промпт неудачный.
В самой документации проекта может не хватать важных различий между похожими сущностями и действиями над ними. Для более строгих границ приходится докручивать промпт генерации.
Важный принцип, которого я пока придерживаюсь (и надеюсь, так будет и дальше): не править руками ни один сгенерированный файл только ради того, чтобы получить хорошие оценки на eval.
В прошлом посте писал, что подключить документацию к LLM оказалось сложнее, чем я ожидал. Когда бот отвечает плохо, не всегда понятно почему.
Что происходит при поиске нужного документа в проекте:
- не находит нужный документ;
- находит похожий, но не тот;
- находит правильный, но пропускает важный факт или источник;
- берёт факт из документации, но неправильно формирует ответ.
Для оценки системы собрал небольшой eval: набор вопросов, ожидаемых источников ответов в виде имён файлов и проверок ответа.
Eval состоит из:
- retrieval, проверяет источник ответа и выставляет оценку: попал / не попал;
- judge, другая модель, которая на вход принимает ответ бота и заметки для оценки. Judge выставляет оценку от 0 до 2, где 0 вообще мимо, а 2 точно донёс информацию.
Так стало проще понять не только то, что бот ошибся, но и где именно:
- проблема в поиске;
- проблема в документации;
- проблема в формулировке ответа.
Каждый сгенерированный документ в шапке имеет свой frontmatter, в котором есть информация о том, к какой сущности он относится и какое действие над сущностью описывает.
Иногда бот отвечает плохо не потому, что модель слабая или промпт неудачный.
В самой документации проекта может не хватать важных различий между похожими сущностями и действиями над ними. Для более строгих границ приходится докручивать промпт генерации.
Важный принцип, которого я пока придерживаюсь (и надеюсь, так будет и дальше): не править руками ни один сгенерированный файл только ради того, чтобы получить хорошие оценки на eval.
🔥5❤3
AI-assisted engineers are burning out, is this fine?
Мне показалось очень полезным в это время активной агентской разработки.
Примеры прям в точку 🤌🏻
Мне показалось очень полезным в это время активной агентской разработки.
Примеры прям в точку 🤌🏻
evilmartians.com
AI-assisted engineers are burning out, is this fine?—Martian Chronicles, Evil Martians’ team blog
AI-assisted code generation is not free. It comes with a hidden cost: burnout. Are we dangerously ignorant to this problem? And how can we cope with it? In this post, we discuss this question.
👍3
Стал чаще слышать о том что AI лаборатории субсидируют подписки и реальная стоимость использования LLM сильно выше того что платим.
Видимо через какое-то время адекватно решать рабочие задачи только на подписках не получится. Либо придется брать самые дорогие и подсаживаться на провайдеров.
Посмотрел статистику своего использования Codex за 30 дней. Codex Bar показал примерно 1038$ API стоимости и около 1.4 млрд токенов.
Экспреимент. Подключил локальную Qwen3:32B в Zed Agent.
Сообщение
улетело около 8500 тысячи токенов.
Агентский режим это не только запрос. С ним улетает системный промт, инструкции агента, tools, MCP, скиллы и прочая обвязка.
Получается, что даже на банальном
можно потратить десятки тысяч токенов, до того как модель начнет думать. А потом удивляемся, а чего это claude / codex скушал дневной лимит.
Пора начать погружаться в токеномику, пока еще можно учиться на подписках.
Видимо через какое-то время адекватно решать рабочие задачи только на подписках не получится. Либо придется брать самые дорогие и подсаживаться на провайдеров.
Посмотрел статистику своего использования Codex за 30 дней. Codex Bar показал примерно 1038$ API стоимости и около 1.4 млрд токенов.
Экспреимент. Подключил локальную Qwen3:32B в Zed Agent.
Сообщение
hello
улетело около 8500 тысячи токенов.
Агентский режим это не только запрос. С ним улетает системный промт, инструкции агента, tools, MCP, скиллы и прочая обвязка.
Получается, что даже на банальном
Сгененрируй commit message
можно потратить десятки тысяч токенов, до того как модель начнет думать. А потом удивляемся, а чего это claude / codex скушал дневной лимит.
Пора начать погружаться в токеномику, пока еще можно учиться на подписках.
💯4