INTENT
Продолжаем в свободное от работы время баловаться с LLM. На этот раз поговорим о ещё одном паттерне LLM-систем.
При создании LLM-продуктов, особенно важно добиваться бескомпромиссно простого и интуитивного взаимодействия с пользователем. Для этого интерфейс должен быть максимально простым с одной, максимум, двумя точками входа. Но как запихать много разного полезного с таким жёстким требованием? Вариант с десятью кнопками отпадает сразу, глаза будут разбегаться и лишние фрикции в UX убьют продукт. Ведь через месяц кнопок придётся делать 11, а через год уже 20. Вариант не масштабируемый от слова совсем.
В блоге "LLM под капотом" прочитал про такую штуку как классификация интентов. Богдан человек простой: узнал новое – бегом пробовать. Сегодня затестил интенты.
Классификация интентов – это буквально чтение мыслей пользователя. Идея тривиальная: "давайте пользователь будет нам писать обычные сообщения, как он писал бы живому человеку, а бот сам разберётся" – на входе будет стоять LLM, которая поймёт, о чем он просит, и перенаправит запрос на нужный специализированный модуль (где, скажем, стоит отдельный RAG под свою задачу).
Очень напомнило Traffic Router (маршрутизатор трафика) в арбитражных платформах, который по IP тебя вычислит и перенаправит ("приземлит тебя") на нужный лендинг.
P.S. Прикрепил пример как может выглядеть промпт для такого LLM-маршрутизатора: мы банально перечисляем все доступные на текущий момент режимы работы (c XML-тегами) и просим классифицировать запрос пользователя. Затем if "<intent>" in response и поехали.
Батут работает.
#LLMOps
SLEEP DEBT
Взялся восстанавливать сон. Скачал приложение RISE (раньше уже пользовался, был доволен как слон). Кроме анализа сна, приложение прогнозирует твои пики энергии в течение дня, даёт советы, какое время лучше выделять под Deep Work (с учётом сна и времени пробуждения), а какое под Shallow Work. Учитывает прием кофе, мелатонина, тренировки; даёт план как нормализовать сон и сдвинуть подъём к желаемому времени (говорит, во сколько согласно плану лучше сегодня готовить ко сну, с какого времени избегать кофеин). В общем, ещё много других полезных фишек.
В основе приложения лежит исследование, главный вывод из которого в том, что самый важный предиктор того, насколько хорошо мы будем перформить в течение дня, это не число REM фаз или что-то ещё, а банально Sleep Debt (буквально, "займ сна" или "нехватка сна"). У каждого человека есть необходимое время сна, которое можно померить. Чем ты больше от него отклонялся за последние 7 дней, тем хуже реализуешь свой энергетический потенциал.
На их сайте RISE есть целый Sleep Guide, который будет ценен и без приложения. Приложение уже геймифицирует процесс поддержания гигиены сна и персонализирует советы на основе собираемых данных о тебе. Highly recommended, не могу не поделиться таким золотом. Отдельное внимание заслуживает дизайн, с точки зрения UI/UX редко когда встречаю такие приятные игрушки.
P.S. Не удивляйтесь, если вскоре вслед за одним старшим главным начальником начну писать посты про матрасы.
https://botharetrue.substack.com/p/every-app-that-adds-ai-looks-like
Читать полностью…
RASMUSSEN SYSTEM MODEL
Например, в одном месте Грег делится ссылочкой на лекцию о том, как он мыслит о сложных системах со словами "I think this is the best (and only, really) framework I've seen on how to think about running a complex system". Лекция короткая, на 19 минут, и будет полезна любому инженеру и техническому менеджеру.
Идеи из лекции:
Сложная система адаптивна: её состояние в каждый момент времени "танцует" между тремя границами:
1. окупаемость (хватает ли нам денег её поддерживать?),
2. поддерживаемость (хватает ли нам рук её поддерживать?)
3. работоспособность (выдерживает ли нагрузку? учащаются ли ошибки, поломки, проблемы?)
Мы стремимся сделать систему дешевле (экономически эффективнее), отодвигая от границы окупаемости – и "автономнее", чтобы починка багов не отвлекала от добавления нового функционала. Обе эти оптимизации не даются бесплатно и ведут состояние системы – ближе к границе работоспособности (соответственно, система работает "на пике", значит, выше риск проблем).
Что же делать? Очерчивать пунктиром красные линии для допускаемой работоспособности? Вводить новые регламенты и субъективные ограничения перед физическими ограничениями?
Нет. Как сказано в начале, мы строим адаптивные системы, которые несмотря на желание сократить косты у менеджеров и на лень инженеров – на удивление работают и даже... относительно редко падают. Что обеспечивает эту адаптивность? – Люди.
Здесь мы приходим к важности мониторингов, алертов, опережающего реагирования, наконец, нашего собственного обучения по мере работы с системой. Это контрастирует с идеей, что достаточно наперёд просчитать на салфетке все нефункциональные требования, собрать систему по лекалу и закрыть сервера в бункере, чтоб никто не трогал.
P.S. Впрочем, не исключено, что через пару лет мы придём к практике навешивать пару-тройку LLM-агентов, завязанных на мониторинги и алерты, для оперативных починок и корректив наших систем, и тогда точно можно закрывать в бункерах!
https://www.youtube.com/watch?v=PGLYEDpNu60
Highly recommended.
Manager работает в совсем другом режиме: ему нужно быстро переключаться между большим количеством разных контекстов (разные отделы, разные задачи, разные люди). Его расписание может быть сильно более гранулярное и фрагментированное: 1 час в календаре = 1 час работы. В книге Cal Newport такая работа (где большая доля коммуникации, общения, обмена информацией) называется Shallow Work. Это не означает, что если вы руководитель, у вас 100% – это shallow work, так, когда вы занимаетесь написанием стратегии или подготовкой к конференции, то вы переключаетесь на роль Maker.
Самая частая проблема коммуникации между Manager и Maker происходит тогда, когда мы забываем, что мы живём и работаем в разных стилях. Так, одного получасового созвона в середине дня достаточно чтобы выбить инженера из колеи и перечеркнуть его план на день.
[Бонус] Мой персональный хак, который придумал буквально на днях: разбивать календари на два: один бесцветный (чтобы сливался с фоном), второй цветной (для deep work). Так ты сразу видишь, где цельные блоки глубокой непрерывной работы, а где остановки на коммуникацию (shallow work тоже важна, но в расписании Maker она должна занимать до 20%).
Ещё пара релевантных ссылок:
https://www.youtube.com/watch?v=ykNcnrNvpTI
https://www.youtube.com/watch?v=xJYlhhT7hyE
Новый месяц – новый дайджест итогов Симулятора ML! В сентябре у нас вышло целых три новых задачи, которые могут помочь подтянуть навыки для работы мечты. Давайте расскажем о них подробнее!
Читать полностью…
Напоминаю канал Генки, где вы можете найти для себя ещё больше практических знаний по всему что касается софт-скиллов, коммуникации, разборчивости в людях и многого другого:
/channel/MySocialCircle
https://twitter.com/karpathy/status/1707437820045062561
Читать полностью…
Soft-skills, связи, нетворкинг – вот это всё…
Два года назад, на свой юбилей, Я пригласил 15 друзей: каждый из них имеет свои уникальные черты, каждый спец в своём специфичном направлении. Было большое удовольствие перезнакомить их между собой и наблюдать, как они находят чем поделиться друг с другом.
Из них, с Игорем и Женей Я вас уже знакомил. Настала очередь Генки.
Генки – это человек, который уже инстинктивно знает, как находить подход к людям, независимо от их типажа, статуса и обстоятельств встречи – и умеет простым, доступным языком объяснить что произошло в каждую секунду коммуникации.
В прошлом он успел поработать партнёром event-агентств, арт-директором, UX дизайнером (помню, как-то мы приходили к мысли, что в дизайне для синьорного уровня тоже важнее уже не хард-скиллы, а оценивать эффект через A/B, понимать пользователей). В 23 он основал и затем продал модельное агентство [не знаю, как ему это удаётся!]. Позже поднял бюджетик на NFT и сейчас у него свой бизнес.
Словом, Генки из опыта знает, как работать с людьми, что такое построение доверительных отношений, партнерство, соц.круги, BizDev и грамотная коммуникация. Недавно он завёл телеграм канал, где делится своими наблюдениями и помогает развивать soft-скиллы другим.
Но на этом хорошие новости не заканчиваются. В эту субботу, в 18:00 по Москве мы проведём эфир «Софт-скиллы, связи, нетворкинг – вот это всё…», где обсудим как подходить к вопросу развития своих софт-скиллов, что становится всё более актуально сейчас, с появлением LLM, когда хард-скиллы всё меньше становятся бутылочным горлышком, а понимать людей (коллег, пользователей, партнёров) – всё больше.
Пишите в комментарии вопросы, которые вы бы хотели, чтобы мы с Генки обсудили во время эфира.
Вышла девятая глава книги «Machine Learning System Design with end-to-end examples» Валеры Бабушкина и Арсения Кравченко, Error Analysis, в написании которой ваш покорный слуга принимал участие, и по мотивам которой написана недавняя статья на Хабре.
В главе вы узнаете, в какой момент пора бомбить датацентры, в также как вашей ML системе стать LessWrong.
По ссылочке можно получить ранний доступ к уже вышедшим главам и оперативно получать новые по мере их публикации: https://www.manning.com/books/machine-learning-system-design
Про читабельный код 2/2
Чтобы не тянуть кота за хвост, сразу же брошу пару-тройку рекомендций, пока они у Меня в голове. Особенно будут особенно полезны начинающим специалистам, но может и матёрым волкам что-то из этого пригодится.
1. Выступление автора библиотеки Keras, "The Secrets of Productive Developer Tools"
Идея: писать код, фокусируясь на том, кто его будет использовать и как; думать о UX, который ты задаёшь своим кодом (какой workflow?); параметры и наименования должны отражать что пользователь твоего кода получает, а не как этот код реализован (мысль тривиальная, но...)
2. Книга Егора Бугаенко, "Elegant Objects"
Идея: "уважать" объекты, воспринимать их как автономные сущности с которыми можно и нужно взаимодействовать, а не как набор переменных, сброшенных в одну кучу (откуда всегда можно что-то взять или положить через сеттеры и геттеры); когда мы что-то хотим получить от объекта, мы должны попросить (делегировать), а не микроменеджерить объекты, вмешиваясь в их логику работы и отдельно диктуя что с чем сделать.
В частности, автор пропагандирует, что все процедуры должны быть глаголами (действиями), а все функции (когда что-то возвращается) – существительным или существительным с прилагательным. Почему? Названием функции мы описываем что пользователь получит.
Аналогия: что когда мы приходим в ресторан, мы говорим, "Мне, пожалуйста, латте" (latte) – называешь, что хочешь получить. Мы не говорим "заварите Мне латте" (brew_latte) или "принисите Мне латте" (get_latte). N тем более мы не идём на кухню, диктовать баристе в какой питчер заливать молоко. Это было бы странно. Но в среднестатистическом коде подобное встречается тут и там.
Собственно, даже если вы пишите MVP на коленке, говнокодя как последний подонок, хотя бы заботьтесь о внятном именовании с понятной логикой. Нормальные именования – это уже залог 80% читабельности кода.
ERROR ANALYSIS
Опубликована Моя вторая статья на Хабре, «Почему анализ ошибок – это начало разработки ML системы, а не её конец?».
Первая статья называлась «10 первый ошибок в карьере ML инженера». Расскажу об 11-ой ошибке в своей карьере, а именно, воспринимать анализ ошибок как финишную черту перед первым A/B, этап для галочки.
Включение анализа ошибок в пайплайн, сбор первых артефактов – это по сути замыкание цепочки обратной связи, когда мы готовы пустить ток (данные) по сети (пайплайну) первый раз и получить самый ранний фидбек (Я расскажу, почему одной валидации мало).
Так мы получаем baseline ML системы (по аналогии с MVP) и переходим к итеративному циклу доработок, отладок, экспериментов и усложнения.
А как именно проводить анализ ошибок, вы узнаете в самой статье. Приятного чтения: https://habr.com/ru/articles/760550/
P.S. Выражаю благодарность коллегам, внёсшим прямой или косвенный вклад в содержание этой статьи за время нашей совместной работы: Андрею Кулагину, Юре Гаврилину, Арсению Кравченко, Валере Бабушкину.
Your thoughts? https://www.youtube.com/watch?v=srgBBxGzOU8
Читать полностью…
Идея простая:
Подготовка:
1. Берётся база знаний как некий набор текстов (documents). Тексты бьются на кусочки, скажем, по 64 или 128 токена (их называют чанками или нодами).
2. Каждый кусочек текста прогоняем через некоторую маленькую вспомогательную предобученную модель (embedding model), которая трансформирует каждый кусочек в вектор ("смысл кусочка", или на инженерском, эмбеддинг).
3. Эти вектора (и исходные кусочек текста и документ откуда они взяты) складываются в некое хранилище, которое называется "векторной базой данных" или "индексом".
Инференс:
1. Retrieval. От пользователя приходит запрос или вопрос. С помощью всё той же вспомогательной модели превращаем его в вектор, находим 2-3-5 самых похожие: либо напрямую, через kNN (k nearest neighbors, k ближайших соседей), либо через ANN (approximate nearest neighbors, приближённый поиск ближайших соседей) – на случай если база знаний очень большая и точный поиск затруднён.
2. Далее с найденными релевантными кусочками текста можно делать что угодно: можно вытащить весь исходный документ (особенно если они небольшие, скажем, по 500-1000 токенов), можно вытащить некую окрестность ближайших кусочков токена в том же документе, в котором нашли данный.
3. Наконец, формулируем промпт для базовой модели (GPT): вставляем исходный вопрос, далее говорим, мол, "вот что тебе может пригодиться при ответе" (ставить подтянутый контекст до или после – сильно зависит от ваших юзкейсов, подумайте, почему), – и далее случается магия, при генерации своего ответа теперь GPT будет опираться на наш контекст из базы знаний, какого бы размера она не была.
Впервые Я услышал эту идею в лекции Игоря Котенкова про модель RETRO (Retrieval-Enhanced Transformer) от DeepMind из статьи "Improving language models by retrieving from trillions of tokens".
Завести описанный пайплайн несложно, это займёт у вас не больше 1 вечера. Ваши друзья здесь: LlamaIndex и LangChain, под это дело там и там есть специальные утилиты, если не сориентируетесь – у них есть языковая модель поверх... документации, которая тоже работает по описанному принципу. Задайте вопрос – и она поможет найти и разобраться.
P.S. Как-то Александр Дьяконов пошутил, что лучший алгоритм в машинном обучении – это kNN, а остальные модели – это попытки его аппроксимировать, нивелировав те или иные недостатки. Тут же мы прямо возвращаемся назад к истокам.
Эмоциональный интеллект (EQ). Что для Вас означает эмоциональный интеллект, какой смысл Вы вкладываете? Как бы Вы оценили свой эмоциональный интеллект от 0 до 10? Как он менялся с течением времени? Над каким его аспектом, Вы думаете, Вам нужно больше работать?
Читать полностью…
LOGBOOK
Читаю Logbook по OPT-175B – документ, состоящий из сырых ежедневных заметок, которые писали инженеры по мере обучения модели. Он содержит статус-апдейты, возникшие проблемы и принятые решения по их починке, неожиданные находки, рекомендации и т.д.
Для понимания, тренировка модели заняла порядка 3 месяцев и длилась с 20 октября 2021 по 6 января 2022.
https://github.com/facebookresearch/metaseq/blob/main/projects/OPT/chronicles/OPT175B_Logbook.pdf
Logbook ценен с многих точек зрения:
1. Во первых, он отвечает на вопрос, а что такого сложного в обучении LLM (после того как архитектура модели зафиксирована)?
2. Во вторых, он даёт адекватное понимание, чем наполнены будни инженера из топовых персентилей. Вообще, было бы клёво иметь подобные логи по разработки разного типа и масштаба систем. Но их почти никто не ведёт. 🙃
3. В третьих, интересна сама дисциплина документировать всё что делаешь и логировать решения которые принимаешь (прямо как NPC в игре Sims – в углу экрана всегда видишь, а о чём он сейчас подумал, а куда он сейчас решил пойти, что сделать). Насколько Я знаю, в серьёзных местах вроде того же OpenAI и Anthropic эта практика весьма распространена.
Это позволяет другим быстро понять, а что было сделано, уловить контекст, понять, какие гипотезы попробованы, что лежало в основе тех или иных решений в дизайне системы (аналогично, можно вести логи менеджерских решений).
____
Сам Я последнее время (пока для себя), стал тоже всё чаще вести логи того, что делаю, какое препятствие встретил, в чем, как думаю, проблема, какая гипотеза по её решению и т.д. Это помогает входить в поток, одновременно проясняя разум, и в конце дня – оставляет артефакт прогресса который ты сделал за день. Логи веду в Session (приложение для трекинга времени, суммарно подобными штуками пользуюсь последние лет 6 на ежедневной основе). Заметки открываются прямо во время начала сессии, сразу удобно накидывать мысли.
Так, а вы балуетесь подобным?
Вчера вечером перед сном читал блог Грега Брокмана –сооснователя и президента OpenAI (ранее CTO в Stripe). Некоторые его называют главным кодером в OpenAI.
Рекомендую прогуляться и вам:
• Его проекты до/в OpenAI (+ полезные ссылки)
• Его блог (часть постов в соавторстве с Ильёй)
#OpenAI
MAKER'S SCHEDULE, MANAGER'S SCHEDULE
Наткнулся на старенький пост Пола Грэма "Maker's Schedule, Manager's Schedule". Пол Грэм – это сооснователь Y Combinator и один из людей, оказавших наибольшее влияние на Сэма Альтмана, наравне с Илоном Маском (Сэм – СEO в OpenAI и бывший президент Y Combinator)
В посте вводятся Maker Schedule и Manager Schedule. Позже этот концепт в книге "Deep Work" некто Cal Newport опишет как Deep Work vs Shallow Work.
Maker – это инженер, писатель, программист, дизайнер и любой другой "ремесленник", работа которого требует глубокого и длительного погружения в один контекст (Deep Work). Как правило, такая работа происходит в одиночестве, хотя есть исключения (пример: командный брейншторм). Такая работа требует держать в голове большой контекст с разными взаимосвязями, чтобы очень точно что-то выполнить, создать или починить – и смывается в унитаз от малейшего отвлечения (сообщения, звонка, проверки новостей и т.д.).
Когда Maker планирует день, он смотрит в первую очередь "а сколько непрерывных часов работы у Меня есть до такого-то времени?" – нам желательно выделять по 4, лучше по 6-8 часов подряд, потому что нельзя сделать что-либо серьёзное, если у тебя всего 2-3 часа... скажем, между звонками. Ведь любая Deep Work сессия требует войти в поток. Чтобы только "войти в поток", т.е. вспомнить / открыть / собрать воедино в своей голове весь нужный для задачи "контекст", нужно минимум 40-60 минут.
P.S. Когда Я пишу сотруднику и он недоступен, Я даже радуюсь – значит, он по-настоящему работает. 😘
FLOWMODORO
Заметки, как Богдан фокусируется на работе, упакованные с помощью ChatGPT. Обсудим технику Flowmodoro: как Vision превращается в стратегию, стратегия в план, план в задачи, задачи в подзадачи, подзадачи в "помидорки", помидорки в "поток", а поток – в долгосрочный momentum.
#MyProtocols
Eliminate inauthentic goals and desires with these six questions:
1. Do I actually desire this? Or do I just desire what it looks like?
2. What’s the core work involved, and can I see myself doing that work every day for years?
3. If I ended up hating this, what would be the reason?
4. Is there something external that prompted this desire? (e.g., a tweet thread, book, influencer, podcast)
5. Am I suffering from recency bias? (You recently saw something that inspired the desire, and because it’s recent it feels more authentic)
6. If someone gave me a billion dollars right now, would I still pursue this? If not, what would I do instead?
smatla">– Sam Matla
Если бы вас попросили выбрать один единственный самый важный софт-скилл, какой бы вы назвали?
Читать полностью…
3. Инструменты:
• black – автоматическое форматирование кода (any color you like, as long as it's black); очень помогает не париться и не спорить насчёт того, какое форматирование сделать в вашем проекте, когда есть источник непреложной истины, сам форматирующий всё в единый стиль.
• pre-commit – автоматически делает что-то с вашим кодом перед коммитом (например, прогоняет тот же black, линтеры, сортирует импорты, проверяет что все файлы короче 4096 токенов 🤡 и т.д.)... дисциплинирует.
• typing (а для самых извращенцев, mypy) – хоть Python и язык с динамическое типизацией, но не писать типы у функций и параметров – это какое-то неуважение к своим коллегам и к своему коду, игра в угадайку. Нормальное наименование
• pylint / flake8 / sonarlint – линтеры это штуки которые автоматически находят баги, опечатки, нарушения PEP8 и другие проблемы, понижающие качество кода. Все линтеры доступны как плагины в VSCode. Если есть возможность, ставьте SonarQube – так у вас на каждый коммит в merge request будет прилетать портянка замечаний, возможных уязвимостей кода, местах со сложной логикой и т.д.
Напишите в комментах, какие ещё знаете приёмы карате или годные источники на тему.
Про читабельный код 1/2
10 лет назад, когда Я участвовал в краевых олимпиадах по программированию, Я подобрал одну цитату у одного из тренеров, которой люблю щеголять по сей день:
Писать код, который поймёт машина – может любой дурак.
Писать код, который поймёт другой человек – вот это искусство.
В конце концов, код – это не только инструмент, заставляющий биты и байты работать на нас, это в том числе средство коммуникации. Это тоже часть продукта, у которого есть свои пользователи (нынешние и будущие коллеги), которым хорошо бы при необходимости за минимальное время разобраться в том, что вы написали, и внести соответствующие коррективы.
Я человек ленивый, поэтому сейчас, когда Мне что-то надо быстро дописать или поправить, Я в первую очередь пробую копи-пастнуть весь файл в GPT-4, сказать, сделать – и получить желаемое изменение в нужном месте. Иногда, требующее косметических доработок. Годы прошли и теперь нам опять важнее, чтобы наш код понимала машина. Но у этой машины есть одно маленькое ограничение: длина контекста.
Поэтому Я официально ввожу новый паттерн хорошего кода: Размер любого файла в проекте не должен превышать 4096 токенов.
P.S. К слову, это вполне внятный критерий, по которому можно определить в какой момент ту или иную сложную логику инкапсулировать в отдельные объекты.
Mochary Method
Существует такой персонаж, Matt Mochary, коуч для CEO. Его очень рекомендует Sam Altman (CEO, OpenAI):
"Matt’s coaching has brought me clarity, focus, organization, less stress, higher performance (me and the team). I have always been skeptical of coaches but I think he can 10x the output of a lot of people and I hope he does!"
У Matt Mochary есть Mochary Method Curriculum, это открытая база знаний по всевозможным темам, с которыми фаундеру необходимо сталкиваться в работе: как строить компанию, организовывать встречи (включая 1:1), как слушать, как принимать решения, ставить цели, нанимать, мотивировать, оптимизировать, расти, работать над ошибками – и много чего ещё. Все знания разбиты на короткие заметки по 2-5 минут чтения. Со слов Matt, эти заметки покрывают 95% его тренинга. Я рекомендую их чтение любому, кто даже только начинает пробовать себя в менеджерской роли.
Впервые этими заметками со Мной довольно давно поделился Игорь, автор канала Сиолошная. Но почему Я вспомнил о них сегодня?
Решил Я, значит, натравить вчера на эти заметки пайплайн с языковой моделью поверх базы знаний, который собирал под другой проектик, заглядываю на сайт, а там... это уже сделано, притом в клёвом интерфейсе. Впрочем, это было ожидаемо, раз уж Sam Altman оказался на лендинге сайта! 😧
Соответственно, highly recommended (Matt AI):
https://beta.mocharymethod.com/matt_bot
Только что открыл для себя ChatPDF, хоть и слышал давно. Позволяет загружать любой PDF, например, статью, резюме кандидата, презентацию или целую книгу – и терроризировать вопросами. И конечно, работает по принципу Retrieval Augmented Generation (RAG), о котором написал вчера.
Нравится.
RAG: Retrieval Augmented Generation
Значит, дошли у Богдана руки наконец сделать один проектик с чат-ботом поверх базы знаний. Кто уже работал с knowledge-augmented chatbots – зову в комментарии похвастаться, какой самый крутой конструктор лего собирали. Кто не работал – расскажу как это заводить.
Проблема следующая: у ChatGPT, как и у других больших языковых моделей, контекст ограничен. Например, у GPT-3.5 он 4K токенов, у GPT-4 он 8К токенов (кто не знает, токен – это символ, или часть слова; посмотреть, на какие запчасти ChatGPT разбирает ваш промпт перед ответом, можно здесь; в английском 1000 токенов ≈ 750 слов). Размер контекста – это сколько текста может переварить модель перед ответом. Ясно, что в такое малое число токенов не запихать какую-то большую, длинную и специализированную базу знаний, с оглядкой на которую мы хотим чтобы модель отвечала.
Какие варианты решения проблемы?
Вариант №1 (долго-дорого-сложно): дообучить модель на свои данные
Вариант №2 (быстро-дёшево-легко): подтягивать релевантные контексты по запросу.
Естественно, нас интересует второй вариант. Как он работает?
