Спецстатья адвоката Лин Шанлун: «Сильный BD — продаёт интеграционные возможности ИИ»

業работки для бизнеса в эпоху ИИ: можно целостно эволюционировать, ориентируясь на болевые точки своей команды, даже если вы не full-time разработчик. Такая настройка должна быть “базовой” для любой должности.
(Справка: статья юриста Лин Шанлунь》Профессионалы, которые понимают ИИ, — будут ли они победителями в эпоху ИИ? )
(Контекст: статья юриста Лин Шанлунь》страх перед ИИ из истории Цай Ага: вас злит не ИИ — вас пугает, что вас обойдут )

Оглавление

Toggle

• То, что он делает, на самом деле довольно точно бьёт по болевым точкам
• Речь о том, как он “встроил” ИИ
• Но я думаю: Output можно сделать ещё больше
• С точки зрения юриста: есть одна вещь, которую обязательно нужно сделать — снизить галлюцинации
• Несколько функций, которые, как мне кажется, его BD Agent может добавить
  • Автоматически генерировать версии договоров по записям встреч
  • Настраивать силу/жёсткость условий договора в зависимости от позиции в переговорах
  • Проверка на комплаенс: отсеивать риски заранее
• В конце

На какой-то техно-выставке я встретил руководителя по business development (BD), который как раз собирался работать в крупной компании. Но особенно то, что он сам взялся руками сделать набор внутренних систем для BD своей компании, используя ИИ. Он очень щедро достал телефон и показал мне прототип — так мы и смотрели, и разговаривали по ходу.

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

То, что он делает, на самом деле довольно точно бьёт по болевым точкам

Сначала он сразу поднял очень реальную проблему: у их BD-команды внешняя “разработка” слишком объёмная — настолько, что ни один руководитель не может переварить все отчёты всех людей ежедневно. Руководитель может отдавать только очень общие указания, из-за чего невозможно выстраивать точные тактики для каждого магазина, каждой точки. А ещё после того как BD “разбрасывает” задачи, очень легко, чтобы люди пересекались/сталкивались между собой, и синхронизировать прогресс друг с другом — при этом абсолютно неэффективно.

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

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

Честно говоря, это сразу видно: вещь сделана человеком, который реально понимает BD. Логика интерфейса не выдумана “с потолка” инженером — её можно придумать только после того, как сам ездил в поле и вёл продажи.

Речь о том, как он “встроил” ИИ

Я спросил его, и что именно тут делает ИИ. Он сказал, что подключил ИИ, который собрал в базу знаний всё, чем BD пользуется в внешней разработке: знания, прошлые договоры, кейсы сотрудничества.

Он привёл очень практичный пример: иногда BD “разрабатывает” сети брендов, но переговорные модели для сетевых договоров полностью отличаются от договоров с единичными магазинами. Сети масштабные и влиятельные — часто нужно делать обмен интересами. Но в процессе обучения обычным BD трудно чётко объяснить “какой величины контрагент” и “какие рычаги/козыри мы можем предложить в ответ”. Поэтому он поручил ИИ отвечать на этот вопрос. Мне кажется, точка входа выбрана очень удачно.

Я снова спросил, как он собрал базу. Он честно ответил: это просто деплой на Google Sheet, а JS читает напрямую. Но подчеркнул один момент: что именно посмотрел каждый BD и какой ответ дал ИИ — всё фиксируется, всё с трассируемостью. Он ещё заранее написал “определение для торговца”: ИИ сначала прогоняет определение, чтобы понять, какой тип у нового клиента, а потом возвращается и сопоставляет сотрудничество с кейсами.

Тут есть одна маленькая деталь, о которой я особенно хочу сказать. Я сказал ему, что у Gemini Flash в бесплатной версии есть “яма” — верхний лимит токенов может привести к результатам хуже ожидаемого. Он это заранее учёл: он заранее распланировал и “зашил” пути для каждой задачи — при каких вопросах читать только определённые вкладки. Это не только предотвращает пропуски, но и экономит время и токены. Такой подход “не пихать всё подряд, сначала оценить, потом забирать данные” действительно попадает в суть.

Но я думаю: Output можно сделать ещё больше

После этого я сказал ему одну довольно прямую фразу: “Твоё решение правда хорошее и очень соответствует вашему способу использования. Но — вкус ИИ тут ощущается не настолько сильно”.

Я не придираюсь: просто вижу, что есть ещё куда “играть”. Сейчас он по сути сделал так, что прошлые неочевидные, неконтролируемые и “неотыгрываемые назад” рабочие следы BD стали прозрачными, видимыми и управляемыми. Этот слой input он уже сделал очень крепким.

Но если смотреть как разработчик, мне кажется, что он застрял на output. Сейчас его результат почти весь сосредоточен в ChatBox и в разборе/сортировке данных. ChatBox — это, безусловно, хорошо, но я думаю, что его output можно отправлять намного шире, например:

Во-первых, выдавать напрямую документы в формате компании — такие как MOU, отчёты и т.п., а не заставлять людей сначала прочитать диалог и потом самим всё собирать. Во-вторых, использовать разные интерфейсы и процессы для разных задач: не всё нужно пихать в один и тот же диалоговый бокс. Базовый слой всё равно LLM, но можно под разные сценарии проектировать разных Agent: одна задача — один процесс.

С точки зрения юриста: есть одна вещь, которую обязательно нужно сделать — снизить галлюцинации

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

У меня собственная привычка: нельзя, чтобы в результатах от AI было хоть что-то, выдуманное “из воздуха”. Поэтому я предложил ему добавить две вещи:

Одна — цитирование с источниками. После каждого результата добавлять citation: чтобы по клику было видно, из какого документа и какого фрагмента это взято. Это для него, по сути, особенно важно: если BD берёт “аргументы/рычаги для переговоров”, которые выдал ИИ, и идёт в бой, но не может вернуться и подтвердить источник, то это уже рискованно — фактически в бой идут невалидированные данные.

Другая — снизить temperature. Чем больше сценарий требует точности и тем меньше права на “фантазии”, тем сильнее стоит подавить случайность модели. В паре эти два шага резко уменьшают пространство для галлюцинаций.

Несколько функций, которые, как мне кажется, его BD Agent может добавить

В их компании есть юристы/отдел правового сопровождения, а договоров обычно много стандартных, и их не слишком меняют. Казалось бы, тогда ИИ будто бы и некуда “влезать”. Но наоборот — мне кажется, что как раз в таких “стабильных” сценариях и есть, чем заняться. Я накидал ему несколько направлений на ходу:

2. Автоматически генерировать версии договоров по записям встреч

После того как BD провели переговоры, самое тяжёлое — превратить двухчасовое обсуждение в официальные пункты договора. ИИ тут хорош: он берёт стандартную заготовку, затем целиком “скармливает” записи встречи, и он генерирует новую версию по итогам; места, которые удалили/изменили, отмечаются tracking edits, и юристам сразу видно, где что трогали.

3. Настраивать силу/жёсткость условий договора в зависимости от позиции в переговорах

Мне кажется, это самое интересное, потому что это как раз связывается с логикой в его системе. Проблема стандартной заготовки в том, что она не отражает различие “силы” в каждом конкретном раунде переговоров. Когда переговоры с большой компанией — наша позиция слабее, значит условия должны быть более мягкими; когда переговоры с маленьким контрагентом — наша позиция сильнее, значит условия могут быть жёстче. Нет ни одного договора, который был бы “один на всех”: каждый нужно кастомизировать. Если его Agent сможет автоматически генерировать версии разной жёсткости в зависимости от масштаба контрагента, то разве это не станет продолжением его идеи в системе про “соответствие масштабов — соответствующее оружие”?

4. Проверка на комплаенс: отсеивать риски заранее

Контент, который BD публикует наружу, часто несёт комплаенс-риски. ИИ может помочь построчно: какие формулировки слишком преувеличены или слишком “в лоб”, какое правило/норма нарушается, что нужно удалить или добавить дисклеймер. Для BD-команды, которая каждый день “в поле”, такая способность “включать предохранитель заранее” реально полезна.

И я тоже напомнил ему: если у компании есть конкретные положения, которые они хотят сохранить, это не конфликтует. Формулировки можно менять, интонацию можно корректировать, но по сути права нашей стороны сохраняются — технически это полностью осуществимо.

В конце

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

Эти два с лишним месяца он делал одну и ту же вещь — искать болевые точки и искать моменты, куда ИИ реально можно “вклинить”. Я думаю, что именно такая настройка должна быть у человека, который хочет использовать ИИ: не “ИИ — крутой, давай поиграемся”, а “тут очень больно, может ли ИИ помочь остановить боль”.

В итоге: самый полезный ИИ обычно не самый “крутой/хвастливый”, а тот, который лучше понимает бизнес и ближе к реальным болевым точкам. Видя, как такой сильный BD начинает думать о своей работе в логике ИИ, я правда ожидаю, что он дальше сделает что-то ещё лучше.