Commit the owner's living brief once, on his explicit instruction and against the standing guardrail: its V6 section on reshaping the backend exists nowhere else

This commit is contained in:
heaven 2026-08-29 13:39:18 +03:00
parent 3333119cd3
commit 8afc2e7483

View file

@ -93,3 +93,11 @@ hello my dear
1) Идеи по фронту. 1) Идеи по фронту.
2) Так как фронт будет писаться под веб сначала, то нужно максимально хорошо сделать для ранжирования гуглом и нужно узнать как там сейчас работают актульные гугловские алгоритмы чтобы сайт не банился и не деранжировался. Просто для примера: политика куков, страницы сироты (на которую никто не ссылается) и так далее 2) Так как фронт будет писаться под веб сначала, то нужно максимально хорошо сделать для ранжирования гуглом и нужно узнать как там сейчас работают актульные гугловские алгоритмы чтобы сайт не банился и не деранжировался. Просто для примера: политика куков, страницы сироты (на которую никто не ссылается) и так далее
Идеи проекта V6, 18.08.2026
Идея переделки архитектуры бэкенда:
1) Делаем map reduce запросы в дешевую модель которая майнит банк памяти, находит сущности, РЕЖЕТ книгу по сценам (границы сцен, но граница сцены это просто удобная порция где не теряется смысл (сцены можно склеить, но если сцена крупная она должна вмещаться в контекст модели)) и просим вернуть джейсон. Не переводит, не пишит текст, выдача джейсон с полями, явно приписанная схема джейсона, указывать смещение в тексте (координаты терминов или имен, сцен). Майнинг ВСЕХ терминов. ЕЩЕ СЛУЖЕБНАЯ ИНФА О КНИГЕ, у нас итак достроена сейчас в бэкенде для txt книг нарезка по главам, но можно еще что то сюда завернуть например поиск идиом или еще других вещей чтоб сократить путь критику и дать возможность редактору банка отработать и принять решение
2) Перевод банка памяти в хорошую модель. Просить принять хорошую модель взять на себе редакторскую роль ПРИНЯТИЯ РЕШЕНИЯ С ОБОСНОВАНИЕМ. Хорошо приложить контекст термина, например первого появления термина. Еще можно разделить сущности: имена отдельно, магические предметы отдельно (разные правила перевода), мы кстати так и делаем или нет? Потому что у нас есть чанкование
3) Сам перевод в хорошую модель. Четко задать роль (ты литературный переводчик) Даем оригинал текста + банк памяти (исключительно релевантные, не давать слишком много контекста - у нас вроде есть это). Плюс опционально появились ли новые термины или сомнительное место которое не покрыто базой. Размер фрагмента - границы сцен. И я бы не подсовывал хорошей модели дешевый черновой вариант. Запретить что то? Менять канон? Зажать промтом, но не бесконечными правилами, а рамками и по каким критериям мы будем провериять результат
4) Литературный критик. Получает исходный текст, банк памяти и не переписывает а дает фидбек: вот тут звучит не по русски, тут термин упал. Зажать модель промтом чтоб не выдавал минорные проблемы, просить явно не предлагать решения, а только зафиксировать расхождение. Заставить критика жаловаться, а не чинить. МАЙНИНГ ЗАМЕЧАНИЙ (новый банк памяти считай замечаний). Просим критика выделить сцену, проблемное место, уверенность в проблемном месте, что пошло не так. Сложная архитектура для критика, так как есть риск лишних правок, в том числе есть правки разной сложности: смысловой (где переврали сюжет), простой случай когда проблема 1 термине непереведенном или непереведенном не так, потеря смысла, неестественный русский (калька языка), и другие проблемы например времен. Хороший критик классифицирует проблему, но не более сверх, тогда редактор понимает куда копать.
5) Запрос в модель редактора точечного фикса конкретных проблем. Постим строку банка проблемных мест и просим исправить. Затем инжектим фиксы в текст. Это edit точечный редактор. Не переписывальщик ни в коем случае он не переписывает ничего