TL;DR
Beceptivity (от author's neologism) — шкала оценки того, насколько конкретен или обобщён ответ LLM. Darth Vecdor — система для генерации графов знаний — использует набор техник промптинга, чтобы получать точные, специфичные и стабильные ответы от LLM. Главная из них — автоматическая проверка специфичности с повторным запросом, если ответ слишком общий.
LLM часто даёт бесполезно широкие ответы: просишь "лекарства от инфекции" → получаешь "антибиотики". Просишь "чем опасен инфаркт" → получаешь "сердечно-сосудистые осложнения". Модель склонна к безопасным общим формулировкам вместо конкретных списков. При повторных запросах с одним промптом ответы непредсказуемо меняются: то "ибупрофен, парацетамол", то "НПВС, анальгетики". При запросе структурированных данных (коды, категории) модель чаще галлюцинирует, чем при свободном тексте. Если спрашиваешь связанные вещи отдельно (лёгкая/средняя/тяжёлая форма болезни), пропорции не сходятся: то 80%, то 120% суммарно.
Решение — связка из шести техник: (1) попросить LLM оценить специфичность своего ответа по шкале, и если оценка низкая — запросить более конкретные варианты, (2) задать один вопрос несколько раз и выбрать ответ голосованием или усреднением, (3) дать пространство для рассуждений перед финальным ответом, (4) запрашивать связанные элементы вместе в одном промпте, (5) генерировать одну фразу в нескольких стилях для точного мапинга к нужному формату, (6) использовать буквы a/b/c вместо текстовых категорий для снижения путаницы.
Схема метода (Beceptivity Check)
ШАГ 1: Запрос + инструкция вернуть оценку специфичности
"Дай ответ + оцени его специфичность от 0 (максимально общее) до 10 (максимально конкретное)"
ШАГ 2: Проверка порога
Если оценка < минимального порога (например, 7) → переход к Шагу 3
Если оценка ≥ порога → конец
ШАГ 3: Re-query для конкретизации
"Ответ слишком общий. Дай более конкретные варианты вместо '{общий_ответ}'"
Все шаги можно выполнить в одном чате вручную или попросить LLM следовать этой логике.
Пример применения
Задача: Выбираешь подрядчика для разработки MVP своего SaaS. Нужно понять риски работы с конкретной студией, но ChatGPT выдаёт общие фразы типа "риски коммуникации" вместо конкретного списка.
Промпт:
Я выбираю веб-студию для разработки MVP B2B-сервиса автоматизации закупок.
Студия: 5 человек, опыт 3 года, портфолио — лендинги и корпоративные сайты,
нет кейсов с SaaS. Предлагают фикс-прайс 800к₽ за 3 месяца.
Какие риски я получаю, работая с такой студией?
Для каждого риска:
1. Укажи сам риск
2. Оцени его специфичность от 0 (самое общее) до 10 (максимально конкретное)
Если специфичность риска ниже 7 — замени его на 2-3 более конкретных варианта.
Результат:
Модель выдаст список рисков, каждый с оценкой. Если встретится "риск коммуникации" с оценкой 4/10, модель сама заменит его на конкретные варианты: "команда не использует таск-трекер — потеря контроля над задачами", "нет практики асинхронной коммуникации — срывы дедлайнов при болезни PM", "нет регламента созвонов — встречи без agenda и action items". Вместо абстракций получишь чеклист проверяемых моментов для диалога со студией.
Почему это работает
Слабость LLM: Модель обучена на паттернах текста, где безопасная общая формулировка встречается чаще конкретных списков. "Антибиотики" упоминается в контексте лечения инфекций в тысячах статей, а конкретные препараты — реже и в более специфичных контекстах. Модель выбирает наиболее вероятное продолжение, а это часто категория, не элементы категории. При генерации структурированных данных (коды, категории) модель работает на границе своих возможностей — она не имеет прямого доступа к базам кодов, поэтому выдумывает правдоподобное, что приводит к галлюцинациям.
Сильная сторона LLM: Модель хорошо оценивает собственный output, если дать ей критерий. Она умеет рефлексировать и углубляться при явном запросе. Когда просишь "оцени специфичность" — модель переключается в режим метаанализа своего ответа и видит, что "антибиотики" — это действительно обобщение.
Механика beceptivity: Добавив в промпт требование оценить специфичность, ты заставляешь модель подумать о качестве ответа ДО того, как выдать его. Порог (например, 7/10) работает как гейт качества (quality gate). Если модель сама оценила свой ответ ниже порога, она возвращается и генерирует конкретные варианты вместо общих. Это создаёт внутренний цикл рефинемента внутри одного промпта.
Рычаги управления:
- Шкала beceptivity — можешь использовать 0-10, 0-100, или "низкая/средняя/высокая". Числовая шкала точнее, словесная — проще для простых задач.
- Порог — снизь до 5 для быстрых черновиков, подними до 8-9 для критичных задач (медицина, финансы, юридические тексты).
- Число конкретных вариантов — "2-3 варианта" экономит токены, "5-7 вариантов" даёт полноту охвата.
- Критерий специфичности — beceptivity можно заменить на другой: "оцени практичность", "оцени измеримость", "оцени проверяемость".
Шаблон промпта: Beceptivity + Are You Sure
{задача}
Для каждого элемента ответа:
1. Укажи сам элемент
2. Оцени его специфичность от 0 (максимально общее, категория) до 10 (максимально конкретное, детальное)
Если специфичность элемента ниже {порог}, замени его на {количество} более конкретных вариантов.
---
Дополнительно: после получения финального списка, повтори этот же запрос ещё {N} раз
(в отдельных сообщениях). Финальный список = элементы, которые встретились
в большинстве ответов (голосование).
Плейсхолдеры:
- {задача} — твой вопрос, например: "Какие метрики отслеживать для email-рассылки?"
- {порог} — минимальная специфичность, например 7
- {количество} — сколько конкретных вариантов, например "2-3"
- {N} — сколько раз переспросить для голосования, например 2-4
"Are you sure?" дополнение: Вторая часть шаблона (повтор запроса N раз) — это техника voting. Если ответ категориальный (список, выбор из вариантов) — элементы, встретившиеся в большинстве ответов, статистически точнее. Для числовых ответов (пропорции, проценты) — возьми среднее арифметическое.
🚀 Быстрый старт — вставь в чат:
Вот шаблон Beceptivity Check. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы правильно заполнить порог специфичности и число вариантов.
[вставить шаблон выше]
LLM спросит какой порог выбрать (зависит от критичности задачи — для мозгового штурма низкий, для решений высокий) и сколько конкретных вариантов нужно (больше = полнота, меньше = скорость). Она возьмёт логику из шаблона и адаптирует под твой контекст.
Ограничения
⚠️ Увеличение токенов: Техника требует дополнительных элементов в ответе (оценки специфичности) и потенциально повторных запросов. Для длинных списков (50+ элементов) или частых итераций (5+ раз "are you sure?") расход токенов растёт в разы. Beceptivity check лучше для качества над скоростью.
⚠️ Переконкретизация: Если порог слишком высок (9-10), модель может заменить одно общее понятие на 10 узких, и ты получишь список из 100 пунктов вместо 10 полезных. Порог 7-8 — баланс для большинства задач.
⚠️ Субъективность оценки: LLM сама оценивает свою специфичность. Это не объективная шкала, а самоотчёт модели. Иногда модель считает "сердечно-сосудистые осложнения" конкретным ответом (оценка 7/10), хотя для врача это всё ещё категория. Для критичных задач проверяй выборочно — соответствует ли оценка модели твоему пониманию специфичности.
⚠️ Не для творческих задач: Если нужна креативность, абстрактность, метафоры — beceptivity убьёт магию. Техника для фактов, списков, решений. Не для сторителлинга, слоганов, концепций.
Как исследовали
Автор разрабатывал Darth Vecdor — open-source систему (Python + PostgreSQL + pgVector) для извлечения знаний из LLM в структурированные графы знаний (базы данных). Идея: запросить LLM один раз, сохранить в SQL — дешевле и быстрее, чем каждый раз дёргать LLM API. Система предназначена для healthcare (медицинские терминологии, коды диагнозов, связи болезнь↔лекарство), где точность критична, а ошибки дорого́ стоят.
В процессе разработки автор столкнулся с типовыми провалами LLM при попытке получить structured output для графов знаний: (1) модель возвращала "антибиотики" вместо конкретных препаратов, (2) при повторных запросах ответы плавали, (3) при запросе кодов ICD-10/SNOMED галлюцинировала чаще, чем при free-text, (4) при запросе "mild/moderate/severe proportions" отдельно суммы не сходились к 100%, (5) категориальные ответы слегка перефразировались ("fracture" → "fractures"), ломая точное совпадение.
Для решения автор встроил в DV шесть техник промптинга (все описаны в статье как features системы, но применимы вручную в чате): beceptivity check (оценка специфичности → re-query если низкая), "are you sure?" voting (N повторов → голосование/усреднение), reasoning space (место для размышлений перед ответом), multi-element prompting (связанные вещи вместе → согласованность), expansion strings (генерация фразы в разных стилях для мапинга к терминологиям), letter categorical mapping (a/b/c вместо текста → меньше путаницы).
Система настраивается через веб-GUI (HTML/JS/Preact) — пользователь без технического бэкграунда может составлять промпты, настраивать пороги beceptivity, запускать генерацию графов. Автор использовал OpenAI gpt-4o-mini как основную модель (низкая цена, скорость, структурированный JSON output) и PubMedBERT embeddings для векторного поиска соответствий между free-text ответами LLM и медицинскими кодами.
Главный инсайт для практики: Если LLM даёт слишком общий ответ — попроси её саму оценить специфичность и заменить общее на конкретное. Это работает, потому что модель умеет рефлексировать над своим output, но не делает этого по умолчанию без явной инструкции. Добавление метрики (beceptivity, другая оценка качества) превращает генерацию в цикл самопроверки.
Что удивило: LLM точнее возвращает букву "a/b/c", чем текст категории. При запросе "выбери один из: a) fracture, b) headache, c) fever" модель почти всегда правильно вернёт "a", но при запросе "выбери один из: fracture, headache, fever" может вернуть "fractures" или "bone injury" вместо точного "fracture". Это feature модели — короткие символы (буквы, цифры-ярлыки) она воспроизводит точнее, чем перефразирует длинные категории.
Адаптации и экстраполяции
🔧 Техника: Multi-element prompting → согласованность связанных ответов
Если запрашиваешь связанные элементы (пропорции, роли, этапы процесса) — спрашивай всё вместе в одном промпте, не по отдельности.
Пример:
Оцени долю пациентов с COVID-19, у которых болезнь протекает:
- В лёгкой форме: __%
- В средней форме: __%
- В тяжёлой форме: __%
Сумма должна быть 100%.
Эффект: Модель видит constraintсумма = 100% и подгоняет ответы. Если спрашивать отдельно ("какой % лёгкой формы?", "какой % средней?") — модель не помнит предыдущий ответ, и суммы расползаются (80% + 70% + 60% = 210%). Применяй для любых взаимосвязанных величин: бюджет по статьям, время по этапам, распределение ролей в команде.
🔧 Техника: Expansion strings → генерация фразы в нескольких стилях
Если нужно сматчить free-text ответ к структуре (категория, термин, код), попроси модель дать несколько версий фразы в разных стилях.
Пример:
Переформулируй "острый инфаркт миокарда" в 3 стилях:
1. Медицинский (как в учебнике)
2. Простой (как объяснишь другу)
3. Разговорный (как говорят пациенты)
Результат: 1. "Острый инфаркт миокарда с подъёмом сегмента ST" 2. "Сердечный приступ из-за закупорки артерии" 3. "Сердце схватило, инфаркт"
Эффект: Если LLM вернула "сердце схватило", а твоя база знаний содержит только медицинский термин — совпадения не будет. Но если ты сгенерировал все 3 стиля для терминов в базе, у тебя есть "сердце схватило" → "острый инфаркт миокарда" — мэтчинг сработает. Применяй для мапинга жаргона к официальным терминам, клиентского языка к внутренним кодам, сленга к документации.
🔧 Техника: Letter categorical mapping → буквы вместо текста для точности
Если нужен выбор из списка, используй буквы a/b/c как ярлыки, не сам текст категории.
Было (неточно):
Выбери тип риска: технический, финансовый, репутационный
LLM может вернуть: "финансовые риски", "денежный риск", "risk of financial loss" — вариативность ломает точное совпадение.
Стало (точно):
Выбери тип риска:
a) технический
b) финансовый
c) репутационный
Ответь только буквой.
LLM вернёт: "b" — всегда точно, без вариаций.
Эффект: Модель точнее воспроизводит короткие символы, чем перефразирует категории. После получения "b" ты сам делаешь lookup: b → "финансовый". Применяй для любых categorical outputs, где важна 100% точность совпадения: типы документов, статусы задач, уровни приоритета, классификация обращений.
Ресурсы
Darth Vecdor: An Open-Source System for Generating Knowledge Graphs Through Large Language Model Queries
Автор: Jonathan A. Handler, MD (Keylog Solutions LLC, OSF HealthCare Clinical Intelligence and Advanced Data Lab)
GitHub: https://github.com/jonhandlermd/darth_vecdor
Технологии: Python 3.10.2, PostgreSQL 15.10, pgVector 0.8.0, SQLAlchemy, OpenAI gpt-4o-mini, NeuML PubMedBERT embeddings, Preact 10.26, Flask
Связанные работы упомянутые в статье: - "Are you sure?" technique для улучшения точности LLM ответов - Chain-of-Thought reasoning (reasoning space перед ответом) - SentenceTransformers для контекстных embeddings фраз - UMLS Metathesaurus для медицинских терминологий