Experimenting with LLMs to Research, Reflect, and Plan

eugeneyan

eugeneyan

Начать здесь Тексты Выступления Прототипирование Обо мне

Experimenting with LLMs to Research, Reflect, and Plan

Эксперименты с LLM для исследований, рефлексии и планирования

[ llm deeplearning learning 🛠 🔥 ] · 14 min read

[ llm deeplearning learning 🛠 🔥 ] · 14 мин чтения

Over the past few weekends, I’ve been playing with large language models (LLMs) and combining them with tools and interfaces to build a simple assistant. Along the way, I noticed some issues with retrieval and thought of a few ideas on how to solve them.

Несколько последних выходных я возился с большими языковыми моделями (LLM) и собирал из них вместе с инструментами и интерфейсами простого ассистента. По ходу дела я заметил проблемы с поиском и придумал несколько идей, как их решить.

It was a lot of fun, and I came away from this experience optimistic that LLMs have great potential to augment how we work, especially how we research, reflect, and plan.

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

Here’s the code to speed run this. It’s messy and relies largely on LangChain abstractions. Could be useful as a reference, but not as learning material.

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

Tools to summarize, query, and advise

Инструменты для суммаризации, запросов и советов

My first project was inspired by Simon’s post on how ChatGPT is unable to read content from URLs. Thus, I tried to help it do just that with /summarize and /eli5. The former can /summarize content from URLs into bullet points while the latter reads the content and explains like I’m five (eli5). They help me skim content before deciding if I want to read the details in full (tweet thread).

Мой первый проект был вдохновлён постом Simon о том, что ChatGPT не умеет читать содержимое URL. Я попробовал помочь ему это сделать с помощью /summarize и /eli5. Первая команда умеет /summarize сжимать содержимое URL в маркированный список, а вторая читает его и объясняет так, будто мне пять лет (eli5). Они помогают мне бегло оценить контент и решить, стоит ли читать его полностью (тред в твиттере).

Bullet point summary of "ChatGPT Is a Blurry JPEG of the Web"

Краткое содержание в виде списка для «ChatGPT Is a Blurry JPEG of the Web»

Explaining to a five-year old "ChatGPT Is a Blurry JPEG of the Web"

Объяснение пятилетнему ребёнку «ChatGPT Is a Blurry JPEG of the Web»

Next, I explored building agents with access to tools like SQL and search. /sql takes natural language questions, writes and runs SQL queries, and returns the result. /sql-agent does the same but as a zero-shot agent. Though /sql-agent didn’t work as reliably as I hoped (see Appendix), watching it struggle and eventually get it right was endearing and motivating (tweet thread).

Далее я попробовал собрать агентов с доступом к инструментам вроде SQL и поиска. /sql принимает вопросы на естественном языке, пишет и запускает SQL-запросы и возвращает результат. /sql-agent делает то же самое, но в виде zero-shot-агента. Хотя /sql-agent работал не так надёжно, как хотелось бы (см. Приложение), наблюдать, как он мучается и в итоге справляется, было умилительно и мотивирующе (тред в твиттере).

Querying a small database via /sql

Запрос к небольшой базе данных через /sql

Querying a small database via /sql-agent (it's fun to watch it think, observe, and act)

Запрос к небольшой базе данных через /sql-agent (забавно наблюдать, как он думает, наблюдает и действует)

I also built /search, an agent that can use tools to query search provider APIs (e.g., Google Search). This way, the LLM can find recent data that it hasn’t been trained on and return an accurate and up-to-date response. (This was before ChatGPT plugins that now have this functionality out of the box. Even so, it was fun building it from scratch.)

Я также собрал /search — агента, который умеет обращаться к API поисковых провайдеров (например, Google Search). Так LLM может находить свежие данные, на которых её не обучали, и возвращать точные и актуальные ответы. (Это было ещё до плагинов ChatGPT, в которых эта функциональность теперь есть из коробки. Но даже так собрать всё с нуля было интересно.)

Using /search to find recent information for the LLM

Использование /search для поиска свежей информации для LLM

Most recently, I built a /board of advisors. It’s based on content from informal mentors—and prolific writers—like Paul Graham, Marc Andreessen, Will Larson, Charity Majors, and Naval Ravikant. /board provides advice on topics including technology, leadership, and startups. Its response includes source URLs for further reading, which can be chained with /summarize and /eli5 (tweet thread).

Совсем недавно я собрал /board — совет экспертов. В его основе — материалы неформальных менторов и плодовитых авторов: Paul Graham, Marc Andreessen, Will Larson, Charity Majors и Naval Ravikant. /board даёт советы по таким темам, как технологии, лидерство и стартапы. В ответе указаны URL-источники для дальнейшего чтения, которые можно прогнать через /summarize и /eli5 (тред в твиттере).

Seeking advice on technical leadership and personal success from the /board

Спрашиваю у /board совета по техническому лидерству и личному успеху

I also built /ask-ey which is similar to /board but based on my own writing. Because I’m more familiar with my work, it’s easier to spot issues such as not using an expected source (i.e., recall issue) or using irrelevant sources (i.e., ranking issue).

Ещё я сделал /ask-ey — он похож на /board, но работает на моих собственных текстах. Поскольку я лучше знаком со своей работой, мне легче замечать проблемы — например, когда не используется ожидаемый источник (проблема recall) или используются нерелевантные источники (проблема ранжирования).

Synthesizing across recsys and mechanism posts on my site via /ask-ey

Синтез по постам про recsys и механизмы на моём сайте через /ask-ey

Combining LLMs, databases, search APIs, and Discord

Комбинируем LLM, базы данных, поисковые API и Discord

To extract content from URLs, I used good ol’ requests and BeautifulSoup. For LLMs, I worked with OpenAI’s gpt-3.5-turbo and gpt-4, primarily the former due to its cost-effectiveness. LangChain made it easy to apply the LLM chains, agents, and tools. For search, I used Google’s custom search through the google-api-python-client wrapper. To embed documents and queries, I used OpenAI’s text-embedding-ada-002.

Чтобы извлекать содержимое из URL, я воспользовался старыми добрыми requests и BeautifulSoup. Для LLM я использовал gpt-3.5-turbo и gpt-4 от OpenAI, преимущественно первую — она экономичнее. LangChain упростил работу с LLM-цепочками, агентами и инструментами. Для поиска я задействовал кастомный поиск Google через обёртку google-api-python-client. Для эмбеддингов документов и запросов — text-embedding-ada-002 от OpenAI.

The application server was hosted on Railway. To host, serve, and find nearest neighbours on embeddings, I used Pinecone. Lastly, I integrated everything with Discord via the interactions wrapper.

Сервер приложения был развёрнут на Railway. Для хранения, обслуживания и поиска ближайших соседей по эмбеддингам я использовал Pinecone. Наконец, всё это интегрировано с Discord через обёртку interactions.

Shortcomings in retrieval and how to solve them

Слабые места поиска и как их исправить

While experimenting with /board and /ask-ey, I noticed that it wasn’t retrieving and using the expected sources some of the time.

Экспериментируя с /board и /ask-ey, я заметил, что они иногда не извлекают и не используют ожидаемые источники.

For example, when I asked the /board “How do I decide between being a manager or an IC”, it fails to use (as a source) any of Charity’s writing on the manager-engineer pendulum or management. However, tweaking the question to “How do I decide between being a manager or an engineer” resolved this.

Например, когда я спросил у /board «Как мне выбрать между ролью менеджера и IC?», он не использовал в качестве источника ни один из текстов Charity о маятнике менеджер—инженер pendulum или о management. Однако, переформулировав вопрос как «Как мне выбрать между ролью менеджера и инженера?», я получил нужный результат.

Asking the first question doesn't lead to the expected manager-eng sources being used; the second does

При первом вопросе ожидаемые источники о паре менеджер—инженер не используются; при втором — используются

Similarly, when I /ask-ey “What bandits are used in recommendation systems”, it didn’t retrieve my main writing on bandits. But updating the question to “How are bandits used in recommendation systems” fixed this issue.

Аналогично, когда я через /ask-ey спросил «Какие бандиты используются в recommendation systems?», он не нашёл мой основной материал про бандитов. Но переформулировка вопроса на «Как используются бандиты в recommendation systems?» решила проблему.

Asking the first question doesn't lead to the expected bandit sources being used; the second does

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

But when I checked the retrieved sources, it was disappointing to see that only the top hit came from the expected URL, and even that was an irrelevant chunk of the content. (Text from each URL is split into chunks of 1,500 tokens.) I had expected embedding-based retrival to fetch more chunks from the bandit URL. This suggests there’s room to improve on how I processed the data before embedding and highlights the importance of data prep.

Но, посмотрев найденные источники, я с разочарованием заметил, что только верхний результат пришёл из ожидаемого URL, и даже это был нерелевантный кусок контента. (Текст с каждого URL разбивается на чанки по 1500 токенов.) Я ожидал, что поиск по эмбеддингам подтянет больше чанков из статьи про бандитов. Это говорит о том, что есть над чем поработать в подготовке данных перед эмбеддингом, и подчёркивает важность data prep.

Only the top hit has the right resource but it doesn't contain useful content

Только верхний результат — это нужный источник, но в нём нет полезного контента

This issue is partially due to poor recall. Here are a few hypotheses on why this happens:

Частично это связано с плохим recall. Вот несколько гипотез, почему так происходит:

ANN-индексы могут быть настроены неоптимально Готовые эмбеддинги могут плохо переноситься между доменами Документы могут быть неудачно разбиты на чанки Одного только поиска по эмбеддингам может быть недостаточно

ANN indices might be tuned sub-optimally

ANN-индексы могут быть настроены неоптимально

Most (if not all) embedding-based retrieval use approximate nearest neighbours (ANN). If we use exact nearest neighbours, we would get perfect recall of 1.0 but with higher latency (think seconds). In contrast, ANN offers good-enough recall (~0.95) with millisecond latency. I’ve previously compared several open-source ANNs and most achieved ~0.95 recall at throughput of hundreds to thousands of queries per second.

Большинство (если не все) систем поиска по эмбеддингам используют приближённый поиск ближайших соседей (ANN). Если использовать точный поиск, мы получим идеальный recall, равный 1.0, но с большей задержкой (порядка секунд). ANN же даёт достаточно хороший recall (~0.95) при задержках в миллисекунды. Я ранее сравнивал несколько open-source ANN, и большинство показывали ~0.95 recall при пропускной способности от сотен до тысяч запросов в секунду.

Benchmarking ANNs on recall vs latency across index parameters; top-right is better.

Сравнение ANN по recall и задержке при разных параметрах индекса; правый верхний угол — лучше.

If the issue lies in a sub-optimally tuned ANN index, we can tune the index parameters to achieve the recall/latency trade-off we need. However, this requires more effort compared to a plug-and-play index as a service. I’m also not sure if cloud vector databases offer the option to tune the ANN. As a result, we could end up with as low as 50% recall.

Если проблема в неоптимально настроенном ANN-индексе, мы можем подкрутить параметры индекса, чтобы получить нужный компромисс между recall и задержкой. Однако это требует больше усилий по сравнению с plug-and-play-индексом как сервисом. Я также не уверен, что облачные векторные базы данных дают возможность тюнить ANN. В итоге recall может быть всего около 50%.

Off-the-shelf embeddings may transfer poorly across domains

Готовые эмбеддинги могут плохо переноситься между доменами

Off-the-shelf embeddings may be too generic and don’t transfer well to other domains. From the examples in this OpenAI forum, we see unexpectedly high cosine similarity between seemingly different text. (While the failure examples above seem generic, the point is that we should pay attention when applying embeddings to our domain.)

Готовые эмбеддинги могут оказаться слишком общими и плохо переноситься на другие домены. По примерам из этого форума OpenAI видно, как у явно разных текстов оказывается неожиданно высокая косинусная близость. (Хотя примеры выше выглядят общими, суть в том, что нужно внимательно относиться к применению эмбеддингов в своём домене.)

A possible solution: If we have both positive and negative examples, we can fine-tune an embedding model via triplet loss. This way, we can ensure that the distance between the anchor and positive example is closer than the distance between the anchor and negative example (by a margin). This is especially helpful when embedding private data that contains language that foundational models may not have seen.

Возможное решение: если у нас есть положительные и отрицательные примеры, мы можем дообучить модель эмбеддингов через triplet loss. Так мы добьёмся того, что расстояние между якорем и положительным примером будет меньше (с запасом), чем расстояние между якорем и отрицательным примером. Это особенно полезно при эмбеддинге приватных данных, в которых содержатся выражения, не встречавшиеся фундаментальным моделям.

Preparing these (anchor, positive, negative) triplets is the bulk of the work. One way is to collect explicit feedback by returning sources in responses and asking people to thumbs up/down on them. Alternatively, implicit feedback is available in settings such as e-commerce, where we can consider results that users ignore as negatives, or search, where we provide sources in results (à la Bing Chat) and observe if users click on them.

Подготовка таких триплетов (якорь, положительный, отрицательный) — основная часть работы. Один из способов — собирать явную обратную связь, возвращая в ответах источники и прося пользователей ставить им лайк/дизлайк. Также доступна неявная обратная связь — например, в e-commerce можно считать отрицательными те результаты, которые пользователи игнорируют; или в поиске мы можем показывать источники в результатах (à la Bing Chat) и смотреть, кликают ли по ним.

Documents may be inadequately chunked

Документы могут быть неудачно разбиты на чанки

Third, if we’re using LangChain, we’re probably taking the default approach of using its text splitter and chunking content into documents of 1,000 - 2,000 tokens each. While we can have such large documents because recent embedding models can scale to long input text, problems may arise when the input is overloaded with multiple concepts.

В-третьих, если мы используем LangChain, скорее всего мы по умолчанию применяем его text splitter и режем контент на документы по 1000–2000 токенов каждый. Такие большие документы возможны, потому что современные модели эмбеддингов поддерживают длинные входные тексты, но проблемы возникают, когда вход перегружен несколькими концепциями.

Imagine embedding a 3,000-word document that has five high-level concepts and a dozen lower-level concepts. Embedding the entire document may force the model to place it in the latent space of all concepts, making retrieval based on any single concept difficult. Even if we split it into multiple chunks of 1,500 tokens each, each chunk’s embedding could be a muddy blend of multiple concepts.

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

A more effective approach could be to chunk documents by sections or paragraphs. After all, this is how most content is organized, where each section/chapter discusses a high-level concept while paragraphs contain lower-level concepts. This should enhance the quality of embeddings and improve embedding-based retrieval. Thankfully, most writing is organized by sections or chapters, with paragraphs separated by /n/n.

Более эффективный подход — разбивать документы по разделам или абзацам. В конце концов, именно так организован большинство текстов: каждая секция или глава раскрывает высокоуровневую концепцию, а абзацы содержат более низкоуровневые. Это должно повысить качество эмбеддингов и улучшить поиск по ним. К счастью, большинство текстов организовано по разделам и главам, а абзацы разделены /n/n.

I suspect there are large gains to be made here though it’s more art than science. It also requires more manual work—scraping and preparing data for my document store took as much, if not more, effort as building the tools. Also see this OpenAI example of how they cleaned, chunked, and embedded wikipedia articles.

Подозреваю, что здесь можно получить большой выигрыш, хотя это скорее искусство, чем наука. Это также требует больше ручной работы — скрапинг и подготовка данных для моего хранилища документов заняли столько же усилий, сколько и сборка инструментов, если не больше. См. также пример от OpenAI о том, как они чистили, разбивали на чанки и эмбеддили статьи Википедии.

Embedding-based retrieval alone might be insufficient

Одного только поиска по эмбеддингам может быть недостаточно

Lastly, relying solely on document and query embeddings for retrieval may be insufficient. While embedding-based retrieval is great for semantic retrieval, it can struggle when term matching is crucial. Because embeddings represent documents as dense vectors, they may fail to capture the importance of individual words in the documents, leading to poor recall. And if the search query is precise and short, embedding-based retrieval may not add that much value, or perform worse. Also, simply embedding the entire query might be too crude and could make the results sensitive to how the question is phrased.

Наконец, опора лишь на эмбеддинги документов и запросов может быть недостаточной. Поиск по эмбеддингам отлично справляется с семантикой, но проигрывает там, где важно точное совпадение по терминам. Поскольку эмбеддинги представляют документы как плотные векторы, они могут не передать важность отдельных слов, что приводит к низкому recall. А если поисковый запрос точный и короткий, поиск по эмбеддингам может либо не давать большой пользы, либо работать даже хуже. Кроме того, простое эмбеддинг всего запроса может быть слишком грубым решением и сделать результаты чувствительными к формулировке вопроса.

One solution is to ensemble semantic search with keyword search. BM25 is a solid baseline when we expect at least one keyword to match. Nonetheless, it doesn’t do as well on shorter queries where there’s no keyword overlap with the relevant documents—in this case, averaged keyword embeddings may perform better. By combining the best of keyword search and semantic search, we can improve recall for various types of queries.

Одно из решений — ансамбль семантического поиска и поиска по ключевым словам. BM25 — надёжная базовая модель, если ожидается совпадение хотя бы по одному ключевому слову. Тем не менее на коротких запросах, где нет совпадения по ключевым словам с релевантными документами, BM25 справляется хуже — здесь усреднённые эмбеддинги ключевых слов могут показать себя лучше. Комбинируя сильные стороны поиска по ключевым словам и семантического поиска, мы можем улучшить recall для разных типов запросов.

Query parsing can also help by identifying and expanding (e.g., synonyms) keywords in the query, ensuring that questions are interpreted consistently regardless of minor differences in phrasing. Spelling correction and autocomplete can also guide users toward better results. (A simple hack is to have the LLM parse the query before proceeding with retrieval.)

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

We can also rank retrieved documents before including them in the LLM’s context. In the bandit query example above, the top hit doesn’t offer any useful information. One solution is to rank documents via query-dependent and query-independent signals. The former is done via BM25 and semantic search while the latter includes user feedback, popularity, recency, PageRank, and so on. Heuristics such as document length may also help.

Также можно ранжировать найденные документы перед тем, как добавлять их в контекст LLM. В примере с запросом про бандитов выше верхний результат не несёт никакой полезной информации. Решение — ранжировать документы по сигналам, зависящим и не зависящим от запроса. Первые рассчитываются через BM25 и семантический поиск, вторые — через пользовательскую обратную связь, популярность, свежесть, PageRank и т. д. Эвристики вроде длины документа тоже могут помочь.

Update: The next iteration uses a hybrid of OpenSearch and E5 embeddings.

Обновление: следующая итерация использует гибрид OpenSearch и эмбеддингов E5.

LLM-augmented research, reflection, and planning

Исследования, рефлексия и планирование с помощью LLM

While the tools above were hacked together over a few weekends, they hint at the potential in LLM-augmented workflows. Here are some ideas in the adjacent possible.

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

Enterprise/Personal Search and Q&A

Корпоративный/персональный поиск и Q&A

Picture yourself as part of an organization where internal documents, meeting transcripts, code, and other resources were stored as retrievable documents. For confidentiality and security reasons, you would only be able to access documents that you have permissions for. To navigate this vast knowledge base, you could ask simple queries such as:

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

Какие были основные причины тикетов высокой важности в прошлом месяце? Каковы наши главные победы и самые ценные уроки за прошлый квартал? Какие недавние «Think Big»-идеи или PRFAQ написала команда?

Then, instead of returning links to documents that we would have to read, why not have an LLM /summarize or /eli5 the information? It could also synthesize via /board and find common patterns, uncovering root causes for seemingly unrelated incidents or finding synergies (or duplication) in upcoming projects. To augment the results, it could /sql or /sql-agent databases or /search for recent data on the internet.

Тогда вместо ссылок на документы, которые пришлось бы читать, почему бы не дать LLM /summarize или /eli5 эту информацию? Он также мог бы синтезировать через /board и находить общие закономерности, вскрывая корневые причины внешне не связанных инцидентов или находя синергии (или дублирование) в предстоящих проектах. Чтобы дополнить результаты, он мог бы делать /sql или /sql-agent к базам, или /search по свежим данным в интернете.

Let’s consider another scenario which uses a personal knowledge base. Over the years, I’ve built up a library of books, papers, and disorganized notes. Unfortunately, my memory degrades over time and I forget most of the details within a week. To address this, I can apply similar techniques to my personal knowledge base and /ask-ey:

Рассмотрим другой сценарий — личная база знаний. За годы я накопил библиотеку книг, статей и разрозненных заметок. К сожалению, моя память со временем слабеет, и я забываю большую часть деталей в течение недели. Чтобы с этим справиться, я могу применить аналогичные приёмы к личной базе знаний и спрашивать /ask-ey:

В каких статьях обсуждается применение бандитов в recommendation systems? Какой совет я дал бы тому, кто приходит в новую команду? Какие основные темы были в моей жизни в последние несколько лет?

For each of those questions, I’ve invested effort into research, distilling, and publishing the answers as permanent notes. And the process was invaluable for clarifying my thoughts and learning while writing. That said, I think the tools above can get us ~50% there with far less effort. Products like Glean (enterprise) and Rewind (personal) seem to do this.

На каждый из этих вопросов я вложил усилия в исследование, перегонку и публикацию ответов в виде постоянных заметок. И сам процесс был бесценен для прояснения мыслей и обучения через письмо. Тем не менее, я думаю, что инструменты выше могут довести нас примерно до 50% результата с гораздо меньшими усилиями. Похоже, продукты вроде Glean (для корпораций) и Rewind (для личного использования) делают именно это.

Research, Planning, and Writing

Исследования, планирование и написание

Back to the scenario of internal docs and meeting transcripts. Let’s say you’re a leader in your org and need to write an important doc. It could be a six-week plan to tackle tech debt or a more ambitious three-year roadmap. How can we make writing this doc easier?

Вернёмся к сценарию с внутренними документами и транскриптами встреч. Допустим, вы — лидер в своей организации и вам нужно написать важный документ. Это может быть шестинедельный план по борьбе с tech debt или более амбициозная трёхлетняя дорожная карта. Как облегчить написание такого документа?

To write the tech debt document, we’ll first need to understand what are the most pressing issues. We can start by asking /board to gather details about the problems we’re already aware of. /board can help us retrieve and synthesize the relevant trouble tickets, war room meeting transcripts, and more via /sql and internal /search. Then, we can expand to broader queries to find problems we’re unaware of, before diving deeper as needed.

Чтобы написать документ по техдолгу, сначала нужно понять, какие из проблем самые острые. Мы можем начать с того, что попросим /board собрать детали по уже известным проблемам. /board поможет нам найти и синтезировать релевантные тикеты, транскрипты war room-встреч и многое другое через /sql и внутренний /search. Затем мы можем расширить запросы, чтобы найти неосознанные проблемы, а потом погрузиться глубже там, где нужно.

With the top three issues, we can start writing an introduction that outlines the purpose of the document (aka the Why aka the prompt). Then, as we created section headers for each issue, a document retrieval + LLM copilot helps with filling them out, providing data points (/sql), links to relevant sources (/search), and even suggesting solutions (/board). Bing Chat has this in some form. Also, I believe this is the vision for Office 365 Copilot.

Имея три главные проблемы, мы можем начать с введения, в котором изложим цель документа (то есть Why — он же prompt). Затем, по мере того как мы создаём заголовки секций для каждой проблемы, копилот на основе document retrieval + LLM помогает нам их наполнять, предоставляя данные (/sql), ссылки на релевантные источники (/search) и даже предлагая решения (/board). У Bing Chat это уже есть в каком-то виде. Также я верю, что в этом и состоит видение Office 365 Copilot.

As the main author, we’ll still need to apply our judgment to check the relevance of the sources and prioritize the issues. We’ll also need to assess suggested solutions and decide if tweaking one solution could address multiple issues, thereby reducing effort and duplication. Nonetheless, while we’re still responsible for writing the document, our copilot can help gather and prepare the data, significantly reducing our workload.

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

LLMs: Not a knowledge base but a reasoning engine

LLM: не база знаний, а движок рассуждений

“The right way to think of the models that we create is a reasoning engine, not a fact database. They can also act as a fact database, but that’s not really what’s special about them. What we want them to do is something closer to the ability to reason, not to memorize.” — Sam Altman

«Правильный способ думать о моделях, которые мы создаём, — это reasoning engine, а не fact database. Они могут работать и как fact database, но в этом нет ничего особенного. Мы хотим, чтобы они умели именно рассуждать, а не запоминать.» — Sam Altman

We’ve seen that LLMs are adept at using tools, summarizing information, and synthesizing patterns. Being trained on the entire internet somehow gave them reasoning abilities. (Perhaps this is due to learning on Github and StackOverflow data, since code is logic?) Nonetheless, while they can reason, they’re often constrained by the lack of in-depth or private knowledge, like the kind found in enterprise or personal knowledge bases.

Мы увидели, что LLM умеют пользоваться инструментами, суммировать информацию и синтезировать закономерности. Обучение на всём интернете каким-то образом дало им способности к рассуждению. (Возможно, это связано с обучением на данных GitHub и StackOverflow, ведь код — это логика?) Тем не менее, умея рассуждать, они часто ограничены отсутствием глубоких или приватных знаний — таких, что хранятся в корпоративных или личных базах знаний.

I think the key challenge, and solution, is getting them the right information at the right time. Having a well-organized document store can help. And by using a hybrid of keyword and semantic search, we can accurately retrieve the context that LLMs need—this explains why traditional search indices are integrating vector search, why vector databases are adding keyword search, and why some apps adopt a hybrid approach (Vespa.ai, FB search).

Думаю, ключевой вызов — и одновременно решение — в том, чтобы давать им нужную информацию в нужный момент. Хорошо организованное хранилище документов помогает. А используя гибрид keyword search и семантического поиска, мы можем точно извлекать контекст, нужный LLM, — это и объясняет, почему традиционные поисковые индексы интегрируют векторный поиск, почему векторные базы данных добавляют keyword search и почему некоторые приложения идут по гибридному пути (Vespa.ai, FB search).

• • •

• • •

It’s hard to foresee how effective or widespread LLMs will become. I’ve previously asked whether LLMs might have the same impact as computers, mobile phones, or the internet. But as I continue experimenting with them, I’m starting to think that their potential could be even greater than all those technologies combined.

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

And even if I end up being wrong, at least I can still have fun getting LLMs to explain headlines in the style of Dr. Seuss or make up quirky quotes on my Raspberry Pi Pico.

А даже если я ошибаюсь, мне как минимум всё ещё весело заставлять LLM объяснять заголовки в стиле Dr. Seuss или придумывать причудливые цитаты на моей Raspberry Pi Pico.

While some use LLMs to disrupt industries and more,
Others build ChatGPT plugins, pushing boundaries galore.

Yet here I am with my Raspberry Pi loose,
Using LLMs to explain headlines via Dr. Seuss. pic.twitter.com/0MJn6HC2cw

Пока одни используют LLM, чтобы переворачивать индустрии и больше,Другие пишут плагины ChatGPT, расширяя границы без меры.А я — вот, с Raspberry Pi в руке,С помощью LLM объясняю заголовки в стиле Dr. Seuss. pic.twitter.com/0MJn6HC2cw— Eugene Yan (@eugeneyan) 10 апреля 2023

Appendix

Приложение

Here’s an example of how /sql-agent struggled and eventually figured out that it should check the database schema. While it finally executed the right query and got the results, it also ran out of iterations before it could respond 🥲 (Back to top)

Вот пример того, как /sql-agent мучился и в итоге догадался, что надо проверить схему базы. Хотя он наконец выполнил правильный запрос и получил результат, у него закончились итерации до того, как он смог ответить 🥲 (Назад к началу)

/sql-agent struggling with getting the query right

/sql-agent мучается, пытаясь правильно составить запрос

If you found this useful, please cite this write-up as:

Если этот материал оказался полезным, цитируйте его так:

Yan, Ziyou. (Apr 2023). Experimenting with LLMs to Research, Reflect, and Plan. eugeneyan.com. https://eugeneyan.com/writing/llm-experiments/.

Yan, Ziyou. (Apr 2023). Experimenting with LLMs to Research, Reflect, and Plan. eugeneyan.com. https://eugeneyan.com/writing/llm-experiments/.

or

или

@article{yan2023llmapps, title = {Experimenting with LLMs to Research, Reflect, and Plan}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2023}, month = {Apr}, url = {https://eugeneyan.com/writing/llm-experiments/} }

@article{yan2023llmapps, title = {Experimenting with LLMs to Research, Reflect, and Plan}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2023}, month = {Apr}, url = {https://eugeneyan.com/writing/llm-experiments/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

Присоединяйтесь к 11 800+ читателей, получающих обновления о machine learning, RecSys, LLM и инженерии.