The post has been translated automatically. Original language: Russian
Everyone is adding AI now, but half of the projects end up with an expensive toy that doesn't affect the metrics. We share our practice on how to approach this in an engineering way.
1. First the task, then the technology
Not "let's screw up the AI", but "what specific pain will it cover". AI really pays off where there is routine, volume, and text: support, application processing, content generation, and knowledge base search. If the task is solved by ordinary logic or a simple script, do not complicate it.
2. Don't train your model. Use the API
A common mistake of early teams is to try to "train a neural network." In 99% of cases, this is unnecessary and ruinous. Take ready-made LLMs through the API (Anthropic, OpenAI, Google, etc.), and use according to your specifics: industrial engineering — correctly formulated instructions close most cases; RAG (retrieval-augmented generation) — connecting your knowledge base/documents so that the model responds to your data rather than "hallucinating"; Fine-tuning — only when everything else has already been squeezed out and a stable narrow format is needed.
3. Keep the person in the loop
Especially at the start: the AI prepares a draft/response, and the human confirms it. This protects against errors in client communications and gives you the data on which the system becomes more accurate.
4. Consider the cost and speed from the first day
Two parameters that kill AI features in the product: the price per request and the latency. Practice: cache duplicate answers, choose a model for the task (don't take the top one where the easy one is enough), set limits. The same feature on a "cheap" and "expensive" model may differ significantly in cost with the same result.
5. Set limiters (guardrails)
AI in a product without a framework = risk. Minimum: filtering of unwanted input/output, clear boundaries of "what the assistant doesn't talk about", folback on a live person, logging for error analysis.
6. A quick start in a week, not a quarter
A working approach: take one narrow scenario (for example, AI answers to the 20 most frequent customer questions), assemble a prototype on the API in a few days, test it on real requests, measure the effect, and only then scale. A small working case is more useful than a large "AI-platform" plan in a presentation.
A short checklist before implementation: ✅ there is a specific task with a measurable metric The API + prompt/RAG path has been chosen, rather than learning from scratch , the cost of the request and latency are calculated , there is a man in contour and guardrails You start with one narrow scenario
ИИ сейчас добавляют все — но у половины проектов это заканчивается дорогой игрушкой, которая не влияет на метрики. Делимся практикой, как подойти к этому по-инженерному.
1. Сначала задача, потом технология
Не «давайте прикрутим ИИ», а «какую конкретную боль это закроет». ИИ реально окупается там, где есть рутина, объём и текст: поддержка, обработка заявок, генерация контента, поиск по базе знаний. Если задачу решает обычная логика или простой скрипт — не усложняйте.
2. Не обучайте свою модель. Используйте API
Частая ошибка ранних команд — пытаться «обучить нейросеть». В 99% случаев это не нужно и разорительно. Берите готовые LLM через API (Anthropic, OpenAI, Google и др.), а под свою специфику используйте: 🔹 промпт-инжиниринг — правильно сформулированная инструкция закрывает большинство кейсов; 🔹 RAG (retrieval-augmented generation) — подключение вашей базы знаний/документов, чтобы модель отвечала на ваших данных, а не «галлюцинировала»; 🔹 fine-tuning — только когда всё остальное уже выжато и нужен стабильный узкий формат.
3. Держите человека в контуре
Особенно на старте: ИИ готовит черновик/ответ — человек подтверждает. Это защищает от ошибок в клиентских коммуникациях и даёт вам данные, на которых система становится точнее.
4. Считайте стоимость и скорость с первого дня
Два параметра, которые убивают ИИ-фичи в проде: цена за запрос и задержка (latency). Практика: кэшируйте повторяющиеся ответы, подбирайте модель под задачу (не берите топовую туда, где хватит лёгкой), ставьте лимиты. Одна и та же фича на «дешёвой» и «дорогой» модели может отличаться по себестоимости в разы при том же результате.
5. Ставьте ограничители (guardrails)
ИИ в проде без рамок = риск. Минимум: фильтрация нежелательного ввода/вывода, чёткие границы «о чём ассистент не говорит», фолбэк на живого человека, логирование для разбора ошибок.
6. Быстрый старт за неделю, а не за квартал
Рабочий подход: возьмите один узкий сценарий (например, ИИ-ответы на 20 самых частых вопросов клиентов), соберите прототип на API за несколько дней, протестируйте на реальных запросах, померьте эффект — и только потом масштабируйте. Маленький работающий кейс полезнее большого «ИИ-платформенного» плана в презентации.
Короткий чек-лист перед внедрением: ✅ есть конкретная задача с измеримой метрикой ✅ выбран путь API + промпт/RAG, а не обучение с нуля ✅ посчитаны стоимость запроса и latency ✅ есть человек в контуре и guardrails ✅ начинаете с одного узкого сценария
Share
