Спасибо за классный комментарий! Вы не гитхабовскими code review agent и coding agent пользуетесь, как я понял? Мы как раз ими - тоже подсовываем жира тикет и конфлюенс страницы через mcp attlassian. А в проектах где не Жира, а прямо GitHub issue накиаких mcp не надо. Качество соответствия AC просто отпад. Также для нас полезно после code review запускать pre-merge ассистент - он subagent от coding agent. Он анализирует результат code review agent, ранжирует из по критичности и выдает риск-скор мерджа. Дальше человек - ревьювер решает мерджить или отправлять на доработку. Opus 4.7 всех лучше, да. Но потому что опенэйай модели в гитхаб копайлоте работают странно. В кодексе значительно лучше...
Так я ровно об этом и говорю. Если вы берёте бесплатную модель только ради воспроизводимости примеров, то у вас автоматически смещается сама оптика статьи: вы начинаете подробно разбирать проблемы класса “что бывает у бесплатных или слабых моделей”. Но для топовых coding-моделей уровня Opus 4.7 или GPT-5.4 значительная часть этих проблем уже просто не является сколько-нибудь актуальной. Поэтому получается не очень честное обобщение: читателю сначала показывают ограничения дешёвого инструмента, а потом подают их как общие закономерности LLM для кодинга вообще.
Откуда столько плюсов? Кто в здравом уме в продакшне для кодинга использует бесплатные llm? Это как писать статью о проблемах закупки продуктов для ресторанов, где в качестве примера берутся решения по принципу “что сегодня раздали даром".
Что за модели вы оба используете? Проблемы шума давно нет. Добавление дополнительных (непротиворечивых, конечно) данных не снижает качество модели. Единственный минус - количество токенов. А так хоть забивай весь мегабитный контекст чанками топ-100 - качество не упадет. А то, что размер чанков зависит от предметной области - это точно подмечено. Еще завист от функционала системы: если это чат-бот - одно. Если агент, пишущий код - другое. Лучшие практики - parental retrievement. Размер большого чанка - абзац/таблица. Маленького - размер среднего входного текста. Если чат бот - предложение. Пользователи обычно не пишут больше одного предложения чат боту.
Нужна единственная метрика -процент правильных ответов с точки зрения эксперта предметной области. Все остальные - вспомогательные и стоит им уделять внимание только если вы ТОЧНО уверены, что они повышают эту главную. Если у вас в базе знаний (вокруг которой rag) нет правильного ответа на конкретный вопрос, то никаким повышением context precision вы это не решите. 2. Главной проблемой после отсутствия информации в базе является выдача релевантных чанков (тех самых, в которых содержится ответ на вопрос пользователя и если которых в принципе нет, то разговаривать вообще не о чем). Простые методы типа топ-к не работают. И тут только два пути - либо повышать это к, тем самым увеличивая денежные затраты на каждый промпт - в принципе рабочий вариант. Либо усложняя алгориьмы. В подавляющем большинстве кейсов (за исключением пожалуй случаев, когда rag нужен на сильно структурированных данных типа sql баз) оптимальным является parential retrievement. Он практически гарантирует, что если в бз есть правильный ответ на вопрос - модель его выдаст пользователю. Его суть: делаем две таблицы чанков: small и large. Large - абзац, таблица целиком и тп - семантически законченный кусок знаний. Small - разбитый на части large чанк, по длинне максимально близкий средней длине вопроса пользователя. Как правило, одно предложение.
Отличная работа! Но хотелось бы меньше кастомизаций и большей универсальности (в реальную систему не только подобные таблицы будут подаваться скорее всего). Для нас сейчас оптимальный по соотношению затраты/качество является следующий вариант: Ключевой момент: parential retrievement. Маленькие чанки в идеале должны быть близки к размеру среднего запроса пользователя. На практике - абзац или ячейка таблицы. Ячейка таблицы как правило меньше среднего абзаца, потому ячейки больше попадают в топ, но это не баг, а фича, так как таблицы более сложный элемент. Большие чанки - абзац или таблица целиком или страница презентации. Да, таблицы парсятся в json, показало себя лучше, чем markdown. Все, такой подход даёт отличную итоговую точность, но, конечно, когда таблица большая, как в ваших примерах, он вылетает по лимиту токенов. Поэтому приходится усложнять. Во-первых, если таблица более двух страниц, то большой чанк тогда - пара страниц таблицы. В принципе достаточно только заголовки перенеси в каждую страницу. Далее, очень большие таблицы, как правило, с простой структурой. Объединения рандомных ячеек, когда, например, где то посередине три ячейки объединили в одну - такое в больших таблицах крайне редко. Поэтому совсем большие плоские таблицы просто конвертируем в pandas dataframe, а llm просим сделать запрос на фильтрацию датафрейма...
Спасибо за классный комментарий! Вы не гитхабовскими code review agent и coding agent пользуетесь, как я понял? Мы как раз ими - тоже подсовываем жира тикет и конфлюенс страницы через mcp attlassian. А в проектах где не Жира, а прямо GitHub issue накиаких mcp не надо. Качество соответствия AC просто отпад. Также для нас полезно после code review запускать pre-merge ассистент - он subagent от coding agent. Он анализирует результат code review agent, ранжирует из по критичности и выдает риск-скор мерджа. Дальше человек - ревьювер решает мерджить или отправлять на доработку. Opus 4.7 всех лучше, да. Но потому что опенэйай модели в гитхаб копайлоте работают странно. В кодексе значительно лучше...
Так я ровно об этом и говорю. Если вы берёте бесплатную модель только ради воспроизводимости примеров, то у вас автоматически смещается сама оптика статьи: вы начинаете подробно разбирать проблемы класса “что бывает у бесплатных или слабых моделей”. Но для топовых coding-моделей уровня Opus 4.7 или GPT-5.4 значительная часть этих проблем уже просто не является сколько-нибудь актуальной. Поэтому получается не очень честное обобщение: читателю сначала показывают ограничения дешёвого инструмента, а потом подают их как общие закономерности LLM для кодинга вообще.
Откуда столько плюсов? Кто в здравом уме в продакшне для кодинга использует бесплатные llm? Это как писать статью о проблемах закупки продуктов для ресторанов, где в качестве примера берутся решения по принципу “что сегодня раздали даром".
Что за модели вы оба используете? Проблемы шума давно нет. Добавление дополнительных (непротиворечивых, конечно) данных не снижает качество модели. Единственный минус - количество токенов. А так хоть забивай весь мегабитный контекст чанками топ-100 - качество не упадет. А то, что размер чанков зависит от предметной области - это точно подмечено. Еще завист от функционала системы: если это чат-бот - одно. Если агент, пишущий код - другое. Лучшие практики - parental retrievement. Размер большого чанка - абзац/таблица. Маленького - размер среднего входного текста. Если чат бот - предложение. Пользователи обычно не пишут больше одного предложения чат боту.
Нужна единственная метрика -процент правильных ответов с точки зрения эксперта предметной области. Все остальные - вспомогательные и стоит им уделять внимание только если вы ТОЧНО уверены, что они повышают эту главную. Если у вас в базе знаний (вокруг которой rag) нет правильного ответа на конкретный вопрос, то никаким повышением context precision вы это не решите. 2. Главной проблемой после отсутствия информации в базе является выдача релевантных чанков (тех самых, в которых содержится ответ на вопрос пользователя и если которых в принципе нет, то разговаривать вообще не о чем). Простые методы типа топ-к не работают. И тут только два пути - либо повышать это к, тем самым увеличивая денежные затраты на каждый промпт - в принципе рабочий вариант. Либо усложняя алгориьмы. В подавляющем большинстве кейсов (за исключением пожалуй случаев, когда rag нужен на сильно структурированных данных типа sql баз) оптимальным является parential retrievement. Он практически гарантирует, что если в бз есть правильный ответ на вопрос - модель его выдаст пользователю. Его суть: делаем две таблицы чанков: small и large. Large - абзац, таблица целиком и тп - семантически законченный кусок знаний. Small - разбитый на части large чанк, по длинне максимально близкий средней длине вопроса пользователя. Как правило, одно предложение.
Отличная работа! Но хотелось бы меньше кастомизаций и большей универсальности (в реальную систему не только подобные таблицы будут подаваться скорее всего). Для нас сейчас оптимальный по соотношению затраты/качество является следующий вариант: Ключевой момент: parential retrievement. Маленькие чанки в идеале должны быть близки к размеру среднего запроса пользователя. На практике - абзац или ячейка таблицы. Ячейка таблицы как правило меньше среднего абзаца, потому ячейки больше попадают в топ, но это не баг, а фича, так как таблицы более сложный элемент. Большие чанки - абзац или таблица целиком или страница презентации. Да, таблицы парсятся в json, показало себя лучше, чем markdown. Все, такой подход даёт отличную итоговую точность, но, конечно, когда таблица большая, как в ваших примерах, он вылетает по лимиту токенов. Поэтому приходится усложнять. Во-первых, если таблица более двух страниц, то большой чанк тогда - пара страниц таблицы. В принципе достаточно только заголовки перенеси в каждую страницу. Далее, очень большие таблицы, как правило, с простой структурой. Объединения рандомных ячеек, когда, например, где то посередине три ячейки объединили в одну - такое в больших таблицах крайне редко. Поэтому совсем большие плоские таблицы просто конвертируем в pandas dataframe, а llm просим сделать запрос на фильтрацию датафрейма...