textmachine/START_PROMT.MD

Идея у меня такая: реализовать бэкенд c фронтендом переводов крупных текстов, то есть книг (прицелюсь пока что в японские/китайские/английские ранобэ и вебновеллы), который будет ходить в ИИ апи для того чтобы переводить поп культурный текст.

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

Главная цель проекта -- максимальное качество и решение проблемы "нехудожественности" ИИ-переводов используя ИИ-перевод (вот так противоречиво, да), стоит подойти креативно к вопросу, возможно применить какие-то мльные математические подходы дообучения под конкретную книгу, интернет ресерча для перевеода конкретной книги, соседних бэкенду тулзов, которые будут выполнять какую то совсем другую работу по переводу, возможно вызов каких-то скиллов как у агентов и тп.

Набор немного разрозненных идей V0

1. построить пайплайн из разных агентов
2. агенты будут выступать в разных ролях: судьи, переводчики, редакторы, консультанты поп культуры, писатели, языковые анализаторы и другие возможны роли если ты понимаешь в этом лучше меня
3. построить пайплайн из дешевых агентов, чтоб перевод книги не превращался в дикую стоимость по цене
4. так же именно бэкендово мне кажется возможным поднятие перевода до уровня хороших моделей из-за свежего исследования arXiv, март 2026 про мультиагентные пайплайны с судьей селектором
5. возможно стоит провести исследование по цене/качестве апи разных операторов
6. у меня есть локальная не самая мощная видеокарта с 8гб памяти и 32 гб рам, можно ради экономии запускать на ней какую-нибдь модельку, я уже поигрался с оллама, вроде она нормально отвечает, но можно и что то еще позапускать и поисследовать, сам у меня бэкенд будет пока локально работать пока мне поиграться просто
7. подход к переводу огромных текстов, понятное дело что весь текст книги не загрузить в модель, так что тут придется при переводе создавать какой-то банк памяти для модели, или глоссарий перевода, вот тут неплохо было бы применить какую нибудь технологию или подход для экономии токенов и запоминании всего контекста книги
8. этот глоссарий мне кажется и места для большего внимания и контрибьюта моделей
9. сами текста могут быть агрессивными с точки зрения морали или перевода 18+, нужно учитывать цензуру моделей, например можно спрашивать локальную разцензуренную модель есть ли тут текст который модель не захочет переводить и надо решать что дальше с подобными ситуациями делать и как их обходить чтоб модели не бредили из-за своих настроек -- вот тут мне кажется будет сильный подход со стороны мультиагентности потому что у разных провайдеров и системные промты разные и они будут по-разному переводить одно и то же.
10. как раз о незацензуренных качественных моделей -- мне видится тут решение от xAi
11. переводить я в основом хочу с китайского и английского и русского и японского во все стороны, думаю это основные языки будут
12. одна из целей высокая маржа при дешевых токенах, исследовать модели и их биллинг
13. в целом исследовать подходы профессиональных переводчиков к сложным текстам, потому что как ты понимаешь при написании текста у автора часто есть видение в целом, поэтому тут надо промтить в модели так как будто весь текст уже прочитан или вообще оставлять рефернс книгу предыдущих частей
14. про отдельные части хорошо бы отдельно подумать, потому что возможность загружать в бэкенд рефернс переводы или предыдущие части -- это сильно улучшит качество переводов, так как они будут держаться единого стиля, но тут количество текста растет конечно сильно
15. отдельно меня интересует вопрос с подходом к художественному переводу и смыслам которые текстовые модели считывают бывают хуже чем люди, особенно дешевые модели, потому что именно дорогие модели обучены на большом разноборазии и могут считать больше смыслов чем слабая модель, возможно тут стоит вызывать какой-нибудь опус, но тк он дорогой не слишком часто это делать разумеется. И он кстати зацензуренный так что возможно стоит выбрать модель более подходящую
16. возможно стоит прикрутить вебфетч в случаях когда модели не хватает культурного контекста чтоб понять о каком именно термине идет речь, но тут осторожно надо потому что у слов бывает крайне много значений
17. нужно определится с языком бэкенда, я лучше всего знаю c++/userver, но другие технологии тоже можно взять вроде go/rust, так как скорее все реализовывать будешь ты, а мне не придется смотреть сам код
18. думаю прежде чем кодить стоит нарисовать какую-то диаграмму на puml которую я мог бы посмотреть и мы по ней могли строить наш бэкенд
19. в целом возможно стоит синкануться с интернетом, комьюнити чтобы узнать больше об этой индустрии, какие уже есть решения, какие у них проблемы, что не нравится людям и куда это все движется и что является фронтиром
20. мне в целом помимо бэкенд технологии хочется еще и написать фронт к бэкенду который будет работать по принципу ide для агентного перевода, только понятное дело которые будут переводить огромные текста и взаимодействовать с бэкендом и юзером
21. подробнее про фронт, хотя мне кажется сначала бэкенд займет у нас много времени, а потом уже фронт будем делать, но планы на фронт такие: иметь возможность одновременного чтения двух текстов которые будут размечаться от начала и конца растягивая друг друга по границам смыслов, тут надо как то заложить возможно такую функциональность, ну например как это выровнено будет выглядеть: hello my dear привет дорогой понятно о чем речь тут? тут разумеется текст может разъзжать, но это будущая функциональность, как ее реализовать мне не понятно, если это будет размечать нейросеть не забредит ли она? Или лучше размечать как то чанки что заливались в перевод
22. так же я хотел бы задать с фронта настроики, типа это текст 18+ или нет, жанр фэнтези или сайфай, ну в общем что то такое что поможет моделям от человека
23. так как фронт будет работь как ide вроде того же vs code и claude code в нем (это ты), то возможно тупо стоит перетянуть фишки, вроде загрузил на фронт книгу, агенты поехали ее разбирать, разобрали, потом задали вопрос на согласование глоссария (если фронтом будут пользоваться проффесиональные переводчики/редактора), возможно что то такое можно просто скопирвать с vs code/Cursor/Windsurf, тут принимаются свежие идеи
24. фронт пока понятное дело реализовывать не будем, у нас бэкенд приоритет, но все эти фичи будут влиять и на бэк, поэтому какую то минимальную функциональность заложить стоит, но возможно первое MVP просто переводит фул книгу просто так
25. нужен какой то учет токенов в бэкенде чтоб понимать стоимость, что отжирает и так далее, вообще тут телеметрия мне кажется будет очень важна, чтоб по ней можно было дебажиться, возможно бд какое то поднимать
26. что касается технологии для выбора фронта -- тут я не знаю, мне кажется работать это все будет на нативной платформе, то есть целевое это windows, но наверное и веб не помешает, думаешь тут электрон? Хотя он дорогой по ресурсам и тп, вобщем хз
27. возможно стоит провести какое то исследование апи операторов моделей, собрать golden set, протестировать их с разной стороны, у меня уже есть несколько апи кеев, думаю тут стоит идти со стороны бэкенда в общие какие-то решение, но наверное написать адаптеры для дерганья разных моделей будет довольно просто, вот я уже подобный бэкенд писал для чат бота в мессенджере, можешь посмотреть код /home/ubuntu/projects/vojo/apps/ai-bot
28. так как индустрия бешенно несется вперед возможно стоит пройтись по последним научным исследованиям и гипотезам от топовых (ну или просто компетентных вузов всего мира), возможно они придумали технологию или гипотезы которые еще никто не реализовал, но они интересны и вероятно выстрелят
29. вероятно стоит еще оценить юридический аспект подобного софта и распространение подобных переводов
30. неплохо было бы приценить сколько будет стоит перевод 1 такой книги
31. как то неплохо было бы измерять онлайн и оффлайн качество, опять же я говорил про телеметрию которую можно собирать при переводе, но пока не понимаю какую
32. что касается тулзов, а агентного бэкенда мне кажется должны быть свои тулзы, чисто переводческие тулзы, какие я не очень пока знаю и понимаю, но возможно какие то могут быть
33. я тебе уже говорил что для качественного перевода надо знать контекст вперед и назад, так что тут возможно стоит проектировать агентов так чтобы они действовали как профессиональные переводчики, сначала все читали, потом брались за перевод, но я тебе об этом уже писал
34. запросы к моделям, так как через апи можно передавать температуру и прочие параметры, надо понять каким образом и качеством это вообще влияет на переводы текстов
35. помимо исследования чисто технического мультагентных систем и ии, возможно стоит обратится к исследованием чисто филологическим, переводческим и возможно более старым решениям, возможно где то в истории уже есть предложения людьми из разряда все новое хорошо забытое старое, тут важно проявить смекалку и творческий подход под задачу, возможно нестандартные решения, возможно даже костыльные которые будет пораждать сам фронт
36. я за переиспользуемые решения, по тому же решению банка памяти или глоссария использовать что то готовое или перетянуть готовое решение вроде MemPalace или его форкнуть, допилить, оценить
37. тебе доступны вообще все тулзы на этом компьютере: вебфетч, gh, просмотр репозиториев, клонирование в /tmp и так далее, делай что захочешь чтоб достигнуть цели

Мысли получились довольно сумбурные, плюс я накидывал по мере вдохновения, возможно я где-то мог ошибиться, можешь меня поправлять. В целом я тебя нигде и ни в чем не ограничиваю, полная творческая свобода с учетом задачи, выслушаю предложения, гипотезы, твои сомнения и критику, можешь сам дополнить перечисленные пункты, перефразировать их, синтезировать и придумать свои, так же я думаю стоит выделать некоторые пункты жирным курсивом и уделить им максимум внимания, потому что какие-то из них будут определять или могут неожиданным образом определить качество таких переводов. Сам промт у меня получился довольно большой и очень много задач, которые возможно будут решаться аж несколькими сессиями воркфлоу, которые я могу в принципе запустить и отдельно в отдельных окнах vs code. Ты на данный момент центральный судья с которого вообще весь проект стартует как гипотеза. Думаю по мере исследований стоит завести в проекте отдельную папку где будет сохранятся какой-то прогресс аля документация, возможно первое форкфлоу стоит отдать приоритетным пунктам MVP а по ходу мне ты можешь выдать промт где я в другом окне стартану другую сессию которая будет в эти же доки параллельно контрибьютить или последовательно можем передать эти дела, в общем как тебе удобно чтоб не забивать контекст так как он у тебя ограничен. Но в целом у нас тут стартует для начала такая MVP-сессия прицел в подобное приложение и перспективы его продажи на рынки ru/en переводчиков, копирайтеров и редакторов.

Идеи которые возникли постфактум V1, 06.07.2025

1. что человечество и академическая среда знает об математическом и лингвистическом анализе книг? Например поможет ли нам какой-то без ллмный анализатор книги перевод? Для банка памяти? Что мы тут обсчитать можем, например количество слов, глав, абзацев. Можем посчитать количество повторяемых слов например сколько упоминается раз то или иное имя. Могут ли нам помочь эти данные в переводе (банк памяти)? В валидации перевода когда бэкенд полностью отработал? Не пропустили ли мы какую то главу? И так далее, это всего лишь примеры, если тут можно найти какое-то совершенно другое применения или другие примеры -- то стоит попробовать
2. как лучше всего промтить в модели? При переводе будет залетать наверное в модель сам оригинальный текст, какие-то референсы из банка памяти и так далее. Так вот как лучше всего составить промт чтоб модель не галлюцинировала, все запомнила и ничего не выкинула? Возможно стоит исследовать фронтир промтинга, рекомендации конкретных провайдеров, гайды и находки юзеров. Опять же академические исследования промтинга в большие модели? Для перевода текста? Ну вот например в модель загружают чанк для перевода монолог рассказчика, возможно какие-то диалоги между персонажами, в целом из куска который загружен в модель довольно трудно понять как перевести соблюдая контекст, который есть у читателя (те же голоса персонажей), стоит вот тут как либо определять личность персонажа в банке памяти, вызывать нейросеть с этой метадатой, короче говоря банк памяти -- это просто словарь переведенных слов? или уже нечто большее для качественного перевода при чанковании?
3. как валидировать качество перевода и его художественность? Очевидно нужно как-то понимать влияние технических решений, например того же промтинга или занесения в банк памяти на само качество перевода. Что если какое то техническое решение наоборот ухудшает, а не улучшает качество?
4. что академия знает и что мы от них перетащили в качестве знаний о языках и их стиле письма? Ну привожу пример: часто в китайских новеллах главы пишутся короткими и в особенности абзацы, у европейских языков такой традиции нет, европейские книги пишутся не построчно как китайские иероглифы, а нормальными крупными абзацами и структурироваными диалогами. Что мы тут должны делать и как переводить так чтобы текст становился более читаемым для привычных структур и языковых кострукций других языковых культур?
5. что делать если сам оригинальный текст написан очень слабо с художественной точки зрения и мысли? Стоил ли ее подправлять и справятся ли с этим модели?
6. тест моделей на редактуру и художественный стиль бы уже проведен. Но есть вопрос: сравнивались популярные тексты, что если эти крупные модели уже его и так знали, видели и понимали как переводить? Как разные модели будут переводить и редактировать совершенно им незнакомый текст? Но самое интересное как они переведут какое-нибудь вообще новое выдуманное или составленное слово самим автором? Или соединенное из разных других слов? Может быть взятые из другого языка? Или которое является исковерконным словом другого языка, скажем более древнего? Этот пункт возможно стоит занести в документацию где юзеры жалуются на ИИ перевод.
7. какие филосовские исследования есть на тему ответов модели и промтинга в нее? Это в тему решения проблемы художественной составляющей перевода. Как заставить модель сотворить что-то что подобно человеческой мысли и пониманию. Есть ли тут лингвофилосовские исследования последние?
8. что насчет параметров моделей при запросе? В текущей вариации реализации eval сессия тестировала разные параметры и как они влияют главным образом на художественность перевода? Хватило ли нам тестов?
9. что мы знаем насчет эры до ии перевода и его качества? до этого многие текста переводились обычными алгоритмами, можем ли мы применить оттуда какое-то решение? только за этим нужно внимательно следить, чтобы оно не уронило качество

Выше дополненые пукнты содержат много примеров. На примерах не надо зацикливаться и это крайне важный поинт всего проекта и затеи. Понятное дело что сложные системы состоят из многих решений, которые закрывают конкретные проблемы и пробелы друг друга. Но речь о том чтобы не зацикливаться на конкретных примерах потому что их вспомнил я, а есть куча других примеров которых я не вспомнил, не понимаю или не вижу еще пачку другую проблем и поэтому не могу привести по ним примеры. Поэтому было бы неплохо если бы ты помог мне в классификации или сам додумался до проблемных мест перевода меж двумя языками. Считаю это приоритетом идей V1. Так же насчет научных исследований -- научные статьи это хорошо, но мы практики, и нам нужны практические решения, которые работают, так что возможно академия для нас может быть вредна, но это надо еще доказать или проверить гипотезы которые они выдвигают, возможно уже в планах строить бэкенд так, чтобы иметь возможность проводить АБ тесты (но это наверное на сильное будущее)

Идеи V2 не касающиеся самого перевода

1. что касается бэкенда у нас планируется какая-то функциональность которая предотвращает абъюз моделей? Очевидно что у нас цель переводить книги и текста на другие языки, будет досадно если в книгу кто-то вставит абузивный промт или атаку. Особенно досадно если прямо под самый конец, жечь токены ради абъюза не хочется. Есть ли какой то вариант не тратя токены понять что нас миссюзают (делают что-то заточенное не на перевод, например написать код) или атакуют? Желательно дешевый и крайне точный с минимум false positive.
2. ну и насчет генерации книги, думаю стоит так же предусмотреть вариант остановки всего пайплайна, не знаю предусмотрено это где то в планах по бэкенду. по разным причинам, будь то команда от юзера или сигнал какой-то изнутри самого пайплайна перевода. и как остановка так и кнопка продолжения (разумеется абъзивный промт нельзя продолжить)
3. так же есть ли у нас ограничения по входу? очевидно что загружать 4 тома войны и мир, хотя это не много наверное, в общем тут надо в бэкенде какую то настроечку сделать, может котороая будет считать входные токены для книги

Идеи V3 пайплайна перевода

1. как мы можем понять что вышеперечисленные идеи и пункты или приемы в ходе реализации улучшают, а не ухудшают качество перевода? стоит ли что-нибудь пересмотреть или кардинально протестировать чтобы отсеять мусор? docs/research/12-architecture-as-antipattern.md
2. как мы будем самоулучшаться? очевидно что при переводах больших книг количество текстов просто огромно, и разбираться в нем и тратить редакторский ресурс человека дорого, может приводить к ошибкам и так далее
3. из пункта 2 у меня следует крайнее радикальное предложение: так как бэкенд ориентирован в основном на дешевые модели и судью среднего качество, что если мы встроем в часть пайплайна фронтир модель которая очень много знает? вероятным кандидатом мне видится или дорогой гемини или чатгпт, сами модели в переводе учавствовать не будут, но вот возможно проанализировать перевод и просигнализировать нам в лог или отдельный отчет по генерации книги вполне себе могут, из этого отчета можно вытаскивать буллеты и точечно понимать фиксы для пайплайна, тут я думаю остается только маневр для выбора модели и режима ее размышлений (chathpt 5.5?), плюс промт ей нужен качественный который погрузит в основные механизмы, так чтобы она понимала что и откуда идет. поэтому это будет не модель судья, а модель судья над судьей и пайплайном в целом. оцени эту идею, как тебе она?
4. Отдельно стоит отметить распространенные проблемы docs/research/12-common-failures.md ИИ-перевода, нужно придумать какими

Выводы проекта. Считаю что надо отметить две центральные ранее озвученные не просто идеи к которым мы стремимся, а это считай все ради чего мы затеяли это все.

1. устранить потерю контекста при переводе, с этим нам поможет банк памяти (тут на самом деле вообще не важно что нам поможет в этом), так вот решение вокруг "банка памяти" должно быть крайне точным, так как даже 1 ошибка в переводе текста может быть для читателя фатальной чтоб закрыть перевод перевод книги и сочти решение не зрелым
2. художественность и смыслы, понятное дело что оценить художественность довольно трудно, но неполноценность ИИ-переводов обосновать можно: у ИИ просто напросто нет всего контекста, модели не могут додумать то чего не знаю или попытаться понять, иногда написанное в книге лежит за пределами самой книги и модель не может сложить воедино паззл, так вот помимо валидатора пайплайна который вызывается редко чтоб оценить перевод, возможно стоит так же редко вызывать модель на крайне узком специализированном участке перевода который и будет решать 1 раз за книгу эту диллему. но это лишь предложение и примеры, всегда к ним можно критически отнестись или предложить что то другое более эффективное Возможно две перечисленные основные задачи стоит поставить eval сессии чтоб она точками выдернула механизмы пайплайна и верифицировала их и оценила влияние, так же нужно чтоб валидировалось не только положительное но и пагубное влияние каких то решений.

Идеи проекта V4, 12.07.2026

1. Как сейчас происходит работа бэкенда над главами? Она идет просто параллельно по главам? Как это работает в архитектуре? Можем ли мы значительно ускорить перевод, сначала нарезав книгу как нам нужно (чанки, главы, неважно что это будет), потом всю эту пачку параллельно запулить в модель переводчика, переводчик условно говоря вынесет из главы на сноски кандидаты в глоссарий, потом мы их распарсим и запихнем в банк памяти, а редактор потом отредактирует все термина? и получить книгу в N раз быстрее? Но это наверное на конец по фазам можно ставить так как это такие, полировочные работы. Да и вообще хороший вопрос, как ускорить перевод книг значительно? Считаю это главной идеей V4, потому что очень быстрый перевод книги это киллерфича. Или мы еще вообще не думали как будем извлекать из книги и строить глоссарий? Короче говоря тут надо синкануться с текущими планами и насколько этот пункт дорабатываемый и аккуратно ложится
2. Считаю что идея со встраиванием в пайплайн фронтир модели -- бессмысленна. Она нам в принципе ничего не дает такого интересного
3. Проход книг наперед тоже считаю идеей изначальной не очень удачливой. Что именно и как нам это может дать? Это вообще полезно потенциально? Бустанет перевод хоть как то? Или это оверкилл непонятный и лучше пока сосредоточиться на другом?
4. Как мы будем собирать глоссарий? Я так понимаю переводом терминов будет заниматься сама модель, и я считаю глоссарий крайне важным, нужно исследовать как делать запросы для перевода в глоссарий, нужно записывать контекст в котором эти слова чаще всего встречаются, плюс передавать жанр книги наверное. И самое важно некоторые запросы перевода в глоссарий мне кажется надо юзать модель с вебфетчем, например гемини лайт с вебфетчем или любую другую
5. Так же задача на будущее для полигона, сейчас все переводы идут с какого-то языка на русский, но в целом глупо делать бэкенд только под русский. Например промт запросы сейчас идут на русском в модели. Скорее всего надо делать запросы на языке на который мы переводим. Но это вообще не точно. Может нужно писать на яызке оригинала? В любом случае мне кажется в переводе с китайского на анлийский -- русский вообще не должен учавствовать чтоб не сбивать модель с вероятностного прогона