Согласен с идеей. Остановило меня от такой реализации необходимость различать одинаковые значения в индексах для последующего удаления. Ведь после разлияния (особый кейс, обусловленный бизнес-требованиями) ссылки из индексов нужно удалить.
Ссылка в индексе, как вы написали, - пара ключ (строка) и значение, на ключ нельзя сделать ссылку для удаления извне, можно только двоичным поиском найти. Если будут две одинаковые строки, ссылающиеся на разные мастера, их можно проверить перебором. А если больше, то это уже может константу увеличить для операции разделения.
Здесь, конечно, вопрос к тому, как часто раздения происходят. Возможно, этим "усложнением" удаления ссылки можно пренебречь.
А вообще, меня ваш комментарий навёл на мысль, что переход к раздельным индексам позволит избежать удаления ссылок во время слияния. Ведь теперь можно при слиянии в паре ключ-значение менять только значение, указывать вместо старого на нового мастера. А в текущей реализации нужно ссылку из составного индекса удалять и новые ссылки создавать и вставлять, так как комбинации полей меняются в новом мастере.
Хорошее замечание по поводу разделения индексов. Я много думал об этом улучшении, но довести до логического завершения не смог. Остановило вот что.
Чтобы обеспечить возможность в индекс добавить одинаковые значения, пришлось "приклеивать" в конце полей порядковый номер. Иначе ссылаться на эти значения невозможно, потому что они одинаковые.
У последнего значения в правиле всегда в такой реализации есть суффикс, например, -1, -2... Если разделить индексы составные на индексы по полям, то такой суффикс должен быть у последнего в правиле поля в отдельном индексе и не быть в других полях.
Однако, поля в разных правилах могут быть в разных местах. Не обязательно ФИО при концевой позиции в одном правиле будет в конце в другом. Тогда в случае присутствия поля в разных местах в нескольких правилах, в индекс попадут значения как с суффиксом, так и без.
Такое смешение ведёт к разрушению парадигмы: в каких-то случаях нужны значения только без суффиксов, а в других - только с суффиксами.
Если у вас есть идеи, как это обойти, я буду очень рад предложениям. Потому что это существенно уменьшило бы константу, как вы точно заметили.
В оценке я, действительно, сомневаюсь. Меня подтолкнула к выбору такого пути рассуждений длительность выполнения алгоритма на практике. Вернее, её зависимость от входных данных. Она совершенно точно меньше квадратичной, и больше линейной :)
Если мы слегка переформулируем алгоритм, станет очевидно, что никакого произведения нет. Пусть у нас изначально есть текущий набор снепшотов и мастеров. Теперь мы хотим добавить новый снепшот в набор. Мы создаем для него отдельный мастер и далее M раз ищем другого мастера, связанного с текущим каким-то правилом, объединяем эти два мастера и переходим к следующей итерации. Поэтому в асимптотике везде нужно опустить M из степени в обычный множитель.
И с вашим подходом я совершенно согласен. Я думал о нём как альтернативе. Но не смог додуматься вот до чего.
В нём нужно оценить число таких слияний. M выглядит зависимой от n, так как каждое объединение порождает генерацию новых значений в индексах. Новые значения в индексах влияют на потенциальные следующие слияния. Так получается, что одно слияние порождает другие. M оставить константой было бы грубым приближением.
Оценить M трудно. Мне хотелось сначала в статье написать, что это число экспоненциально зависит от n, так как количество новых записей в индексах на каждом слиянии имеет экспоненциальную зависимость. Но в какой-то момент я понял, что эта зависимость не от n, а от числа параметров в правиле.
На этом моя цепочка мыслей обрывается, не могу сообразить связь между M и n в таком подходе. Но и интуиция её присутствия меня не покидает. Поэтому оценка в статье из другого подхода, где связать слияния удалось.
Не во всех продуктах на входе пользователь указывает номер телефона. И это главная проблема, которую мы решаем, вы верно заметили. Если бы был номер телефона во всех снепшотах, было бы гораздо проще.
Бывает иногда, что муж и жена указывают одинаковый номер телефона. Скорее всего для нас они будут одним человеком после объединений.
Но самый частый пример - это опечатки, как ни странно... Операторы при вводе данных под диктовку ошибаются, и если объединять только по номеру телефона, получаются "Франкенштейны". Заметить такие ложные слияния по практике очень сложно, поэтому мы и используем несколько полей в правилах
В корне своего замечания вы абсолютно правы. Будь бизнес-требования "более математичными", реализация была бы существенно проще. Однако, как оказывается, реальность состоит из ньюансов.
Справедливо. Спасибо за мнение. В режиме A/B тестирования запустим кнопку, посмотрим на отзывы. Вообще, да, любой дополнительный шаг во взаимодействии с клиентом снижает "конверсию". Ответ хочется получить сразу. У нас в этом вопросе ещё большое поле для исследования и проведения опытов впереди...
Согласен с вашими замечаниями, очень в точку. Отвечу по пунктам:
5% неправильных ответов в подавляющем большинстве связаны с неоднозначностью постановки вопроса. Например, клиент не уточняет продукт, по которому задаёт вопрос. Или может быть формулировка: "Хочу красиво."
Над улучшением "понимания" предстоит поработать довольно плотно. На пилоте во время тестирования в качестве быстрого решения мы добавили кнопки "нравится ответ" и "не нравится ответ". Когда не нравится, переключаем на оператора. Это наивно, и в продакшн выпускать это не собираемся, потому что слишком высок риск, как Вы сказали, испорченного пользовательского опыта.
Следующий шаг - это в качестве ответов писать не напрямую клиенту в чат, а в систему обработки обращений UseDesk. Так мы оставляем в процессе человеческую супервизию. Оператор в начале работы с обращением сразу видит предлагаемый моделью ответ. Если ответ правильный, просто нажимает кнопку "ответить". Если нет, пишет свой вариант, а мы собираем данные для выстраивания новых связей вопрос-ответ. Планируем следить за динамикой количества неправильных ответов. В какой-то момент или периодически будем возвращаться к оценке рисков с учётом вероятности неправильного ответа.
Ещё одна идея - в чат-боте сделать выбор категории вопроса или хотя бы продукта. Это позволит существенно снизить неоднозначность. Мы частично уже подтвердили эту гипотезу, но ещё работаем над оцифровкой результатов.
ИИ в нашем решении, скорее, выполняет функцию семантического поиска по базе знаний. В Confluence либо ищет оператор глазами, либо наша система. Других способов, например, захардкоженных или алгоритмических ответов у нас нет. Пытались сделать, но увязли в экспоненциально растущем числе правил. В качестве метрики на первых порах мы использовали удовлетворённость отдела поддержки. Коллеги, которые непосредственно сами отвечают на вопросы клиентов, делают супервизию ответов модели в формате "правильно-неправильно".
Вопрос с выбором между точностью и вариативностью с человечностью, скорее, можно перевести в плоскость вопросов. Наше решение позволяет в довольно произвольной форме задать вопрос, и получить на него релевантный ответ "на языке" формулировки вопроса. В классических системах (на правилах), где есть алгоритм, в качестве движка для поиска обычно используется лексический поиск. Чуть изменится формулировка вопроса - получается промах мимо правила.
У меня есть интуиция, что в итоге наше решение придёт к гибридному формату. Когда правила срабатывают не по лексическому, а по семантическому поиску. Примером такого правила может быть: "Если клиент спрашивает про оформление ипотеки, уточнить, на вторичное или первичное жильё." Семантический поиск в вопросе легко вычленит смысл "про ипотеку", даже если в вопросе сказано "займ на приобретение жилья". Это будет на первых этапах общения. До тех пор, пока продукт и/или направление обсуждения не будет достаточно однозначно выяснено. Дальше, наверное, продолжать можно будет без правил.
В качестве метрики по фактологической точности, когда дойдёт до автоматизации, мы планируем использовать тот же семантический поиск. Точнее, "семантическую близость" как его результат. У нас сотни типовых вопросов от поддержки, на которые есть человеческие ответы. Всё это собрано в одном файле. Планируем расширить до тысяч. В качестве автотетста мы можем прогнать модель по всем этим вопросам. И каждый ответ модели сравнить с человеческим ответом на предмет схожести выраженного смысла.
Дальше можно играть со статистикой, чтобы получить некую "среднюю правильность". И решить, устравивает ли нас, или оставляем всё через человеческую супервизию.
Исчерпывающий пейпер по RAG - методу работы с внешними базами знаний для LLM, - на базе которого строится подход, описанный в этой статье.
https://arxiv.org/pdf/2312.10997.pdf
Согласен с идеей. Остановило меня от такой реализации необходимость различать одинаковые значения в индексах для последующего удаления. Ведь после разлияния (особый кейс, обусловленный бизнес-требованиями) ссылки из индексов нужно удалить.
Ссылка в индексе, как вы написали, - пара ключ (строка) и значение, на ключ нельзя сделать ссылку для удаления извне, можно только двоичным поиском найти. Если будут две одинаковые строки, ссылающиеся на разные мастера, их можно проверить перебором. А если больше, то это уже может константу увеличить для операции разделения.
Здесь, конечно, вопрос к тому, как часто раздения происходят. Возможно, этим "усложнением" удаления ссылки можно пренебречь.
А вообще, меня ваш комментарий навёл на мысль, что переход к раздельным индексам позволит избежать удаления ссылок во время слияния. Ведь теперь можно при слиянии в паре ключ-значение менять только значение, указывать вместо старого на нового мастера. А в текущей реализации нужно ссылку из составного индекса удалять и новые ссылки создавать и вставлять, так как комбинации полей меняются в новом мастере.
Спасибо большое за ваши идеи!
Да, вы абсолютно правы. Моя ошибка. Очевидным это становится в имплементации:
https://github.com/Evgeny-Mamaev/dedu/blob/b253fbe048b41c1bd1bbdad4062f19815e0902e1/deduplicator.py#L534
n * log^m(n) превращается в n * log(n).
Хорошее замечание по поводу разделения индексов. Я много думал об этом улучшении, но довести до логического завершения не смог. Остановило вот что.
Чтобы обеспечить возможность в индекс добавить одинаковые значения, пришлось "приклеивать" в конце полей порядковый номер. Иначе ссылаться на эти значения невозможно, потому что они одинаковые.
У последнего значения в правиле всегда в такой реализации есть суффикс, например,
-1,-2... Если разделить индексы составные на индексы по полям, то такой суффикс должен быть у последнего в правиле поля в отдельном индексе и не быть в других полях.Однако, поля в разных правилах могут быть в разных местах. Не обязательно ФИО при концевой позиции в одном правиле будет в конце в другом. Тогда в случае присутствия поля в разных местах в нескольких правилах, в индекс попадут значения как с суффиксом, так и без.
Такое смешение ведёт к разрушению парадигмы: в каких-то случаях нужны значения только без суффиксов, а в других - только с суффиксами.
Если у вас есть идеи, как это обойти, я буду очень рад предложениям. Потому что это существенно уменьшило бы константу, как вы точно заметили.
В оценке я, действительно, сомневаюсь. Меня подтолкнула к выбору такого пути рассуждений длительность выполнения алгоритма на практике. Вернее, её зависимость от входных данных. Она совершенно точно меньше квадратичной, и больше линейной :)
И с вашим подходом я совершенно согласен. Я думал о нём как альтернативе. Но не смог додуматься вот до чего.
В нём нужно оценить число таких слияний. M выглядит зависимой от n, так как каждое объединение порождает генерацию новых значений в индексах. Новые значения в индексах влияют на потенциальные следующие слияния. Так получается, что одно слияние порождает другие. M оставить константой было бы грубым приближением.
Оценить M трудно. Мне хотелось сначала в статье написать, что это число экспоненциально зависит от n, так как количество новых записей в индексах на каждом слиянии имеет экспоненциальную зависимость. Но в какой-то момент я понял, что эта зависимость не от n, а от числа параметров в правиле.
На этом моя цепочка мыслей обрывается, не могу сообразить связь между M и n в таком подходе. Но и интуиция её присутствия меня не покидает. Поэтому оценка в статье из другого подхода, где связать слияния удалось.
Это ответ на первую часть вашего сообщения :)
Не во всех продуктах на входе пользователь указывает номер телефона. И это главная проблема, которую мы решаем, вы верно заметили. Если бы был номер телефона во всех снепшотах, было бы гораздо проще.
Бывает иногда, что муж и жена указывают одинаковый номер телефона. Скорее всего для нас они будут одним человеком после объединений.
Но самый частый пример - это опечатки, как ни странно... Операторы при вводе данных под диктовку ошибаются, и если объединять только по номеру телефона, получаются "Франкенштейны". Заметить такие ложные слияния по практике очень сложно, поэтому мы и используем несколько полей в правилах
В корне своего замечания вы абсолютно правы. Будь бизнес-требования "более математичными", реализация была бы существенно проще. Однако, как оказывается, реальность состоит из ньюансов.
Спасибо, пошёл изучать ещё одного представителя семейства верблюдовых)
Справедливо. Спасибо за мнение. В режиме A/B тестирования запустим кнопку, посмотрим на отзывы. Вообще, да, любой дополнительный шаг во взаимодействии с клиентом снижает "конверсию". Ответ хочется получить сразу. У нас в этом вопросе ещё большое поле для исследования и проведения опытов впереди...
Согласен с вашими замечаниями, очень в точку. Отвечу по пунктам:
5% неправильных ответов в подавляющем большинстве связаны с неоднозначностью постановки вопроса. Например, клиент не уточняет продукт, по которому задаёт вопрос. Или может быть формулировка: "Хочу красиво."
Над улучшением "понимания" предстоит поработать довольно плотно. На пилоте во время тестирования в качестве быстрого решения мы добавили кнопки "нравится ответ" и "не нравится ответ". Когда не нравится, переключаем на оператора. Это наивно, и в продакшн выпускать это не собираемся, потому что слишком высок риск, как Вы сказали, испорченного пользовательского опыта.
Следующий шаг - это в качестве ответов писать не напрямую клиенту в чат, а в систему обработки обращений UseDesk. Так мы оставляем в процессе человеческую супервизию. Оператор в начале работы с обращением сразу видит предлагаемый моделью ответ. Если ответ правильный, просто нажимает кнопку "ответить". Если нет, пишет свой вариант, а мы собираем данные для выстраивания новых связей вопрос-ответ. Планируем следить за динамикой количества неправильных ответов. В какой-то момент или периодически будем возвращаться к оценке рисков с учётом вероятности неправильного ответа.
Ещё одна идея - в чат-боте сделать выбор категории вопроса или хотя бы продукта. Это позволит существенно снизить неоднозначность. Мы частично уже подтвердили эту гипотезу, но ещё работаем над оцифровкой результатов.
ИИ в нашем решении, скорее, выполняет функцию семантического поиска по базе знаний. В Confluence либо ищет оператор глазами, либо наша система. Других способов, например, захардкоженных или алгоритмических ответов у нас нет. Пытались сделать, но увязли в экспоненциально растущем числе правил. В качестве метрики на первых порах мы использовали удовлетворённость отдела поддержки. Коллеги, которые непосредственно сами отвечают на вопросы клиентов, делают супервизию ответов модели в формате "правильно-неправильно".
Вопрос с выбором между точностью и вариативностью с человечностью, скорее, можно перевести в плоскость вопросов. Наше решение позволяет в довольно произвольной форме задать вопрос, и получить на него релевантный ответ "на языке" формулировки вопроса. В классических системах (на правилах), где есть алгоритм, в качестве движка для поиска обычно используется лексический поиск. Чуть изменится формулировка вопроса - получается промах мимо правила.
У меня есть интуиция, что в итоге наше решение придёт к гибридному формату. Когда правила срабатывают не по лексическому, а по семантическому поиску. Примером такого правила может быть: "Если клиент спрашивает про оформление ипотеки, уточнить, на вторичное или первичное жильё." Семантический поиск в вопросе легко вычленит смысл "про ипотеку", даже если в вопросе сказано "займ на приобретение жилья". Это будет на первых этапах общения. До тех пор, пока продукт и/или направление обсуждения не будет достаточно однозначно выяснено. Дальше, наверное, продолжать можно будет без правил.
В качестве метрики по фактологической точности, когда дойдёт до автоматизации, мы планируем использовать тот же семантический поиск. Точнее, "семантическую близость" как его результат. У нас сотни типовых вопросов от поддержки, на которые есть человеческие ответы. Всё это собрано в одном файле. Планируем расширить до тысяч. В качестве автотетста мы можем прогнать модель по всем этим вопросам. И каждый ответ модели сравнить с человеческим ответом на предмет схожести выраженного смысла.
Дальше можно играть со статистикой, чтобы получить некую "среднюю правильность". И решить, устравивает ли нас, или оставляем всё через человеческую супервизию.