Лучшие практики проектирования чат-ботов, которые действительно полезны в бизнесе

8 апреля 2026 г., 10:00 · Го Комура · AI, Чат-бот, Веб-разработка, Улучшение воронки обращений, База знаний

Эта статья систематизирует общие принципы создания чат-ботов для обращений на веб-сайте, внутренних FAQ-ботов и ботов первичного ответа. У работающего чат-бота роль, источники знаний, права доступа, условия передачи оператору и метод оценки продуманы раньше, чем «насколько умна модель».

Когда заходит речь о чат-ботах, легко сразу начать с вопросов «какую модель использовать», «делать ли RAG» или «нужна ли мультиагентная архитектура». Но порядок, который реально работает на практике, немного другой.

Сначала нужно решить, чью работу, какую именно задачу и насколько нужно сократить. Если этот порядок нарушен, диалог может звучать правдоподобно, но не приводит ни к обращениям, ни к росту эффективности бизнеса.

На технических и B2B-сайтах эта тенденция особенно сильна. Ценность не в том, чтобы поддерживать долгую непринуждённую беседу. Она в том, чтобы точно рассказать о содержании услуг и при необходимости направить пользователя на нужную страницу или к нужному специалисту. Современные основные руководства по разработке тоже во многом исходят из того, что для промышленного качества оценку, grounding, guardrails и передачу оператору нужно проектировать как отдельные компоненты.¹²³⁴⁵⁶

Оглавление

1. Сначала вывод
2. Сначала - общая картина
3. Первое решение - «чью работу и что именно сократить»
4. Проектирование диалога важнее выбора модели
5. Проектирование базы знаний определяет большую часть качества
6. Промпт: короткие операционные правила важнее длинного описания личности
7. Безопасность - это не только «отсеивание опасных вопросов»
8. Условия передачи человеку определяются заранее
9. Улучшение без оценки - почти случайность
10. Если бот на веб-сайте, проектировать его нужно вместе с воронкой обращений
11. План создания основы за 90 дней
12. Частые ошибки
13. Итог
14. Похожие статьи
15. Источники

1. Сначала вывод

Сформулируем выводы довольно грубо, но удобно для практики.

1. Чат-бот сильнее, если с самого начала определить одно назначение.
2. Ещё до выбора модели нужно решить, на основании чего бот будет отвечать.
3. Нужно разделять ответы, для которых нельзя привести источник, и ответы, которые следует передавать человеку.
4. Чем выше риск операции, тем меньше можно ослаблять права доступа и этапы подтверждения.
5. В промышленной эксплуатации без журналов диалогов и набора для оценки улучшение почти полностью сводится к догадкам.
6. Если бот работает на веб-сайте, помощь в понимании страниц и продвижении по воронке обращений обычно ценнее, чем поддержание долгого диалога.

Хорошо спроектированный чат-бот действительно полезен. Но стоит превратить его в универсальную стойку, отвечающую на всё, - и точность, эксплуатация и зона ответственности разваливаются разом. В конечном счёте быстрее получается, если начать узко и расширяться из областей, где бот точно приносит пользу.⁷

2. Сначала - общая картина

Сначала - общая картина.

flowchart LR
    A[Вопрос пользователя] --> B{В пределах области охвата?}
    B -->|Да| C[Поиск по базе знаний / вызов инструмента]
    B -->|Нет| H[Страница обращения / направление к специалисту]
    C --> D{Соблюдены права доступа и условия безопасности?}
    D -->|Да| E[Ответ с указанием источника + следующее действие]
    D -->|Нет| F[Передача человеку]
    E --> G[Логи / оценка / улучшение]
    F --> G
    H --> G

Важно в этой схеме то, что чат-бот - это не один промпт, а система, включающая воронку, знания, права доступа и оценку. Его нужно проектировать не просто как ответчика на вопросы, а с учётом условий, при которых он отвечает, условий, при которых не отвечает, и того, куда он направляет пользователя дальше.

Современные основные наборы инструментов построены на той же идее. У Google Cloud webhook, handoff rules и evaluation существуют как отдельные возможности, а OpenAI рекомендует фиксировать снимок модели (model snapshot) и создавать evals как основу промышленной эксплуатации.¹²⁸³⁴ Иными словами, первая лучшая практика - не пытаться решить всё одним промптом.

3. Первое решение - «чью работу и что именно сократить»

Прежде чем создавать чат-бота, сначала сузьте назначение до одного. Пока это остаётся расплывчатым, невозможно определить ни критерии оценки, ни структуру знаний.

Назначения в грубом виде можно представить таблицей.

Среди них проще всего начать с задач с узким охватом, где легко определить эталонный источник ответа. Например, легко начать с:

• первичных ответов по FAQ продукта;
• консультаций по услугам до обращения;
• поиска по внутренним регламентам.

И наоборот, такие темы, как:

• решения по договорам;
• фиксация сумм;
• согласование исключений;
• обращения с сильно выраженными индивидуальными условиями для каждого клиента,

безопаснее не делать основной ареной с самого начала.

Кроме того, случаев, где действительно нужна multi-agent архитектура с самого начала, не так много. Microsoft также отмечает, что single-agent упрощает реализацию, снижает эксплуатационную нагрузку и даёт более предсказуемую модель выполнения, и рекомендует сначала проверять решение на single-agent, если нет явной причины для разделения.⁷

4. Проектирование диалога важнее выбора модели

Одна из частых причин неудачи чат-ботов - то, что не определены вход и выход диалога. Если оставить всё как «свободный ввод, спрашивайте что угодно», граница между тем, что бот может, и тем, чего не может, размывается.

4.1 Зафиксировать вход в диалог

Стабильнее, когда область охвата показывается сразу в первом сообщении. Например, для бота на веб-сайте показ в самом начале:

• какие темы бот может обсуждать;
• какие страницы он может сразу порекомендовать;
• какая минимальная информация нужна для консультации,

снижает разброс в диалогах.

Если доступны кнопки или быстрые ответы, размещение первых веток вроде:

• узнать о ценах;
• узнать, беремся ли мы за такую задачу;
• посмотреть примеры проектов;
• оставить заявку,

даёт заметно более стабильный результат, чем только свободный ввод.

4.2 Спрашивать минимум информации

У пользователя достаточно спрашивать только те данные, которые меняют ответ или маршрутизацию. Если добавлять поля просто потому что «кажется, стоит спросить», это увеличивает отток.

Например, спрашивать имеет смысл, если от этого зависит дальнейшая консультация:

• отрасль;
• тип обращения;
• наличие существующей системы;
• срочность.

А информацию, которая не понадобится сразу, лучше отложить на потом.

4.3 Определить, чем заканчивается ответ

Хороший ответ не заканчивается только основным текстом.

Если он завершается в таком порядке:

1. вывод;
2. основание или источник;
3. доступное следующее действие,

диалог легче связывается с реальной работой.

Особенно для ботов на веб-сайте ценность создаётся не завершённостью диалога внутри чата, а ясным следующим шагом:

• перейти на соответствующую страницу услуги;
• посмотреть примеры проектов;
• перейти в форму обращения.

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

Области высокого риска - аутентификация, персональные данные, суммы, договоры, согласование исключений - безопаснее не смешивать с обычным маршрутом консультации. В handoff rules Google Cloud тоже явно приводятся примеры, где запросы высокого риска направляются конкретному агенту.³

5. Проектирование базы знаний определяет большую часть качества

Качество чат-бота чаще страдает из-за базы знаний, чем из-за модели. Если информация, лежащая в основе ответов, неоднозначна, ни одна модель не будет работать стабильно.

5.1 Сначала определить, «что считать эталонным источником»

Как минимум стоит заранее решить:

• какие документы или страницы являются эталонным источником;
• кто отвечает за обновление;
• с какой периодичностью происходит обновление;
• когда устаревшая информация должна быть удалена.

Без этого бот будет одновременно подхватывать и старую, и новую информацию. И это несоответствие с высокой вероятностью станет заметно пользователю.

5.2 Разбивать не по страницам, а по смысловым единицам

Классическая ошибка RAG - просто загрузить PDF или страницы как есть и считать дело сделанным. На практике ответы стабильнее, если работать со смысловыми блоками:

• одно описание регламента;
• одна процедура;
• один пункт FAQ;
• одно предупреждение.

Microsoft указывает, что качество RAG зависит от подготовки контента, и рекомендует в качестве базовой линии chunking, векторизацию, гибридный поиск и семантическое ранжирование.⁵ File search в OpenAI тоже исходит из переписывания запроса, множественного поиска, сочетания keyword и semantic поиска и reranking.⁹ Иными словами, лучшая практика - не «загрузить документы», а «превратить документы в knowledge, пригодный для поиска».

5.3 Показывать источник и дату обновления

Пользователя успокаивает не бот, который хорошо говорит, а бот, чьи основания можно проследить.

Если дизайн позволяет показать:

• какую страницу бот использовал для ответа;
• какой именно пункт какого документа;
• когда информация была обновлена в последний раз,

расследовать ошибочные ответы становится проще.

Web search в OpenAI изначально спроектирован так, чтобы возвращать ответы с указанием источника, а Microsoft Copilot Studio тоже описывает grounded, cited responses.¹⁰¹¹ Даже когда бот отвечает на основе содержимого сайта или внутренних документов, стремление к состоянию «источник можно проследить» облегчает эксплуатацию.

5.4 Выносить актуальную информацию во внешний поиск

Для тем, где важна свежесть данных, не стоит отвечать только на основе фиксированной базы знаний.

Например:

• рабочие дни;
• изменение цен;
• вакансии;
• информация о сбоях;
• изменения законодательства или регламентов.

Для таких вопросов безопаснее либо обращаться к исходному сайту или API по отдельному каналу, либо явно отвечать «актуальную информацию смотрите на этой странице». Если в качестве источника знаний используются публичные сайты, заранее нужно ограничить круг доверенных доменов. Copilot Studio также исходит из поиска, ограниченного настроенными доменами, с citations и проверкой релевантности.¹¹

6. Промпт: короткие операционные правила важнее длинного описания личности

В промпте чат-бота реально работают не длинные описания «личности», а короткие и чёткие операционные правила.

Как минимум удобно разделить его на четыре слоя:

1. роль;
2. знания и инструменты, к которым разрешено обращаться;
3. условия, при которых можно отвечать, и условия передачи оператору;
4. формат ответа.

Например, роль можно описать коротко: «консультирует до обращения», «объясняет внутренние процедуры». Формата ответа тоже достаточно в виде «вывод → основание → следующее действие».

И наоборот, слабый промпт обычно выглядит так:

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

6.1 Использовать структурированный вывод

В сценариях, которые передаются в дальнейшую обработку - статус заказа, слот бронирования, классификация обращения, - безопаснее не полагаться только на свободный текст. OpenAI тоже описывает возврат JSON через Structured Outputs.¹

Текст, который видит человек, и значения, которые получает машина, лучше разделять. Например, само по себе разделение на:

• текст для отображения: пояснение, которое видит пользователь;
• intent: тип обращения;
• confidence: уверенность в определении;
• next_action: дальнейший шаг воронки,

стабилизирует эксплуатацию.

6.2 Зафиксировать версию модели и менять её только после оценки

В промышленной эксплуатации ситуация «сегодня бот отвечает чуть иначе, чем вчера» уже является инцидентом. OpenAI рекомендует фиксировать (pin) снимок модели для production-приложений и создавать evals, измеряющие поведение промпта.¹ Также явно указано, что оптимизацию нужно вести как непрерывный цикл: evals → prompt engineering → fine-tuning.²

6.3 Разделять модели по типу задачи

Не обязательно нагружать одну модель всем сразу. OpenAI тоже рекомендует разделение: модели семейства GPT - для чётких задач с низкой задержкой, reasoning-модели - для сложных решений с высокой неопределённостью.¹²

На практике разделение вида:

• лёгкая модель для ответов FAQ и классификации;
• reasoning-модель для обработки исключений и сложного резюмирования;
• человек для решений высокого риска,

обычно стабилизирует и стоимость, и качество.

7. Безопасность - это не только «отсеивание опасных вопросов»

При словах «безопасное проектирование» легко представить себе только блокировку вредоносных вопросов. Но на практике важно не только это.

7.1 Исходить из возможности prompt injection

Для ботов на базе LLM разумно заранее исходить из возможности prompt injection. Microsoft выделяет два типа - direct и indirect - и отмечает, что скрытые инструкции, встроенные во внешние сайты или файлы, способны перехватить сессию.⁶¹³

Иными словами, для бота, который читает внешние документы или веб-страницы, нужны:

• отказ от того, чтобы обращаться с внешним контентом наравне с системными инструкциями;
• минимизация прав на выполнение инструментов;
• подтверждение перед операциями высокого риска.

7.2 Минимизировать права доступа

Подход «может читать всё, до чего дотягивается» и «может выполнять любую операцию, которую способен вызвать» опасен. В рекомендациях Microsoft по безопасности тоже подчёркивается важность принципа наименьших привилегий и изоляции влияния внешнего контента.⁶

Для внутренних ботов особенно стоит заранее определить:

• права на просмотр по подразделениям;
• разделение информации по клиентам;
• исключение документов, содержащих персональные данные.

7.3 Обрабатывать персональные данные и аутентификацию на отдельном уровне

Безопаснее не полагаться на то, что «бот сам аккуратно всё замаскирует». В документации Microsoft о public website grounding прямо указано, что персональные данные, введённые пользователем, не маскируются и не удаляются автоматически.¹¹

Если бот работает с персональными данными или уникальными данными клиента, нужен дизайн, при котором:

• аутентификация выполняется на стороне приложения;
• круг доступной информации ограничен;
• ведётся журнал аудита;
• перед ответом выполняется проверка идентификации.

7.4 Безопасность закладывается с самого начала, а не в конце разработки

Generative AI Profile от NIST тоже исходит из того, что риски нужно управлять на каждом этапе - проектирования, разработки, эксплуатации и оценки.¹⁴ Иными словами, безопасность - это не финальный пункт проверки перед релизом, а то, что должно входить в спецификацию с самого начала.

8. Условия передачи человеку определяются заранее

Дизайн, который ограничивается одной фразой «если не разберусь - передам оператору», слаб. На практике нужно решить, при каких условиях, кому и с какой сопроводительной информацией передавать диалог.

Например, следующие условия легко определить с самого начала:

• вопросы, требующие аутентификации;
• вопросы, требующие подтверждения договора или суммы;
• вопросы, на которые нельзя привести источник;
• вопросы, на которые бот не смог дать внятный ответ два раза и более;
• жалобы и обращения повышенной срочности;
• консультации в областях высокого риска - юридической, кадровой, медицинской.

В handoff rules Google Cloud явно указано, что вместо передачи на основе инструкций можно использовать детерминированное управление.³ Чем выше риск области, тем удобнее в эксплуатации правило «при этом условии передаём обязательно», а не «наверное, передадим».

Также стоит заранее решить, какую информацию передавать человеку при handoff:

• историю диалога до этого момента;
• уже полученные данные;
• страницы и документы, к которым обращался бот;
• причину, по которой бот застрял;
• что нужно проверить далее.

Уже наличие этих пяти пунктов заметно снижает объём повторной работы после передачи.

9. Улучшение без оценки - почти случайность

Самое опасное в улучшении чат-бота - просматривать несколько диалогов и двигаться дальше на ощущении «вроде стало намного лучше». При таком подходе каждая правка промпта что-то ломает в другом месте.

OpenAI рекомендует сначала написать evals и прогонять их на входных данных, близких к реальной эксплуатации.² Иными словами, отправная точка улучшения - не промпт, а набор для оценки.

9.1 Минимальный набор метрик

В CX Agent Studio от Google Cloud тоже в качестве метрик оценки используются user goal satisfaction, tool correctness, hallucinations и другие.⁴ Этот подход хорошо переносится на любую реализацию.

9.2 Улучшение - это не «серебряная пуля», а цикл

Порядка ниже, как правило, достаточно.

flowchart LR
    A[Создать набор для оценки] --> B[Измерить текущий промпт / модель]
    B --> C[Классифицировать неудачные случаи]
    C --> D[Исправить знания / промпт / маршрутизацию / handoff]
    D --> E[Повторно оценить]
    E --> F[Мониторинг в эксплуатации]
    F --> A

Без этого цикла улучшение зависит от личной интуиции. А с ним становится легко отслеживать, что улучшилось, а что ухудшилось.

10. Если бот на веб-сайте, проектировать его нужно вместе с воронкой обращений

Для чат-бота на корпоративном сайте сам чат не обязательно является главным элементом. В большинстве случаев естественнее спроектировать его как вспомогательную линию, которая:

• сообщает, чем занимается компания;
• подсказывает, какую страницу услуги посмотреть;
• показывает примеры проектов и FAQ;
• снижает тревожность перед обращением.

Особенно на технических и B2B-сайтах описание услуг сложное. Поэтому чаще выигрывает не попытка рассказать всё в чате, а направление на нужную страницу.

Например, хорошо работает такой сценарий:

1. уточнить тип обращения;
2. направить на соответствующую страницу услуги;
3. при необходимости показать связанные примеры проектов или FAQ;
4. если остались неясности, задать только минимум вопросов;
5. перейти к форме обращения.

В таком виде чат становится помощником продаж и воронки обращений. Если же расположить его в отрыве от навигации по страницам, он легко превращается в «коробку, которая умеет говорить, но никуда не ведёт».

11. План создания основы за 90 дней

Не нужно начинать с чего-то масштабного. Для создания основы за 90 дней реалистичен следующий порядок.

0-2 недели: определить назначение и эталонный источник

• решить, какие обращения нужно сократить;
• определить целевых пользователей;
• определить эталонные документы и ответственного за обновление;
• определить условия передачи человеку.

3-6 недель: собрать небольшой прототип

• создать прототип только для основных сценариев;
• создать вступительное сообщение и ветвление;
• реализовать ответы с указанием источника;
• собрать набор для оценки из 20-50 кейсов.

7-10 недель: доработка на пилоте

• изучить логи реальных пользователей;
• классифицировать вопросы, на которых бот застревает;
• исправлять знания и маршрутизацию раньше промпта;
• в областях, где результат слабый, усилить условия передачи оператору.

11-12 недель: определить формат промышленной эксплуатации

• определить метрики, которые проверяются еженедельно;
• зафиксировать и управлять версиями промпта и модели;
• определить процесс обновления и ответственного;
• решить, расширяться ли на второе назначение.

Такой порядок снижает вероятность того, что попытка сразу построить что-то большое развалится.

12. Частые ошибки

В завершение соберём наиболее частые ошибки.

12.1 Превращать бота в универсальную стойку, отвечающую на всё

Если с самого начала слишком расширить область охвата, размываются и точность, и зона ответственности. Сужение до одного назначения даёт более сильный результат.

12.2 Нет эталонного источника и ответственного за обновление

Даже при наличии RAG-инфраструктуры результат не будет стабилен, если исходная информация не упорядочена. Управление базой знаний - это отдельная работа.

12.3 Категорично утверждать что-то без источника

Правдоподобно звучащие ответы - самое опасное в эксплуатации. Ответы, основания которых нельзя проследить, трудно исправить впоследствии.

12.4 Сразу давать боту выполнять операции высокого риска

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

12.5 Расплывчатая передача человеку

Если написано только «при необходимости передаём оператору», на практике это создаёт затор. Нужно определить условия, адресата и сопроводительную информацию.

12.6 Нет набора для оценки

При каждом улучшении невозможно понять, стало лучше или хуже. Это встречается очень часто.

12.7 С самого начала выбирать multi-agent архитектуру

Увеличение числа агентов повышает свободу проектирования. Но одновременно растёт нагрузка по задержке, управлению состоянием, мониторингу, отладке и управлению правами доступа. Если нет необходимой причины для разделения, безопаснее сначала попробовать с одним агентом.⁷

13. Итог

Если сформулировать лучшую практику создания чат-бота одной фразой: решить роль, знания, права доступа, передачу оператору и оценку раньше выбора модели.

Особенно важны следующие пять пунктов:

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

Этот порядок во многом общий как для сайтов, так и для внутреннего использования. Если проектировать чат-бота не как «нечто, что хорошо говорит», а как «инструмент, который упорядочивает, где сокращается работа и где происходит передача человеку», вероятность неудачи заметно снижается.

Похожие статьи

• Зачем компании нужен собственный сайт - как не ограничиться визиткой и превратить его в источник прибыли
• Как связать статьи и страницы услуг - основы проектирования внутренних ссылок
• Как создавать страницы услуг - порядок структурирования для технической сферы и B2B
• Три места, которые нужно исправить в первую очередь на сайте, куда не приходят обращения
• Лучшие практики SEO и Google Ads - общая схема привлечения через поиск

Источники

Услуги, связанные с этой темой

Эта статья связана со следующими страницами услуг. Заходите с наиболее близкого вам входа.

Улучшение воронки обращений на веб-сайте

Чат-бот на веб-сайте эффективнее, если спроектирован вместе с направлением к FAQ, страницам услуг и форме обращения.

Смотреть услугу «Улучшение воронки обращений на веб-сайте» Связаться с нами

Разработка веб-сайта

Чат-бот на веб-сайте эффективнее, если спроектирован вместе со структурой страниц, CTA-элементами и страницей обращения.

Смотреть услугу «Разработка веб-сайта» Связаться с нами

Разработка веб-сайта (пересмотр SEO и воронки обращений)

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

Смотреть услугу «Разработка веб-сайта» Связаться с нами

Профиль автора

Страница профиля автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, технической консультации и расследовании неисправностей. Особенно силён в проектах, связанных с сохранением существующих активов, и в расследовании сбоев, причины которых трудно установить. Также хорошо справляется с задачей структурировать бизнес со сложным техническим контекстом в понятную структуру страниц и формулировки.

Смотреть профиль Связаться с нами

Публичные ссылки

• GitHub
• X

Вернуться к списку статей блога

Связаться с нами

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Что нужно решить в первую очередь при внедрении чат-бота?

Ещё до выбора модели нужно сузить назначение бота до одного - определить, чью работу, какую именно задачу и насколько нужно сократить. Пока это остаётся расплывчатым, невозможно определить ни критерии оценки, ни структуру знаний. Проще всего начать с узких по охвату задач, где легко зафиксировать эталонный источник ответа: первичные ответы по FAQ продукта, консультация по услугам до обращения, поиск по внутренним регламентам. Области высокого риска - решения по договорам, фиксация сумм - безопаснее не делать основной ареной с самого начала.

Как сделать так, чтобы качество ответов чат-бота было стабильным?

Качество чаще страдает из-за знаний, чем из-за модели, поэтому сначала нужно определить, какие документы или страницы считаются эталонным источником, кто отвечает за их обновление и с какой периодичностью они обновляются. В RAG ответы стабильнее, если работать не с целыми PDF или страницами, а со смысловыми блоками - одной процедурой, одним пунктом FAQ. Кроме того, если в дизайне предусмотреть отображение источника (какая страница легла в основу ответа) и даты обновления, расследовать ошибочные ответы становится проще.

Как правильно спроектировать передачу диалога от чат-бота к человеку?

Дизайн, ограниченный одной фразой «если не понял - передам оператору», слаб: нужно решить, при каких условиях, кому и с какой сопроводительной информацией передавать диалог. Легко определить в качестве условий передачи с самого начала: вопросы, требующие аутентификации, вопросы о подтверждении договора или суммы, вопросы, на которые нельзя привести источник, а также вопросы, на которые бот не смог дать внятный ответ дважды и более. При передаче стоит отдавать человеку пять вещей - историю диалога, уже полученные данные, использованные документы, причину, по которой бот застрял, и что нужно проверить далее - это заметно снижает объём повторной работы.

Какие ошибки чаще всего допускают при внедрении чат-ботов?

Типичные ошибки: превращать бота в универсальную стойку, отвечающую на всё, и чрезмерно расширять область охвата; не определять эталонный источник и ответственного за его обновление; давать боту категорично утверждать что-то без источника; сразу давать боту выполнять операции высокого риска; оставлять условия передачи человеку расплывчатыми; не иметь набора для оценки; и с самого начала выбирать multi-agent архитектуру. Без набора для оценки при каждой правке промпта невозможно понять, стало лучше или хуже, и улучшение фактически превращается в игру случая.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.