Jev: зачем использовать отдельную модель для принятия решений? Большинство современных AI-сервисов строятся вокруг LLM: отправили контекст, модель что-то проанализировала и вернула ответ. Но далеко не каждой задаче нужен ChatGPT-подобный интеллект. Иногда от модели требуется гораздо более простая вещь: выбрать один вариант из известных заранее или оценить вероятность события. Именно для этого предназначена Jev от TypeSafe System One (есть и другие подобные решения, но сейчас не про это). Она не генерирует произвольный текст, а работает с типизированными решениями: Choice, Noul и Score. То есть вместо: - "Проанализируй ситуацию и расскажи, что делать" мы задаём: - A / B / C / ничего из перечисленного и получаем выбранный вариант вместе с вероятностью. Зачем это может понадобиться? Пример 1. Проверка банковских операций Допустим, есть поток транзакций. Для каждой нужно решить: - операция выглядит обычной; - требует дополнительной проверки; - имеет высокий риск мошенничества. LLM тоже способна это определить. Но какой ценой? Нам не нужен результат в виде текста - "На основании предоставленной информации операция выглядит подозрительной...". Нужно одно конкретное решение, а именно его вероятность из предложенных вариантов. Здесь подход Jev выглядит естественнее: пространство возможных ответов заранее ограничено, модель не может придумать четвёртый статус, а программа после ответа сразу выполняет следующий шаг. Например: "имеет высокий риск мошенничества" > 0.9 -> заблокировать автоматическую обработку 0.5–0.9 -> отправить на дополнительную проверку В таком сценарии при больших объемах LLM становится довольно тяжёлым механизмом для получения нескольких структурированных значений. Пример 2. Разбор большого потока резюме (актуалочка) Представим сервис, через который ежедневно проходят тысячи резюме. Для каждого кандидата нужно определить несколько вещей: - соответствует ли опыт вакансии; - насколько релевантный основной стек; - есть ли обязательные требования; - стоит ли передавать резюме рекрутеру. Можно отправлять каждое резюме в LLM и просить написать заключение. Но если итогом должно стать одно из событий: REJECT / MANUAL_REVIEW / NEXT_STAGE, то большая часть возможностей LLM просто не нужна. У Jev можно сразу задать несколько вопросов одной "батареей": соответствие требованиям, уровень релевантности и финальный маршрут кандидата. В результате мы получаем не эссе о кандидате, а набор решений, которые сразу может обработать код. При большом количестве однотипных запросов это особенно интересно: согласно тестам (тут поверим интернету), Jev оказалась быстрее и дешевле LLM именно в задачах со стабильной структурой. В этом и заключается основная ценность Jev для меня - цена, т. е. экономия токенов на больших объемах данных. Далее я расскажу пример который хочу реализовать, не уверен что это будет именно Jev, но суть та же.
BlaNote
Векторное мышление: как задавать направление вместо формулировок
Мы привыкли считать, что мышление - это работа со словами. Чётко сформулировал - получил результат. Ошибся в формулировке - получил неправильный ответ. Работа с большими языковыми моделями (LLM) показывает, что это представление неполное. Куда важнее не что именно ты сказал, а в каком направлении ты указал. Этот способ мышления всё чаще называют векторным. Векторное мышление - это подход, при котором: смысл представляется не как текст или формула, а как точка или направление в многомерном пространстве признаков...
Написание логики без if/else на примере Java.
if и else уходят в закат Иногда на уме возникают какие-то безумные идеи - как писать логику без операций ветвления? Да, такая тема существует - ниже я объясню зачем, как это работает, какие техники используют, и в каких случаях это реально даёт пользу, а где - это просто красивая теория, которая на практике вредна. Зачем вообще избавляться от if/else. Коротко: Когда мотив имеет смысл 1. Слишком много if/else или switch - код трудно читать и невозможно расширять без правок. 2. Появляется состояние, зависящее от типа/статуса/режима, и каждый новый тип добавляет новые ветки...
«анти-vibe-coding» Мне тут ChatGPT сказал, что я, оказывается, занимаюсь «анти-vibe-coding'ом». Методология SDD (Spec-Driven Development) - это не формальный стандарт вроде Scrum или TDD, а современный подход к разработке, который делает спецификацию центральным элементом всего процесса. По сути, это «анти-vibe-coding» подход: - Сначала - чётко формулируем, что и зачем мы делаем. - Потом - реализуем ровно то, что описано. - И проверяем, что результат соответствует спецификации. Суть SDD (Spec-Driven Development) можно описать формулой: | Спецификация - План - Реализация - Проверка соответствия В отличие от классического "code-driven" подхода, где код рождает документацию постфактум, здесь всё наоборот: - Спецификация задаёт направление. - Реализация служит доказательством. - Документация - не побочный продукт, а фундамент. Основные принципы. Specification First - любая фича начинается с текстовой (или формальной) спецификации - описания цели, сценариев, ограничений, допущений. Traceability - каждый кусок кода должен иметь соответствующую запись в спецификации. Это обеспечивает прозрачность и контроль изменений. Predictable Outcomes - мы формулируем, что считаем успешным результатом заранее. Код проверяется не просто на корректность, а на соответствие ожидаемому поведению. Iterative Refinement - спецификация не статична - её можно уточнять по мере исследования, но изменения должны быть осознанными и фиксироваться. Human-AI Co-development (новая черта) - в эпоху Copilot/ChatGPT спецификация становится интерфейсом не только между людьми, но и между человеком и ИИ-ассистентом: она описывает намерения, чтобы ИИ мог правильно генерировать код.
Как ИИ воспринимает форматированный документ?
В статье на Habr я рассказывал про форматированные документы - правила, рассуждал о возможности их применения как инструкции, спецификации и шаринг между команды в разработки программного приложения. Есть интересный пример и его разбор который не вошел в статью. В модуле нашего приложения `create` есть форматированный документ, который является описанием обработки ошибок: CREATE_ERROR_HANDLING.md # TRIGGER: ERROR_HANDLING_CREATE ## Контекст В модуле `create` реализована специализированная обработка ошибок для валидации создания постов...
VibeCode. Как не назови все равно полетит Plain Text vs XML or Markdown: на чём писать промпты для ИИ-кодера? Структура — это новый язык общения с ИИ. Особенно когда дело касается кода. Есть миф: чтобы попросить ИИ написать код, достаточно набросать запрос в чат «как есть». Plain text, без правил. Сработает? Иногда. Будет эффективно? Редко. Почему ИИ «понимает» структурированный промпт (с тегами, отступами, чёткими блоками) лучше, чем простой текст? Читать далее habr.com/...794/
