хорошая модель не спасает плохой контекст
Когда бот отвечает расплывчато, повторяет общие фразы или путает детали, первая реакция обычно звучит так: «значит, нужна модель получше». Но очень часто проблема в другом. Если система не получила релевантный контекст, не увидела нужный документ или прочитала слишком сырой текст, даже сильная модель не сможет выдать уверенный и точный ответ.
Поэтому качество бота начинается не в модели, а в том, как устроены знания. Разрозненные документы, устаревшие инструкции, дубли, длинные полотна текста без структуры и неочевидные названия разделов ломают качество сильнее, чем разница между соседними версиями модели.
где чаще всего рушится полезность бота
Типовые точки отказа выглядят так: retrieval находит не тот фрагмент, в контекст попадает слишком много шума, система не различает похожие сценарии, нет ограничений на выдумывание ответа, а у самого бота нет понятных правил эскалации. В результате он звучит уверенно, но не решает задачу.
Еще один скрытый фактор это сама формулировка роли бота. Если от него ждут и консультацию, и продажи, и helpdesk, и оформление заявки, он начинает расплываться. Чем яснее сценарий, ожидаемый результат и границы ответственности, тем выше шанс получить действительно сильный ответ.
что улучшать раньше, чем менять модель
Обычно сильнее всего влияют четыре вещи: чистка и переразметка базы знаний, улучшение retrieval, явные инструкции по формату ответа и наблюдаемость по типовым ошибкам. Когда команда видит, где бот не нашел источник, где выбрал не тот фрагмент и где не отправил кейс человеку, улучшения становятся инженерной работой, а не гаданием.
Смена модели имеет смысл после того, как вы привели в порядок контекст и процесс. До этого этапа она часто дает только косметический выигрыш. А вот структурированная база знаний, хороший поиск по ней и внятный поток действий почти всегда дают заметный прирост полезности уже на текущем стеке.